07-11-2012 12:49 PM
I want to disable the output of a counter on a USB DAQ device. I have several different stimulation protocols, some of which generate pulses (used to trigger different hardware) on both counters (0 and 1). I also have one protocol which generates multiple pulses from counter 0; this implicitly uses counter 1, which means I can't generate any pulses on counter 1 with this protocol. The problem is that when NIDAQmx configures counter 1 to count the pulses from counter 0, it leaves the output of counter 1 connected to its typical output pin, PFI13. This means that I get an unintended pulse on counter 1. Short of asking the users to disconnect some hardware before running the multi pulse protocol, is there a way to disconnect the output of counter 1 from PFI13?
With trad nidaq, I could connect ND_GPCTR0_OUTPUT to ND_NONE when configuring a counter to be used "internally". If I try to disconnect the output of counter 1 from PFI13, I get an error when I try to run the multipulse protocol, saying the routing of the counter 1 is not compatible with the routing alreay in use. My workaround is to connect counter 1 output to a "non-standard" pin, PFI0, say, and then disconnect it to run the multipulse protocol. But that is ugly. Am I missing something?
07-12-2012 01:55 PM
I think you'll find the answer on this post
Please post back if this doesn't help.
Cheers,
Andrew S
07-12-2012 01:58 PM
Thanks for the reply. All working now, I can disconnect pfi13 from ctr1 output, and reconnect it when I need it again, with no error messages generated.
jamie
07-13-2012 09:27 AM
Jamie,
Which specific calls do you use to disconnect & reconnect? What did you see w.r.t. the "lazy uncommit" Andrew mentioned in the thread he just linked?
I'm curious because it seemed like a task-based routing would be generally preferred, but in your situation, I didn't know of a task-based way to do it. You wanted to disconnect Ctr1Out, but the task's "CO.OutputTerminal" seems like it would refer to Ctr0Out. I didn't know of a task-based way to refer to the output terminal of the implicitly-necessary Ctr1.
So... were you able to do this in a task-based way? If so, how? If not, did you use the non-task-based method of connecting and disconnecting terminals?
-Kevin P