05-29-2012 11:10 PM
Playing around with labview and I have a m-series device and a counter device with RTSI. Anyways, my VI runs, but my array size keeps fluctuating around +/- 10 around my 6000 samples per packet. I need it to consistantly be 6,000 samples. 6281 is always outputting the desired 6,000 array, but the 6602 which is using the ai/sampleclock from the 6281 via the RTSI is not outputting the desired array length. Tried scanning the example files which have info on how to multi-device sync two counters or two m-devices, but not both. Am I dealing with a sync problem, and how do I fix it?
05-31-2012 08:02 AM
It shouldn't be an issue with your synchronization, if you sync two counters, it should be doing the same as syncing your two M Series devices. I'm guessing your second device is not capable of being that accurate or that you have improperly synced your counters.
05-31-2012 01:20 PM
Bit of a wild guess in absence of code, but this sounds like the kind of thing that can happen on hardware-synced tasks by not being quite careful enough with the DAQmx Read function.
1. Are these continuous tasks where you want to read exactly 6000 samples per loop iteration?
2. How are you timing the loop(s) that contains these read requests?
3. Are you requesting 6000 samples explicitly from either or both tasks? Or are you relying on
requesting "all available samples" (by wiring a -1 or leaving unwired) on one (or both)?
To me it *sounds* like you might be explicitly requesting 6000 samples from the analog task and
then requesting "all available" from the counter task. Sometimes, the time that passes between
those two reads is longer, so you get >6000 samples from your counter task. If the next iteration
has a smaller time between those reads, you could get <6000 samples from your counter task.
05-31-2012 01:31 PM
Here is the VI that was developed using 1 pulse per rev. I acknowledge it is messy. Take a ganeure at the outside of the while loop. The problem manifested itself here too. All I want is to export my data, and it is not able to because of the different lengths of the arrays.
06-01-2012 04:53 PM
Yup, sure enough, you're explicitly requesting 6000 samples from the AI task, while leaving the counter task to the default behavior of "read all available samples". Wire that same 6000 value down to the counter task and you'll solve the problem you mentioned.
Now let's solve a problem you didn't notice yet. First a brief review: You've synced your tasks to the extent that they both sample off a shared hardware
signal. Fixing the Read problem above will get you closer. The other step you need is to make sure that both the AI and CTR tasks take their *1st* sample at the same time. Then all other samples and reads will stay in sync.
All you've got to do is make sure you start the CTR task before the AI task. Since the CTR task uses the AI sample clock, it won't be able to take any samples until the AI task is started. Then they'll both take their 1st (and all subsequent) samples simultaneously. You can use the error wire to enforce the sequence by dataflow by routing down to the CTR Start before routing back up to the AI Start.