LabVIEW
Multi Device Synch AO Series via RTSI
Solved!
Thanks for your reply. Yes, I have added the cable to MAX (see image below - also tells you what AO Series device I have)
I am using 'No Trigger', so I assuming Dev1 is triggering, also going by the fact that the Dev1 Boolean goes green. Dev2 Booleen does not go green.
Thanks for the offer!! Here you go,
Gretchen
Looks familiar, right? Looks like the DAQmx Examples.
Here's the snippet
Assuming the "Enabled" case of your diagram disable structure just passes through the task handle and error wire, the software looks good (which is actually unfortunate, I was hoping it would be something obvious). You're not getting any software errors, right (the screenshot seems to indicate that you are getting no errors)?
As a troubleshooting step, could you try polling the Total Samples per Channel Generated property for Dev 2 inside your loop?
If the samples generated number stays at 0, Dev2 isn't seeing the clock at all.
- Check that the RTSI cable is plugged in all the way on each device (but you've probably already done this).
- Could be a bandwidth issue on the RTSI cable? The AO sample clock pulse is pretty narrow (2 timebase ticks I believe).
- Try unplugging all devices except Dev1 and Dev2.
- Try changing the AO Sample Clock Timebase (on the master device) to be 100 kHz instead of 20 MHz.
- Try running a counter output task at some moderate frequency (e.g. 1 kHz, 50% duty cycle) and use this signal for the AO sample clock on Dev2.
- Try sharing Master Timebase and Start Trigger instead of AO Sample Clock.
- Could be a defective RTSI cable? You could try a continuity check or connect a scope to it if you have the equipment.
If the samples generated number increments to some number (0 < N < 1000) then Dev2 is seeing some of the clock edges but missed some. Try the same steps as #2 above (bandwidth issue).
If it increments to 1000 then Dev2 saw all of the clock edges but the task isn't reporting that it is done. If this is the case, somebody from NI would need to look into whether there is a bug with Is Task Done? when using an external clock on the 6723. I don't have the hardware myself to check. If this is your scenario, the sample clock was received properly and all samples would have been generated so it's just a matter of finding another way to exit your loop (could use Total Samples Per Channel Generated for example).
If it increments to >1000... well this just wouldn't make any sense since Dev1 is only supposed to issue 1000 sample clock pulses. There would have to be noise on the RTSI line for this to happen in conjunction with a bug in DAQmx causing the Is Task Done? to not work with an external clock on your device.
Best Regards,
If you're consistently getting 999 samples then it's not a bandwidth issue (so ignore half of my previous post).
There's some bug or undocumented feature of the 6723 that's giving you this behavior. The device is pretty old and I'm not too familiar with its inner workings, but I'll take a wild guess and speculate that your last sample is sitting in the latch and requires an additional sample clock edge to push it through (if this is true, it would mean that the synchronization was actually off by a whole sample clock period!):
Instead of sharing a sample clock, I would configure your tasks like this:
This way each device will generate its own clock and do what it needs to output all of the samples. The tasks will start synchronously due to the shared start trigger and will not drift over time due to the shared timebase.
Best Regards,
