Run something only once in a while loop?

[siggy2xc]

What is the best way to run something only once while in a while loop? The method I am currently using uses a global variable but id like to find a way that does not require a global or a local variable.

[Vikesrock]

So if I understand correctly you want some piece of code inside a while loop to run only the first time the loop runs?

This can be accomplished by placing the desired code inside a case structure that is fed by a comparison with the out put of the little blue "i" block in the corner. This block keeps track of the number of loop iterations. I can't recall off hand whether it starts at 0 or 1 (I think 1) but you should be able to trigger your case structure by doing an "equal to" on the output of.

Let me know whether that made any sense or not

[Joe Ross]

You can also use the first call function: http://zone.ni.com/reference/en-XX/h...ng/first_call/

[siggy2xc]

Thanks! never knew that. But it starts at 0 for future reference

[random_variable]

I think something like this may be of interest to you. After I start the program, no random number appears. When I 'Begin Trial' a single random number appears. I did initialize the value of 'Boolean' to TRUE before the while loop executes.

[Alan Anderson]

Yes, that's pretty much how Tyler was doing it in the first place. He was asking how to do it without a global/local variable.

Two years ago.



I think the "First Call?" function is the appropriate tool.

[NeatNit]

I believe First Call is a very specific function with a very important quirk to keep in mind. If said while loop is inside of a bigger loop, then the second time it is called, should the code run? With First Call, it will not run. With iteration check, it will run, since that is reset every time the loop is started.

There is also a bunch of LabVIEW quirks, if you run your code through your PC for debugging after some code has already run on the robot, you can't be sure whether First Call will reset or not, as LabVIEW seems to save the most annoyingly unpredictable bits of data when you do things like that.

First Call is a deceivingly simple yet advanced function and should not be introduced to inexperienced LabVIEW programmers.

[Greg McKaskle]

I agree that first call is an advanced concept, but I wouldn't call it quirky. The documentation is pretty explicit "The First Call? function returns TRUE only the first time you call it after you click the Run button." There is a bit more in the details. If you find a case that doesn't fit the documentation, it is time for something to change, either the docs or the product.

Greg McKaskle

[NeatNit]

Well, just think about how many times feedback nodes reserved information you didn't want them to, or wouldn't expect them to. First Call would do the same thing.

[Greg McKaskle]

The explicit purpose of the feedback node is to retain information for another run of that diagram expression. The complication is specifying what the lifetime is for the retained state data -- when is it to be initialized and with what value. The initializer terminal on the feedback node and the left side of the shift register are there to specify the value and timing of the initialization. Perhaps it doesn't work the way your intuition says it should, and I'd like to hear more about that, but it seems pretty complete, useful, and teachable. I'd like to hear the cases you are having issues with.

Greg McKaskle

[NeatNit]

Originally Posted by Greg McKaskle

The explicit purpose of the feedback node is to retain information for another run of that diagram expression. The complication is specifying what the lifetime is for the retained state data -- when is it to be initialized and with what value. The initializer terminal on the feedback node and the left side of the shift register are there to specify the value and timing of the initialization. Perhaps it doesn't work the way your intuition says it should, and I'd like to hear more about that, but it seems pretty complete, useful, and teachable. I'd like to hear the cases you are having issues with.

Greg McKaskle

Well to put it short I am having problems predicting when feedback nodes get initialized, especially when teaching about them. They seem to be very determined in retaining information always always, and sometimes even between totally separate runs. Shift registers are completely predictable - they get initiated when the loop is started. But I've seen some generally nice code by rookie programmers get slaughtered by this. Stopping, editing code, and running it again, feedback nodes actually retained information from previous runs. I find it difficult to teach people "when to use what", because they're not going to accomplish anything if they don't learn these kinds of things the way they understand them, and with feedback node and shift registers being so similar, it's very hard for me to just tell someone "forget it, feedback node's broken, switch to shift register".

[Greg McKaskle]

I agree that you need to have the correct concept and trust your code to work.

I'd suggest that you build very simple programs, perhaps charting them. This will hopefully help with the teaching.

By the way, it is certainly allowed for code to retain values across runs. This is intentional so that it can better represent external hardware and other processes. This is the behavior of the uninitialized shift register and the feedback node with no initializer.

Greg McKaskle

[NeatNit]

Something I can't test right now - many inexperienced LabVIEW programmers like to use Run Continuously (or whatever it was called, the loopy button next to the normal run button) for testing their loop code. How does First Call react to that? For the record I intend never to teach about this button ever again, just because of the confusion it causes, and the horrifying habit of pressing it always instead of normal run.

[Greg McKaskle]

It works the same as pressing run immediately after the VI finishes. It inits between each run of the diagram.

Greg McKaskle