LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Data logging freezes based on System inputs

I'm using Labview to record 30s of data during a testing procedure. The program is setup using a state machince and the following steps:

1.) intialize - sets up test values and file names 

2.) idle - displays relevant data in real time to user on a main front panel and waits for a certain pressure to activate logging or for a user input

3.) Logging- logs data to a .tdms file

4.) Stop - closes out all files and ends the state machine 

 

The issue I am having is that during the logging state labview will freeze up between 3 and 6 seconds into the logging. The strange part for me is that this only occurs during the high pressure operation of the unit being tested. I have successfully logged data at pressures below the test pressure, and  labview also unfreezes when the pressure drops back down. I have attached an image of the logging state. Any help would be appreciated.

0 Kudos
Message 1 of 9
(3,333 Views)

The code is very messy, how about hitting block diagram cleanup and posting another picture -- or better yet the code itself...

 

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 2 of 9
(3,319 Views)

 

I have attached a cleaned up version.

Its a large project with many sub VI's, I didn't think it would be practical to post all them. I like to keep the code on one screen so I don't have to scroll and the clean up expands it too much for my liking. 

0 Kudos
Message 3 of 9
(3,306 Views)

I do not see anything obvious as a cause of freezing. Since that loop runs for about 30 seconds it is not clear how you know it is "freezing." Exactly what do you see happening (or not happening) when it freezes?  

 

I would probably eliminate that loop. Stay in the "Logging" state for 100 ms. If the 30 seconds have elapsed, then write to the TDMS file.  If not, then repeat the Logging state for another 100 ms. Actually I would split that into two states, one for acquisition and one for writing to file.

 

Use of local varaibles to pass data creates extra copies and may be prone to race conditions. They are rarely needed in state machines.

 

Lynn

0 Kudos
Message 4 of 9
(3,290 Views)

@johnsold wrote:

I do not see anything obvious as a cause of freezing. Since that loop runs for about 30 seconds it is not clear how you know it is "freezing." Exactly what do you see happening (or not happening) when it freezes?  

 

I would probably eliminate that loop. Stay in the "Logging" state for 100 ms. If the 30 seconds have elapsed, then write to the TDMS file.  If not, then repeat the Logging state for another 100 ms. Actually I would split that into two states, one for acquisition and one for writing to file.

 

Use of local varaibles to pass data creates extra copies and may be prone to race conditions. They are rarely needed in state machines.

 

Lynn


In regards to the freezing and the local variables; I know it is freezing because I have a Progress Bar and the local variables are used to keep the GUI the same throughout the states. For example the local variable "Pressure" is a real time graph of the current pressures in the system. So when the program freezes the progress bar, all graphs and gauges stop working (no change in values or time on graphs).

 

I'm not sure how I would avoid local variables in this situation. Also wouldn't using a state machine eliminate any race conditions as long as the same variable isn't used twice in the same state?

 

I'm not sure I fully understand your idea to only use the logging loop for 100ms. I'm looking to collect all data over 30s, without creating a buffer I think I have to continuously log as the data is read from the DAQ.

0 Kudos
Message 5 of 9
(3,267 Views)

An independent verification of the freeze would be to place an indicator on the "i" terminal of the inner loop. If that stops incrementing, then the loop has certainly stopped.

 

As for race conditions and state machines, the answer is "it depends..." If there is other code running in parallel, then the possiblity of race conditions certainly exists. We cannot see that from the image of part of the code.

 

Here is a simple example of how to repeat a state. This state machine starts in the Idle state and goes to the Logging state. It repeats the Logging state until Max Count is reached. Then it goes to Other state where it repeats until Restart Logging or Stop is pressed.

 

Lynn

0 Kudos
Message 6 of 9
(3,241 Views)

I have placed an indicator on the "i" terminal of the inner loop. It stops incrementing at 31 iterations fairly regularly, sometimes reaching 60.

The issue I'm having is not, is it stopping?, its why does it only stop during certain tests, specifically tests with high pressure/vibrations when these inputs should not affect the program only the data.

 

Thank you for the example, my code is very similar to this.

State machine starts in an initialize state (setting up parameters and variables) moves to an idle state to await the conditions required for logging. Once the conditions are met it moves to the logging state. It remains in the logging state for 30 seconds then the state machine basically resets  by returning to the initialize state and preparing for subsequent tests.

0 Kudos
Message 7 of 9
(3,237 Views)

Notice that my example does NOT remain in the Logging state for 30 seconds. It is in that state for a few milliseconds and then repeats that state many times until the maximum count is reached. This way the program does not need to wait 30 seconds if someone presses the stop button just after entering the Logging state.

 

Back to your debugging. Since you have a fairly predictable condition (31 iterations and high pressure) where it misbehaves, set a Conditonal Probe on the iteration count. Set it to stop one iteration before the freeze (30). Then turn on Execution Highlighting and see if that gives you any clues. This slows things way down and messes up the timing but can be a powerful way to find out what is happening. You may need to experiment with the conditional settings. Breakpoints can also be useful.

 

In your initial post you indicated that it unfreezes when the pressure comes down. I would look at every place in your program which does anything with the pressure data to see if you can find anything strange. Also place temporary error out indicators on every error wire in that logging loop.  Some error may be causing problems but then is cleared when the "thaw" occurs and the Simple Error Handler never sees it.

 

Lynn

Message 8 of 9
(3,232 Views)

Great I didn't even notice that, I have a few of my other states with while loops as well. I've been using a local variable "Exit" to allow ending all these while loops but your way seems much more simple. Thanks for the tips I will look into your other suggestions as well.

 

 

0 Kudos
Message 9 of 9
(3,224 Views)