CTR start trigger error - USB6343

[Dar_Bahatt]

Hi-

A digital pulse from a device in my system is connected to the gate of CTR0 (PFI9).

CTR0 is used as a quadrature encoder. My code routes PFI9 to the gate of CTR1 (PFI4)

and also defines PFI9 as a start trigger for CTR3. CTR3 is set to generate a finite

retriggerable pulse train for each digital pulse on PFI9.

My code returns error -89137 indicating that Specified route cannot be satisfied,

because it requires resources that are currently in use by another route.

Not sure what this means?

Screenshots of relevant code and error message are attached.

I am using LV2010 and a USB-6343.

Your help is appreciated !

Dar

[Courtney_L]

Hey Dar,

I think this is probably an issue with the internal routing of your USB-6343 requiring some of the CTR channels that you are routing to. It looks like when you are routing PFI9 to PFI4 this is actually using CTR3 internally. Take a look at this KnowledgeBase article as I think it applies to your issue:

http://digital.ni.com/public.nsf/allkb/28F2757575F9C77B862575C2005F36B4?OpenDocument

You are definitely having some resource conflict problems and might have to reconfigure which lines you're using. Try testing each part of your code independently to see if you have issues: IE, can you route your CTR0 to the gate of CTR1 without error? Can you use CTR0 as the trigger for CTR3 without error? Then try putting them together.

I hope this helps!

Courtney L

Applications Engineer

National Instruments 

[Dar_Bahatt]

Hi Courtney-

Thanks for your response!

I played with the code and found that if the Start Trigger setup (setting PFI9 as CTR3 start trigger) is executed before

the routing PFI9 to PFI4 then there is no error message.

I wonder why the order of setting these routes makes a difference?

Dar

[Courtney_L]

Hey Dar,

I'd say it's just a matter of the start trigger set-up relinquishing control of the CTR3 line in time for it to be used when PFI9 is routed to PFI4. Are things up and running now?

Courtney L

Applications Engineer

National Instruments

[Dar_Bahatt]

Hi Courtney-

Thanks for your response!

Looks like my code is working as intended, but after reading the link you provided: http://digital.ni.com/public.nsf/allkb/28F2757575F​9C77B862575C2005F36B4?OpenDocument I am concerned about intermittent performance in the long run.

Are there any additional in-depth engineering details at NI you can share on this topic?

Best,

Dar

[Courtney_L · Accepted solution]

Hey Dar,

As long as you're careful about managing your hardware resources then you shouldn't face persistent problems. It's just a matter of knowing which lines you are using at what time, and being conscious of how your signals are physically re-routed in your hardware (as I said, this is something you can check in Measurement & Automation Explorer). There are lots of great DAQ resources online through NI KnowledgeBase articles, Developer Zone articles, and community examples (found at ni.com/support). For resource related conflicts, this KnowledgeBase article is particularly good:

http://digital.ni.com/public.nsf/allkb/485201B647950BF886257537006CEB89?OpenDocument

I hope this helps! If you encounter future problems, the forums are a great way to get peer input &/or response from NI engineers.

Courtney L.

Applications Engineer

National Instruments