Synch VISA data together with Multi-Function-Synch AI-AO

[Guntis]

I would like to simultaneously take measurements of 2 different sorts (from different devices):

a/ standard AO-AI (using NI-dacq board's hardware timing), and

b/ data from device being read using VISA (measuring device interface is USB).

The measurements that occur simultaneously are then to be merged into a multi-channel waveform data point.

[tbd]

---

Guntis wrote:

I would like to simultaneously take measurements of 2 different sorts (from different devices):

a/ standard AO-AI (using NI-dacq board's hardware timing), and

b/ data from device being read using VISA (measuring device interface is USB).

The measurements that occur simultaneously are then to be merged into a multi-channel waveform data point.

---

Hi Guntis,

      Does this mean you want to make a single measurement using device "a/" and at the same time read a single measurement from [USB] device "b/"?

Is the USB device a National Instruments device (which one)?

There will be a time difference between when value "a/" and "b/" are measured, though, the difference might be made relatively small depending on triggering options.  If both devices are from NI, then I think measurements can be synchronized more easily.  If the USB device isn't from NI, does it have an "External Trigger" option?  If the time difference between value "a/" and "b/" is 0.1 seconds, is that good enough?

Cheers!

[Guntis]

Thanks for the response.

To clear things up (I used the word device in an ambiguous way):

This is a compression test of a large specimen that needs deflection measurements at several locations.

I have a controller (signal conditioner) that can handle 3 signals but not 4, and I need 4 signals (for this reason I cannot use 2 more LVDTs).

I will use this signal conditioner to handle a load cell and a LVDT signal which feed into a NI board (E-series).

I would like to use 2 digital indicators (Starrett) with USB interfaces for 2 channels of displacement data.

I have been able to set up a vi  that reads the 2 digital indicators (USB ports) continuously by using VISA write and read in a loop.

I am looking for a way to simultaneously use AI read (hardware timed), and read the USB ports.

Timing is not a huge problem since I'm looking to capture 1,024 data points in 30 seconds (although this is faster than 0.1 second).

To sum this up, I will use a NI board for load and LVDT signal capture (as well as controlling the test), and 2 USB devices (non-NI) for displacement measurement capture.

[tbd]

Thanks for the clarification.

While 30Hz (roughly) would be a snail's-pace for the NI DAQ hardware, synchronizing the USB measurement(s) with each AtoD makes this more work.  In the absence of an external trigger on the Starret, I think you'll want to:

 - code a multiple-channel/single-sample DAQ Read in parallel with calls to each USB device, and

 - put this logic in a loop that iterates every 29ms.  What version of LabVIEW are you using? - "Timed-loops" (available after 7.1) are very convenient.

I don't know how quickly the Starret returns a measurement(?) - this will affect how closely USB measurements are synchronized with each NI DAQ AtoD.

I could rough-out some code using DAQmx (don't have traditional NI DAQ installed here)  Whether using NI-DAQ or DAQmx it's best to configure a "task" once and have a simple DAQ "Read" inside the loop.  The loop can pass-out a 2D-array (AKA "table" ) where each Row contains both the NI and Starret measurements.  This 2D-array can be graphed and/or saved to disk using VIs that ship with LabVIEW.

Would you like some help "roughing-out" the code (are you using DAQmx...)?

Cheers.  

[Ben]

I really think adding addional hardware to avoid the serial interface all together should be seriously concidered.

But if you really want to do this I'll outline how I did this about 7 years ago when CPU were running at about 400 MHz.

The system I was monitoring and controlling was a jet aircraft simulator that simulated an engine to a new design of fuel pump*.

I had to monitor all of the DAQ and log it to file and at the same time query and log the internal states* of the Fuel Pump.

So I used a DAQ process on a Windows machine to gather and log all of the analog signals. These signals were queued up to a dedicated DAQ logger that kept the disk updated.

Meanwhile...

THere were two other background process both watching unique com ports and grabbed the packets coming in as fast as they were recieved. As was the case wit the DAQ these values were queued up to background logging threads.

To keep the serail data "pseudo-periodic" I used a coulple of threads running on an RT target to query the serial port data.

Out-of-the-box approach:

THe serial cables going to the fuel pump controllers was a custom build where the send lines (the lines send the query to the pump) where wired to the RT box while the recieve lines (lines on which fule pump responds) were wired to the Windows machine.

After a test was complete post processing code merged the three files (DAQ plus two serial) into a single file.

I would think that you could duplicate this approach (but eleminate the req fro an RT machine) to achieve the same effect.

I hope that gives you some ideas,

Ben

* A variation on that fuel pump is now flying in the new Joint Strike Fighter.

** States plural, there where two controllers just in case the primary failed dring flight.

[Guntis]

Thank you tbd and Ben for your ideas.

tbd

I appreciate  your offer to rough out some code using timed loops.

I have not used timed loops before, and any help is greatly appreciated.

Ben

New hardware is not the first option at this time.  Like everyone else, we're under a budget crunch.

I am using LabView 8.5

[tbd]

Hi Guntis,

      Here's one way to approach the application using Timed-loops (mentioned above.)  DeflectionTest.DAQ.vi can be called as a top-level VI for debgging.  DeflectionTest.vi calls DeflectionTest.DAQ which runs until complete, or Abort is pressed - whichever comes first.

Warning/Caveat: Timed loops, while convenient, allow only ms resolution on loop-period (assuming non-RT target) and your application requires ~29.296 ms ideally.  In this example the 1024th measurement(s) will occur at t=29.667 sec  (1st measurement is at t=0.)  If this is an issue, loop period can certainly be made more precise with a different approach.

Without the hardware, this is a completely untested example offered to help convey some basic concepts.  

Cheers!