Timed Data Acquistion

[sam.ferguson]

I have written a LabVIEW program that reads a serial device and then logs the output.  I chose to use the event structure along with message ques in my program.  I have the program reading the serial device during the "timeout" case of the event structure, which I have set to 5ms.  Looking at the log file it appears that the time stamp varies anywhere from 5ms to 17ms.  I knew from the outset that the data acquisition would be at different intervals using the timeout case of the event structure.  My question is this: Can I get a repeatable data acquisition interval using a different method? If so, what kind of time resolution would I be looking at (1ms, 5ms, etc.)? 

Thanks for the help!

[Bob_Schor]

The problem might be that you are trying to do a "deterministic" task, that is, take readings at a known, accurately-timed interval, but are doing it on (a) a Windows machine, which is not a deterministic OS, (b) using a serial interface, where there are a variety of things that can influence the transmission rate, and (c) there may be other time-consuming processes competing for CPU resources.

You can ameliorate some of these issues by doing your best to make the data acquisition (serial reads) as "deterministic" as possible, and getting everything else out of the way and in its own parallel loop.  One way to do this is to use a Consumer-Producer architecture, and to make the Producer (your Serial Reader) run at a higher priority than your Consumer (the logger).

Write your Producer in its own sub-VI and make it do nothing except read from your Serial device, creating a message and a time-stamp.  You can time this using a Timed-Loop structure.  Create a named Queue (call it "My Data Queue", if you want) outside the loop, and put your data (probably a cluster of TimeStamp + data) on the queue.  Look at the Properties of this VI, and set Execution priority to High (or at least Above Normal, so it has priority over the Consumer Loop).

Now (perhaps in your Top Level program) write the Consumer.  It, again, creates the same named Queue, but its While Loop dequeues the data (as the Producer produces it), and its only responsibility is to log it (or display it).  Because the two loops are separated, and the Producer is running (a) independently, and (b) at a higher priority, the timing of the data points should be minimally affected by whatever you do in the Consumer code.  You still need to deal with Windows jumping in occasionally (virus scans, e-mail notices, etc.).

BS

[Akiel]

i managed to get reasonably reliable tiings (given i was on a windows machine) by using a reliable timing source on a pxi card to as the timing source for timed loops, not while loops. I was running  a producer/consumer setup (get data in one loop and put on queue and process etc in another loop(s). the timings were ok on the simulation setup but are good on the actual rig. (some of the code was fpga as well which helped)

[sam.ferguson]

Okay, so basically it sounds like an ideal setup would be a non-windows based machine running the LabVIEW program.  Is this what the cRIO and other real-time targets are used for? (I'm new to NI products)

[Kilometers]

The main point of using LabVIEW Real-Time with a real-time target is for deterministic execution. With such a set up LabVIEW has control of priorities of processes on the entire system allowing for an extremely limited amount of jitter. On a Windows, or other standard operating systems, LabVIEW only has control of priorities of LabVIEW processes. This means Windows can decide a system update, a virus scan, or any other process is higher priority than your LabVIEW code and cause an unbounded amount of jitter. 

You can find out more about deterministic execution in these two articles, Creating Deterministic Applications (Real-Time Module) and Creating Deterministic Applications Using the Timed Loop (Real-Time Module). If you have further questions about using Real-Time and applications that are best suited for it I'd recommend posting in the Real-Time Measurement and Control Forums. There is also a training course, LabVIEW Real-Time 1, that addresses these questions if you are interested.