LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Advice on restructuring code to prevent slowdown over time

Solved!
Go to solution

Hi there, I am a new LabView user looking for advice on how to better structure this program I wrote that is used to run a hydrostatic test fixture. Data is collected on a cDAQ 9207 AI module and a cDAQ 9474 DO module is used to control two solenoid valves which subsequently controls pressure into and out of the test chamber. I have attached my initial version of the code for reference. 

 

What the VI is suppose to do is when the user arms the system and subsequently hits the run switch, the program will transition the test chamber through several states corresponding to different pressure levels for certain durations. The pressure vs time plot is written to a measurement file. I built this using a state machine structure.

 

My problem is, during initial testing, when the test duration was roughly 5 minutes or so, the program ran fine. However, once I started testing at actual test duration of 2.5 hours, I noticed the program running slower and slower as time progressed to the point where it would take several seconds for each loop iteration and eventually crash about an hour or so into the test. After scouring articles and posts, I suspect the primary culprit is the waveform chart and to a lesser extent the DAQ assistant. 

 

While I need the data collection and case structure loop to run relatively rapidly (preferably on the order of a few hundred S/s) as I need the code to be able to react to changing pressure in the chamber pretty quickly, the actual data I need to store and display on the chart can be as slow as one sample every second or even longer. My guess at this point is I should rebuild the program using a some sort of producer/consumer architecture so I am looking for some advice on how best to structure the program.

 

The data acquisition obviously belongs in the producer loop that'll run at a pretty fast clip and there will be a consumer loop that will run at a much slower rate for the chart display the write to measurement file vi, but where should I put the case structure state machine that currently controls the valves? Should that be put in the producer loop since it should run at the same fast rate as the data collection so it can react to changes in pressure or should I build another consumer loop for it? What about the other indicators (pressure and bolean) and controls on the front panel, should they be on another loop running at some intermediate speed as I want them to react at a faster rate than the chart/data write loop but they don't need to be as fast as the DAQ loop? 

 

Finally, I am not quite sure what the best way would be to reduce the sampling rate of the data that I actually display on the chart and store into file, it wouldn't make sense to create another measurement task that samples at a lower rate just for that purpose. Any suggestions and advice would be greatly appreciated! Thanks in advance!

 

Bob

0 Kudos
Message 1 of 5
(2,220 Views)
Solution
Accepted by topic author daBub

My guess is that if you monitor memory usage over time, you see that going up as well, yes? While is is always a good idea to get rid of the express VIs, I would look for the slowing problem in the case structure. You are repeatedly opening and using some DIO channels without ever closing the tasks that are being created. Hnece each time through the loop more memory is allocated. Try moving the create channel VIs outside the loop so the tasks are created once before the loop starts and then written to as needed inside the loop - and don't forget to clear the tasks when the loop finishes.

 

Mike...

 

PS:You are right with your comments concerning the producer consumer architecture. Basically break it up such that the stuff that needs to happen quickly (the DAQ IO) is in one loop, while the user interface and stuff that can take a while (like data logging) is in another loop. You might even want to have three loops by having one for the DAQ input and a second for the Digital output.

 

PPS: Finally remember that while the producer consumer structure is typically shown with everything in one diagram, it doesn't need to be so. I have written many where each loop is in its own VI that is launched dynamically then the application starts.


Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
Message 2 of 5
(2,201 Views)

I went back to that code and moved the create channel VI's out of the loop and performance increased dramatically. While the cycle rate still could be improved, at least it stayed consistant throughout the 3 hours of testing and allowed us to do some testing of the rest of the system. I still plan on rewriting the code using producer/consumer architecture and still am wondering what the best way would be to reduce the sample rate of the data that I am actually charting and recording, ie. record/display every 100th data point? Thanks for the tip!

0 Kudos
Message 3 of 5
(2,187 Views)
Getting rid of the express VIs will be a major help too as they are very inefficient inside a loop. You see each time they are called the open a reference to what they are going to do, complete their task and close the references.
To see what they are doing internally right click on each one and select the Open Front Panel option. This converts them into normal VIs that you can look at and edit.

Mike...

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 4 of 5
(2,178 Views)

Have a look at the following article, helped me alot

 

optimise memory usage

 

Hope it helps

 

TD

Please remember to accept any solutions and give kudos, Thanks


LV 8.6.1, LV2010,LV2011SP1, FPGA, Win7
0 Kudos
Message 5 of 5
(2,169 Views)