Timing Issues

[Scram]

Hi everyone,

I am writing a Labview code to control a set of valves, record some temperatures with a set of thermocouples, record some pressures, and finally control a sparkplug by sending a very specific type of square wave signal (specific frequency and duty cycle). Before I go into the details of my problem, this is the equipment that I am using:

LabVIEW 2011

CDAQ - 9188

NI 9401 - used to control (open/close) 8 valves

NI 9269 - analog output module used to send the square wave for the sparkplug

NI 9264 - used for the thermocouples

NI 9205 - used to measure pressures

I am trying to do all the above simultaneously but each sent signal is timed with respect to a clock (Time Elapsed VI) which is displayed on the Front Panel as seen in the Heater Controls 7 VI attached. Initially, I created one large while loop to do all this but I started to have problems because the time display on the front panel would not update continuously. In other words, it seemed like the while loop was taking too long to finish up and by the time it did, a certain amount of time had elapsed which delayed the digital display update. That was my theory at least. So I decided to create two loops, isolating the DAQassist for the analog output module that sends the square wave into one loop and having a Time Elapsed VI on each loop to control the timing of the signals. This seemed to improve the code as the time update on the Front Panel was smoother, but then I realized I had another problem. By connecting an oscilloscope to monitor the square wave signal sent by the NI 9269 I realized that the signal would not stop on time, that is once the runtime (user defined) was up. The stop delay seemed to be random and went anywhere from 0.5 sec to 4 sec. At that point I thought that the issue might be that the loops where not starting simultaneously and so I decided to pass an error function through both loops to force them to start at the same time. I decided to compare the time  display of both loops and also the iteration index of both and I noticed how the small while loop would start running fine at first, then stop at some random point, wait for some time, and then update again. By the time it did that last update, the runtime for the square wave was up, and so the signal would be shut down late.

To recap, I need the display of the time elapsed in the front panel to update smoothly just as a normal stopwatch would do and not get repeatedly stuck as the program runs. More importantly, I also need my square wave to be stopped on time once the runtime is up, and not have this erratic behavior that I am having now. This is crucial for my application since this square wave controls a sparkplug used to ignite a combustible mixture.

I don’t know if there is something fundamentally wrong with my code or if these issues have something to do with the CDAQ/ modules that I am using. I am pretty new to this software and I am trying to learn how to use it. Any help, suggestion, comment would be greatly appreciated. Thanks for your time. If you need any clarification or you have any question please let me know. Attached are the VIs and subVIs.

[NEWKlear]

Scram,

I took a look through your code, I think the issue is using the write to measurement files inside of the while loop.  With the current set up, everytime the while loop iterates the Write to Measurement File VI is opening a file, writing one value, then closing.  That takes a bit of time to do and could be what is slowing down your system.  The only other real overhead I see in the code are all of the DAQ Assistant Express VI's.  They are known to be less efficient than manually setting up DAQs, however I think the DAQ VI's have far less overhead than all of the File IO VI's.

Regards,

[Bob_Schor]

It is a challenge to figure out what you intend to do because almost everything is in a single VI, with wires everywhere.  This makes the logic that you intend to follow unclear.  One good way to fix this is to "encapsulate" functions by putting them in a sub-VI, which will make the top level VI much simpler and easier to analyze and understand.

One thing to realize is when you have everything in a single loop, it runs as fast as the slowest thing in the loop.  If disk reading and writing takes place in the loop, along with data collection, the variability in disk i/o can well lead to variability in loop timing.

Another thing is that Windows is not a real-time system -- all kinds of things are going on "under the hood" in Windows that can steal time from your application (over here, we have anti-virus software that periodically likes to force yet another scan of the system).

One thing that LabVIEW has going for it is that it is that parallel loops can run ... in parallel.  You can have a While loop generating your data, running at its own speed, and putting the data into a queue.  In another loop, you can be reading the queue, and if it has anything in it, writing this to disk.  As the data acquisition loop knows nothing about disk i/o, it won't be "blocked" if the file system takes extra time opening the file.  Similarly, the disk i/o loop will not take any CPU time if there's nothing to write, as it is waiting for something to appear in the queue.

This pattern is usually called the Producer/Consumer pattern.  If you open a new VI by going File, New ..., you can see, under Frameworks, the Producer/Consumer Design Pattern, which should show you how this works.

[ben64]

To add to the other comments you should also make the solenoid and calibration vis reentrant.

Ben64