Narrative:

Tower departed an IFR B206 on a vector and scanned the departure strip via the electronic strip scanner. The west radar controller received the strip and let me know he had the rolling call but was very busy and unable to get the strip to me right away. Tower then departed a BE20 IFR on runway heading. Recent changes in the SOP allow the departure controller to turn away from runway heading and not towards the gate. The helicopter and king air were cross out gates but the tower chose not to issue a 'do not turn' instruction to the radar position. When the B206 checked on my frequency I could not tell what heading or altitude the tower had assigned due to the flight strip printing to a different radar position and the fact that both positions were busy. On initial contact I observed the B206 at about 4 miles off the departure end and flying what I thought to be about a 200 heading. When the B206 checked onto my frequency; the subsequent king air departure was not on my scope or tagged up; and I had not received the departure strip. I then radar identified the helicopter and assigned a heading of 190 and altitude of four thousand. When I finally received the B206 strip; I saw that the tower assigned heading was 180 degrees. That was when the king air called me and I looked to see the tower assigned vector of runway heading off runway 20. I immediately tried to increase separation by climbing the king air over the helicopter; and then by turning the helicopter to a 140 degree heading. The new procedures here are very different from previous procedures which allowed the departure controller turns towards the gate. This was obviously a contributing factor. Additionally; I do not think giving the departure controller a cross out situation without issuing a do not turn instruction is a safe operation due to the recent procedure changes. Previously a 'do not turn' instruction was mandatory especially if the lead aircraft/helicopter was the only radar tag on the departure controllers' scope. Add to the fact that ZZZ has experienced SOP changes; numerous RNAV changes; essentially an airspace redesign for controllers; and the electronic flight strip printer sending the flight strip to the wrong radar position during a busy/complex period of traffic. This was the perfect scenario for errors. There is not enough built into our new system to prevent errors and this highlights that fact. Fix the electronic flight strip printer; this has been a known issue for years and is even addressed in the SOP. Tower should not give cross out IFR traffic without a 'do not turn' instruction; or we need to be provided more flexibility from the local control position as at this time our hands are tied by an unacceptable noise abatement procedures and limited headings. Changes due to RNAV procedures need to be reevaluated by air traffic controllers who are working traffic on a daily basis at ZZZ TRACON/tower.

Related reports:

Google
 

Original NASA ASRS Text

Title: TRACON Controller described a departure conflict event between an IFR King Air and Helicopter. The reporter listed both new procedures and equipment limitations as causal factors.

Narrative: Tower departed an IFR B206 on a vector and scanned the departure strip via the electronic strip scanner. The West RADAR Controller received the strip and let me know he had the rolling call but was very busy and unable to get the strip to me right away. Tower then departed a BE20 IFR on runway heading. Recent changes in the SOP allow the Departure Controller to turn away from runway heading and not towards the gate. The Helicopter and King Air were cross out gates but the Tower chose not to issue a 'do not turn' instruction to the RADAR position. When the B206 checked on my frequency I could not tell what heading or altitude the Tower had assigned due to the flight strip printing to a different RADAR position and the fact that both positions were busy. On initial contact I observed the B206 at about 4 miles off the departure end and flying what I thought to be about a 200 heading. When the B206 checked onto my frequency; the subsequent King Air departure was not on my scope or tagged up; and I had not received the departure strip. I then RADAR identified the Helicopter and assigned a heading of 190 and altitude of four thousand. When I finally received the B206 strip; I saw that the Tower assigned heading was 180 degrees. That was when the King Air called me and I looked to see the Tower assigned vector of runway heading off Runway 20. I immediately tried to increase separation by climbing the King Air over the Helicopter; and then by turning the Helicopter to a 140 degree heading. The new procedures here are very different from previous procedures which allowed the Departure Controller turns towards the gate. This was obviously a contributing factor. Additionally; I do not think giving the Departure Controller a cross out situation without issuing a do not turn instruction is a safe operation due to the recent procedure changes. Previously a 'do not turn' instruction was mandatory especially if the lead aircraft/helicopter was the only RADAR tag on the Departure Controllers' scope. Add to the fact that ZZZ has experienced SOP changes; numerous RNAV changes; essentially an airspace redesign for controllers; and the electronic flight strip printer sending the flight strip to the wrong RADAR position during a busy/complex period of traffic. This was the perfect scenario for errors. There is not enough built into our new system to prevent errors and this highlights that fact. Fix the electronic flight strip printer; this has been a known issue for years and is even addressed in the SOP. Tower should not give cross out IFR traffic without a 'Do Not Turn' instruction; or we need to be provided more flexibility from the Local Control position as at this time our hands are tied by an unacceptable noise abatement procedures and limited headings. Changes due to RNAV procedures need to be reevaluated by air traffic controllers who are working traffic on a daily basis at ZZZ TRACON/Tower.

Data retrieved from NASA's ASRS site as of July 2013 and automatically converted to unabbreviated mixed upper/lowercase text. This report is for informational purposes with no guarantee of accuracy. See NASA's ASRS site for official report.