12-06-2006 09:34 AM
12-06-2006 01:01 PM
I only use LabVIEW so I can't help with VB or CW syntax. However, I do know the 660x family has limited signal routing abilities. In general, any PFI pin that's a default Gate pin for any counter can be used as a programmed Gate signal for any other counter, but other PFI pins can't.
In your case, PFI 31 is listed as Counter 2's default Source pin. Try wiring and configuring for PFI 30 (pin 67), which is Counter 2's default Gate. Hope it works!
-Kevin P.
12-14-2006 10:28 AM
12-14-2006 11:21 AM
Apparently, it's the driver. In general, DAQmx makes it easier to route timing signals, handling more of the grunt-work behind the scenes. It also has extended the range of routings allowed, such as the case you've discovered.
An old trick I used to use in traditional NI-DAQ was to explicitly route a signal up onto a RTSI line and then configure my task to use that RTSI line as a Source or Gate or whatever. When I did it, I was typically routing a pulse train output or an analog sample clock signal. I'm not certain, but there *may* be a way for you to do such a routing from PFI to RTSI even on an input pin. I recall that this indirect routing allowed me to program some things I couldn't have routed directly, but I'm not sure if I ever routed an input PFI to RTSI. I can only vouch for routing counter outputs.
If you explore your device under MAX, there's a tab or menu option somewhere to define valid and invalid routing combos.
-Kevin P.
12-19-2006 06:21 AM
12-19-2006 10:47 AM
Because your PFI pin is typically used as an input, I'm not certain that traditional NI-DAQ will allow you to route it to RTSI. Since I only know LabVIEW, I also don't know the syntax you'd use to try. In LabVIEW, there was a function named "Route Signal.vi" that I used, maybe you could look for a similarly named function?
Then again, why not just go ahead and use DAQmx where you've already demonstrated functionality?
-Kevin P.