synchronizing USB 6351

[JThorus]

Hello,

I have a question related to synchronizing two USB 6351 DAQ boards. I routed the sample clock and a start trigger from one device to the other (as in the attached picture of the code), and ran the program successfully with the devices synchronized. However the acquisition tended to cut out unexpectedly. I noticed that the second device will stop acquiring data specifically when I turn on various instruments or even flick the lights on and off in the van where I'm working.

So this might be a difficult question, but is there any way to make the signals more reliable? Maybe I need to use a different cable to connect the PFI lines between devices? I've also noticed I can change the sample clock output behavior to either 'Pulse' or 'Level' - any chance one of these would work better than the other?

I should also mention that I was able to successfully route a signal from a 555 timer IC to each device as a sample clock and start trigger, but observed the same problem when running the program.

Thank you for your time!

Jeff

 ps please be patient with me as I am a civil engineer and will do my best to provide any additional details necessary! 🙂

[jred101]

Hi JThorus,

The synchronization works fine, but I see that you are using a a secuence structure to start the tasks at two separate moments. Also, can you please attach a screenshot of all of your block diagram, beacause we can only see your channel configuration and timing.

Please take a look at the following website since it shows different examples on how to synchronize and acquire data from different devices:

http://www.ni.com/product-documentation/4322/en/

There is a zip file where you can find example VI's.

[JThorus]

Hi jred101

I use the sequence structure to make sure the task on Dev2 starts first, so it is ready to receive the start trigger from Dev1. It looks like on the site you suggested 'Timing and Synchronization Features of NI-DAQmx' I could accomplish the same thing by error handling. So maybe I can use error handling instead if that is the recommended method.

I attached the VI (Labview 2011 version) so you can see / work with the whole diagram. (I have some sub VI that make sure the correct calibration factors are applied to the measurement on each channel; I don't think it is necessary to attach all those.)

I noticed also on the site (in Section 9) how easy it is to synchronize two devices with the RTSI cable. I tried to get my supervisor to get devices with this capability but he insisted on the USB devices as we work outside and move the devices around often. I don't believe you can add a device to a cable connected to a USB 6351 - is this correct?

Thank you!

Jeff

 

[jred101]

Hi JThorus,

The error handling in this case can also be used to make a function node execute before another one, we recommend this when using the DAQmx functions. Regarding the calibration of the measurement, it depends on your application and if you consider it necessary. Finally, the USB does not have a RTSI connection, this type of communication is used mainly in PCI cards.

[John_P1]

---

I noticed that the second device will stop acquiring data specifically when I turn on various instruments or even flick the lights on and off in the van where I'm working.  

So this might be a difficult question, but is there any way to make the signals more reliable? Maybe I need to use a different cable to connect the PFI lines between devices? 

...

I should also mention that I was able to successfully route a signal from a 555 timer IC to each device as a sample clock and start trigger, but observed the same problem when running the program.

---

It sounds like a grounding / power problem to me.  Could you briefly describe how everything in your van is being powered?

---

I've also noticed I can change the sample clock output behavior to either 'Pulse' or 'Level' - any chance one of these would work better than the other?

---

No, you'll need to keep the behavior set to "Pulse" which is the default.  "Level" would effectively give you half the sample rate (the output line would toggle state every sample clock rather than issue a pulse).

Best Regards,

[JThorus]

Thanks all for the responses. Will be sure to set the sample clock to pulse.

We power the instruments measured by the two USB boards with an AC-DC (12 V at 2 A) power converter. I hooked up a voltage regulator (9V, 1 A) as in the attached picture 'regulator.jpg' and measured the output or regulated voltage overnight, shown in the picture 'regulated voltage.jpg'. I think the instruments only draw a few tenths of an amp. I noticed some irregular spikes in the regulated voltage which might be causing the problem.

I'm not sure if the spikes are caused by the converter-regulator setup or the AC power in the van itself.

We also run an extension cord from the van power to a motor controller by the test location. Interestingly I have observed the acquisition cut out when I turn the motor controller on. So maybe the power in the van is not grounded properly? I am pretty far out of my element here, but hopefully that observation helps!

One other idea I had was to perform the acquisition with the devices synchronized at a location OTHER than the van. Might help determine if the van power is the problem. My other hypothesis is that performing multiplexed sampling on the DAQ boards allows cross talk or ghosting to corrupt the timing signals. Any merit to that idea?

Thank you for your time!

Jeff