Run something only once in a while loop?

[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

[NeatNit]

I know how it works, but when someone is new to LabVIEW, the first tasks for teaching them are mostly input, linear calculations, and output. To test this we use the Run Continuously button, so we can see how the output responds to our input immediately. This causes the hard-to-break habit for new programmers to always use the Run Continuously button instead of the Run button.

$@#$@#$@#$@# annoying.


Edit: lol, that looks a lot more angry than the original xD

[Greg McKaskle]

You can, of course, teach in any way you like.

I've used LV for over twenty years, and to me, it is just another feature. It is handy for quick things and not meant for finished applications.

Greg McKaskle

[NeatNit]

Yes, I'm well aware of its usefulness (but you have to admit, it doesn't take that much time to make a while loop and a stop button), it just causes bad habits.