How to have an indicator on when a loop is in progress, and then change it when the loop ends without local variables?

[Pyromuffin]

Hi everyone,

I'm a newish labview programmer, and I'm trying to be a 'good' programmer and not use local variables, but I can't seem to find an elegant way to change an indicator's state inside a loop and also outside of a loop without breaking the dataflow paradigm. I've attached a section of my code. Please don't mind the copious (horrendous) use of shared variables, as I took over this program from someone else who tried to write Labview code like C.

Concerning the attached code, I would like to re-write this without using the local variable for the Curve in progress indicator.

Thanks for your help.

[Ben]

IN that code

you can add logic inside the loop to compare the "I" plus 1 with the 'N" and use that to update the indicator inside the loop. Make sure you flow forces that update to be the last thing that happens in the loop.

But that is just specific answer to your question.

Locals are legitimate in this context. The "standard" sasy minimize locals not eliminate. For the sake of keeping the user entertained and updating the GUI, locals are OK but one thing one may want to change is where the local is used vs the terminal. Locals take more work to update, so use the terminal when you are doing a bunch of updates and use the local for the one-off.

Please note that I am talking about updating the GUI.

Please don't take what I said to mean you can use locals to read/write from a control that is storing some data value for you. Controls indicators loacls property nodes are OK for updating the GUI but data should not be stored in FP objects. THat is what wires are for.

You may also want to click on the link in my signature about a race condition. That will take you to my Nugget on Action Engines where I talk about sharing data between threads SAFELY in LV.

have fun,

Ben

[altenbach]

There is nothing wrong using a local variable for UI stuff. Sometimes they are the most efficient solution. Why do you think you need to write the same value to the local with every iteration of the loop? Once right before the start of the loop is enough!

Please attach the actual VI, a picture is not very helful.

More serious problems are the use of inner loop traps that consume all CPU (see also). One takes control away from the operator for 45 seconds!

Can you explain the feedback node in the leftmost loop????

Also the entire program logic and dataflow is very suspect. All this code is in a case tied to a certain tab position (if I read the shared variable correctly), and inner code also rely on tab position for certain program decisions. This make a program very difficult to micromanage. It is typically better to use tabs a purely cosmetic elements that simply logically group FP objects.

[Pyromuffin]

You're correct, that will work, but it's not very elegant. I suppose that I can leave the local variable in. I just felt that I was failing some unspoken labview test by using a local, when I can usually figure out how to do things with dataflow.

[Pyromuffin]

Unfortunately, the whole VI is rather gigantic, and possibly subject to NDA. I will copy out that portion of the VI in question. I will not include the other cases, because they are not relevant. Also, the subvi's wont be included, but they are not important either.

I see your point about the loop traps, but I'm not sure how to get rid of them.

You're right, I should write the value to the indicator once before the loop, but how would I do that without using a flat sequence?

The whole tabbed control thing is a terrible idea that came from the guy who wrote the program before me. He is basically using the tabs for mutually exclusive states of the program, like one tab for VI curves, one tab for manual controls, etc.

The function of the VI is to run a VI (Voltage vs current) curve on a piece of equipment by feeding a series of current requests to a load bank, waiting for 45 seconds and then logging the value.

The function of the feedback node is to store the current request at the beginning of the loop, and then write it back to the load bank when the VI curve completes completes.

The auto flows VI internally sets the current request, and adjusts some other parameters automatically.

The tab position is linked to the stop control of all the loops because if the user changes the tab position, the VI curve needs to end.

I can't replace the 45 second counter with a time delay, because then I won't be able to exit the loop if the tab position changes.

I realize I have some begginner's coding habits, but I am trying to change them.

Thank you for your help.

Edit: I had swapped one of the booleans on the diagram by mistake. It is fixed now.

[altenbach]

---

Pyromuffin wrote:

You're right, I should write the value to the indicator once before the loop, but how would I do that without using a flat sequence?

---

As it currently stands is OK, you don't need a sequence. Currently the boolean gets updated in parallel to the loop, this is sufficient for an UI.

That entire tab business is a really bad idea! From an UI standpoint, the typical operator does not expect things to abort when switching tabs. Many times the user is bored and wants to look at some other parts of the front panel while the test is in progress.

This juggling of the tab control value looks like mouse trap code. Everything is spring loaded!

OK, you added a bit more code to the inner loop. Still these polling loops needs a small wait.

You still have not explained the feedback node in the loop on the left.

I would really recommend to change all this to a proper state machine. It would probably be faster than to try to repair this.

[Pyromuffin]

The feedback node writes the initial value of the current request (which is set by the auto flows subvi) when the for loop finishes. Now that I think about it, I guess the value is stored in the tunnel when it exits the initial while loop. I suppose that I do not need the feedback node.

The whole tabbed structure thing includes like 8 whole subsystems, which would take a quite a while to rewrite. I know it's a bad idea. When I first got a hold of this code, while it was running, I changed the tabs and the whole thing crashed. I was surprised to say the least, hah!.

So, the polling loops are okay if I just put a wait in them, or should I use a different technique?

Thanks again.

[Tanya_V]

Polling loops are fine. The wait just gives the processor some time to breathe and process other demands.

Take care!