labview freezes during FOR loop

[armchair_engineer]

I'm using a FOR loop to run a Keithley 2410 source-meter multiple times along with a pair of Velmex motors. In the middle of the "Current Map" loop, however, Labview freezes and starts using 25% of my CPU. I have used this exact same code structure with an Agilent 34972 and never had this problem. How do I fix this?

[Yamaeda]

My guess is that you're getting a greedy loop (you have 4 cores, right?)

You have a Local Variable of Thermionic that's set to False at the end of the case, thus all other loops will just spin wildly in the False cases. 

Since you have rather good Error wiring you can remove most of the Flat sequences without any difference to the function.

/Y

[Yamaeda]

Run it in Highlight mode and i'm sure it'll show you what's happening.

/Y

[armchair_engineer]

That local variable isn't part of the "Current Map" subroutine. Why would it be affecting the rest of the program?

[armchair_engineer]

And I did check the processor. I have four cores on this machine.

[armchair_engineer]

Alright, I have added time delays to the code in all of the relevant loops, and it still freezes early on in the execution. I've tried putting the delays in every possible location to no avail, and in some cases, labview freezes even earlier than before. I'm out of ideas now.

[johnsold]

Exactly what happens when it "freezes"? Or, how do you know it freezes?

If the rest of the code takes negligible time to execute, the 250 ms Wait in the last frame of the innermost sequence structrure will require >182 seconds to complete the nested for loops.  There are no indicators in those loops, so it would not be obvious whether the program was still running normally or not during those 3 minutes.

Try putting indicators on the "i" terminals of the for loops. That will tell you whether the loops are executing, and when it freezez, you will be able to see how many iterations have completed.  Also put error indicators inside the loop so that you can see if any errors are reported. Unfortunately the Velmex driver does not report errors.

Highlight Execution is useful for finding problems in code. But if the freeze occurs after several hundred iterations of the inner loop, you will grow old waiting to see what happens. A combination of Breakpoints and Highlight Execution is more versatile for troubleshooting loops.

Sequence structures are almost never the appropriate choice for well written LabVIEW code. I would probably create several subVIs wrapping around the Velmex driver, with each subVI perfoming one task. Include error in and error out terminals (even if the Velmex driver does not return errors for most tasks) so that you can use dataflow for controlling the order of execution.

Lynn

[armchair_engineer]

I know that it freezes because all four cores jump to 25%, Labview acquires the "Not Responding" status in the task manager, and all of the instruments stop working. Waiting does not fix the problem, and no errors ever show up; Labview won't work unless I give it a hard reset. What is even more frustrating is it never used to do this, and now I can't run the VI without this happening. I also just checked to see if it's the Keithley which causes the problems; the freezing still occurs even when it is only the Velmex which is running. That said, the "Voltage Sweep" part of the program still runs fine, even though it has a similar structure.

The point at which it freezes is entirely random. I've had times when it gets most of the way through, and I've had times when it barely gets through the first iteration. On average, however, it completes 3-5 iterations before breaking.

[altenbach]

That motor drives subVI is a bit weird, especially with these huge numbers of connectors arranged without regard to any guidelines (might give hints how the dll code itself is written :(). The subVI is configured as "reentrant(preallocate clones)", yet all it does is call a dll that is configured to run in the UI thread. It really makes little sense to me to have it reentrant if ~100% of its processing occurs in the UI thread. In one of the middle frames you call two instances in parallel, maybe they step on each others toes, for example (should not be a problem, but who knows what's going on inside these dll!). Try to enforce sequential calls instead and see if things improve.

[armchair_engineer]

No such luck. Labview still freezes during execution even when the motors are called sequentially.