First some very generic advice that's mostly stylistic, but hopefully still helpful.
- when using the same Gate config info for all 3 counters, use a single front panel control and let the wiring fork off to the 3 places. Ditto for the device # control and others that are necessarily shared.
- assign the most commonly used values to your config controls (Gate, Source, etc) then "save as default". The big boldface instructions are good, but having the vi launch with the correct values already in place is even better.
Now the more relevant thoughts along with the assumptions that drive them:
Synchronization
---------------
1. I expect you want all 3 counters to be referenced to the same t=0 point. You had a good idea to query the tick count that will be used as t=0 in the sequence frame immediately *after* programming a counter. However, there is no sequencing / data dependency that makes sure the other 2 counters are started as near as possible to simultaneously.
1a. Software timing. What you'd need to do is perform all the config operations for all 3 counters *except* arming them ('program' value fed to "Counter Control.vi"), then arm all 3, then capture your msec tick count. You can use the error cluster to tie together the various config chains and provide the sequencing you need. With this software-driven timing, you can probably get the counters started within several msec of one another. I'd suggest ensuring that all initializations and other stuff "floating" outside the main loop are forced to execute before the counters are armed.
1b. Hardware timing. The better approach would be to configure all 3 counters to be triggered. Then you would arm all 3 counters before providing the trigger signal (which could be generated by another counter or a DIO pin on your card). This way, they all have the exact same t=0 point.
Events relative to time and/or other events
-------------------------------------------
2. Your program seems to use an external gate signal, which acts as an acquisition clock for your measurements. Whatever the timing of that signal may be, you'll be storing the 3 count values on each active transition. You end up with 3 arrays of event counts, with each value corresponding to an active transition of your gate signal, but with no particular timing information. Is this what you need? Or could you more simply sample the 3 sets of count values at a constant rate?
2a. Hardware timing, constant sampling rate. This approach basically ignores the gate signal. Skip to the next approach if this isn't acceptable in your app. Set up a 4th counter to generate a continuous pulse train at your desired sampling rate. Route its output to a RTSI line. Set up other 3 counters to use that same RTSI line as their gate signal. Arm the 3 counters before arming the 4th. With this approach, the time of an event corresponds to its index in the final array, one element per sampling period.
2b. Software timing, external gate signal. Basic idea is to build up 2 separate datasets, possibly 2 separate files. One will hold all the raw count data from your 3 counters, each containing one element per active transition of the gate signal. The other will extract only the latest reading from each of the 3 counters each pass through the loop, and combine it with the elapsed msec tick count -- i.e., one element per software loop.
2c. Hardware timing, external gate signal, more tricky. You could configure a 4th counter for event counting off the same Gate signal but with the Source set to 100 kHz internal timebase. You would also need to explicitly set this one up to use interrupts instead of DMA for its buffering. I don't know the speed of your gate signal, but a ni.com search suggests that interrupts can often handle from speeds from a few hundred to a thousand Hz or more. If you go this route (sub-msec timing precision on measurements), you should definitely set up all 4 counters for hardware triggering.
In this approach, your 4th counter would be your time array, scaled as 1 count = 10 microseconds = 1/100 kHz. Then you would bundle up this time array with your 3 count arrays into a single dataset.
Better stop now. You can always check the shipping examples or ni.com for more info on such things as interrupts vs. DMA, routing signals to RTSI, triggering multiple counters, etc. Good luck!
ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
