I have 3 off PCI 6602 counter cards. Is it possible to route the gate of counter 0 to the RTSI bus?? I’m using daqmx vi’s and believe I need to use the daqmx export signal vi but not sure how to configure it.
It is possible to route the gate of counter 0 to the RTSI bus. But, if you are using DAQmx, you should be able to simply pull the signal you want from another device, once you have your RTSI cable configured in MAX. (ie-you can set your start trigger on Dev2/ctr0 to Dev1/PFI38).
I managed to achieve what I needed in the end using a daqmx channel property node to define the source of the counters, which then seems to make the initial counter selection redundant (even so, I still have to choose a counter for each channel which I don’t understand!)
I needed to use the start trigger for another external signal to synchronize the two counters, but it pointed me in the right direction – many thanks Gus!!
What I can’t do now is get my counters to reset their count after each sample so that I can compare duration. i.e. 30, 30, 30. All I can get is 30, 60, 90. I have attached a snippet of my code.
In order to have the count reset on each sample, you need to change your application to do period measurement. There are a few other things you'll need to do as well. First, on the Period Measurement Create Channel VI, change the units to "ticks" (the other settings should be fine as their defaults). Rather than using the CI.Count.Edges.Term, you should be using the DAQmx Channel->Counter Input->General Properties->Counter Timebase->Source. Change your Timing VI flavor to "Implicit" rather than "Sample Clock". If you are using non-default pins for "Gate1" and "Gate2" you can use the channel property node to use a different input (DAQmx Channel->Counter Input->Period->Input Terminal). Lastly, instead of using the Counter 1D DBL NSamp Read, you should use the Counter 1D U32 NSamp Read. What this basically does is it configures the counter to perform a period measurement with an external timebase. So the measurement you are receiving is the number of ticks of the timebase source between active edges of your GateX signal. Let me know if you have any problems configuring this.
I made all the changes you suggested. But I get the error:
‘Counter timebase rate must be specified for external counter timebase sources in order for frequency and/or time calculations to be made correctly. Set the counter timebase rate property to the appropriate value for your external source’.
Everything you suggested seems to make sense in my head, but is this error caused because the channel is set to period, and therefore trying to calculate a time period even though the units are set to ticks??
The problem that I have with setting the timebase rate is that it can vary anywhere from 0 to 450KHz
Surely labview should be able to look at the external ticks and be able to calculate it??
I’ll try a few ideas I have and post again if I have any joy, but any ideas you have will be greatly received!!
If you are unable to work out the problem, it might be helpful to post the modified VI which generates the error. If you do this, I can easily reproduce the problem and give some suggestions for solving it. It's probably something fairly straight forward, you may have missed!
Sorry for the late reply. What version of NI-DAQ are you using? I believe there was a problem related to this issue in NI-DAQ 7.2 that was fixed in 7.3, but I'm not positive. A workaround for the timebeing is to simply set the counter timebase rate to 100 (or any arbitrary number). Since you are reading data in ticks, it the calculations that would be made based on the timebase rate don't affect you. Additionally, since your external timebase may be slower than the input terminal, you also need to enable Duplicate Count Prevention, which is located in the channel property node under "Channel>COunter Input>General Properties>More>Advanced>Duplicate Count Prevention" (sorry if that path is not correct, I don't have LabVIEW with me currently to verify).
Setting the counter timebase rate to an arbitrary value gets around the problem I had (Error 200143). The code then runs, but with frequent erroneous results, so I set the duplicate count prevention property to true which solved the matter.
The above were tried with NI-DAQ 7.2 installed. I haven’t got round to proving if this is fixed in version 7.3.
I have attached a snippet of the final code I used to get the data I needed, which may be of use to someone else as this subject isn’t well documented anywhere.