Counter/Timer

[jdb11]

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?

[stilly32]

I think you'll find the answer on this post

How to suppress counter output on default terminal ?

Please post back if this doesn't help.

Cheers,

Andrew S

[jdb11]

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

[Kevin_Price]

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