memory leak between primary display .vi, and cutting sub .vi?

[JimSchwendeman]

Hello All!

I am having a little bit of trouble with a memory leak in my setup, and thought someone might be able to suggest ways that I could troubleshoot this leak, or even spot potential errors.  A quick bit about the code:

The main .vi is just a instrument display, while the back panel allows the user to mix and match cutting and linear moves to perform the tests required.  The system is to evaluate cutter performance.  The cutting .vi is the only .vi that actually records data (to a .csv file), and I suspect where the faulty code is...

Any thoughts would be greatly appreciated, I'm stumped.  Even suggestions on how to troubleshoot this would be great!

Thanks!

.jim

[GerdW]

Hi Jim,

"I suspect where the faulty code is..."

Well, each of your "Cut"/"Move" has some race conditions inside because of those local variables... Why do you wire an error cluster to the subvi, when you also want to clear this error cluster input using a local??? All of your locals are accessed without any dataflow dependency - RACE CONDITIONS!!!

Yippie, found the classic Rube Goldberg code: a case structure outputting true or false depending on the boolean input of true and false, respectively (inside "CutX_2axis.vi")

The whole program depends on ActiveX component(s), how do you know for sure it's LabView leaking memory? As I don't have that special ActiveX component I cannot test your vi...

[JimSchwendeman]

Good catches on all!  (the Rube Goldberg case structure....  D'oh! )

I believe I had the clear error clusters in there when I was individually testing each .vi. 

I have heard your comment before: All of your locals are accessed without any dataflow dependency - RACE CONDITIONS!!!

I am still having a hard time understanding dataflow dependancy, particularly in regards to the local/global variables (I like to use them, and I sense that is bad).

I have heard that you should use only direct wires (avoid locals at all costs?!?), but it just gets too messy for me to work through the code then.

Thoughts (or examples that might concrete how to not make these mistakes anymore)?

I really appreciate the comments.

.jim

[johnsold]

It looks like you call the Move and Cut VIs repeatedly. Rather than stretch them all over the diagram, put them in a loop. Create arrays of the parameters and use autoindexing. Better yet, make the whole thing into a state machine. With a cluster of data passed around via a shift register the locals are easily eliminated and the race conditions with them.

The sequence structures in the subVIs are largely useless. The dataflow is all that is needed.

Do you really need to re-initialize the load cell (with a 5 second delay and 500000 samples) each time the CUt Vi is called?

Lynn

[JimSchwendeman]

I tried putting everything in an loop that ran x times, with everything passed through via shift registers, but this resulted in what seemed to be more frequent faults than I am receiving right now.  Thoughts on that?  I would love to have a clean loop instead of 20 subs all over the place.

Do the sequence structures take away anything in terms of computation/ data flow?

I suppose I don't need to re-initialize the load cell every time either (a initialize sequence is nice to have though).

Thanks!

.jim

[johnsold]

Jim,

What do you mean when you say "faults?" What errors do you get? With the number of local and global variables you have, the loop may be generating more race conditions.


The sequence structures are a means of enforcing ordering of execution. Generally dataflow can do the same thing. So wherever you have error wires or refnum wires connecting nodes, the sequence structures are unnecessary.

With a state machine architecture you would likely have an initialize state, several running states (mix, cut, others??), possibly one or more states for saving or displaying data, an error handling state, and a shutdown state. The initialization state would obviously be called at the beginning but could also be called again whenever the program determined that re-initialization was needed (if baseline drifted out of tolerance for example). Depending upon how much user interaction you have the whole program might be one state machine loop or a producer/consumer design pattern.

Some of the things in the Cut and Mix subVIs might be moved to separate states (like the initialization discussed above). Timing and waits are often handled more flexibly by the state machine directly than by incorporating them into subVIs. This is especially true if you need to implement a software controlled stop in the middle of a task.

Do you need the precision of a timed loop for the display update?

Lynn

[JimSchwendeman]

John,

Thanks for the reply!  When I say faults or errors, I'm referring to (usually) a communication error between labview and the CAN devices that I'm using.  I believe that this is related to a timing issue (i.e Labview 'hangs' for a little, the CAN devices don't see a response after x time and they fault out).  I have confirmed this with a CAN traffic analyzer.  My hypothesis was that something was causing Labview to slow down (memory leak) to the point that would result in a non-response to the CAN devices?  I don't know if that sounds reasonable, this is just not an issue I had before with a previous version of Labview....

Thanks for the recommendation of the state machine architecture.  I had implemented a similar configuration before, but I thought it would be too complicated to be able to modify the test type on the fly (mixing and matching the cut and move .vis), so I didn't go that route.

I don't need the timed loop for the display.  Should that just be a regular while loop?

Thanks!

.jim

[johnsold]

Jim,

A regular while loop for the display is fine. Any parallel loop should have a wait or delay function to allow CPU sharing. For display loops waits of 200 ms or longer are fine because the eye cannot track changes much faster than that.

The state machine architecture is exactly what you want if you need to change your test type "on the fly." You can specify the next test as an input - predefined, from a file, or from the user - and the state machine can go to the appropriate state(s) to implement the tests.

I do not know anything about CAN communications, but if delays may be causing the problem, set up a parallel loop which only communicates with the CAN bus. Send data to and from this loop via queues or Action Engines. Run this loop fast enough to catch all the communications. Slower processing can be handled in other loops without affecting the communications. Most of my state machine programs contain such parallel loops.

Lynn