Labview: Feedback node doesn't reset on "stop"

[kamocat]

Okay, I'm a little early, but I'm *hoping* there's some other kids out there working with Labview already. NI communities doesn't have enough people to get a help question answered within a week.

Anyways, I've been having problems with my feedback nodes not resetting when I stop the simulation. When I wire a value to the initializer terminal, the node simply sends the value wired to the initializer terminal, instead of storing the input value for one loop. I have seemed to get around this with putting a "while" loop around the whole VI instead of testing with a "continuous run", however if I leave subVIs like this, they hang up the VI where they are used.

What can I do to get around all this?

[Greg McKaskle]

I can't be sure of what you are doing because I can't see your diagram, but it sounds like you are using continuous run, and you either have state data that isn't inited when you don't wire to the init terminal, or is always the initial value when you do.

The continuous run is simply running your entire diagram again and again including the init code. If you want better control over initialization, which you do, place your own loop around this with a button to exit the loop. You can then init on entering the loop and have state data inside the loop.

Personally, I then prefer to switch over to the loop shift registers. They aren't necessarily better, but they are what I learned, and to me are simpler to explain things like initialization.

When you are ready to use the code you are writing as a subVI called from other locations, if the loop doesn't belong inside the subVI, but the state data does, then set the loop to a constant to run only once.

Greg McKaskle

[Greg Marra]

Originally Posted by Greg McKaskle

Personally, I then prefer to switch over to the loop shift registers. They aren't necessarily better, but they are what I learned, and to me are simpler to explain things like initialization.

I've never used feedback nodes. I have always used While Loops for when I need my program to run infinitely. I imagine that at the base of program for the new RC, there will be a giant While loop managing everything.

[kamocat]

Yes, I am using continuous run. The default value of a boolean feedback node is FALSE, and that just happens to be what I need to to initialize to.

Originally Posted by Greg McKaskle

The continuous run is simply running your entire diagram again and again including the init code. If you want better control over initialization, which you do, place your own loop around this with a button to exit the loop. You can then init on entering the loop and have state data inside the loop.

Huh. I just tried it, and I must have done it wrong, because it didn't work. One of the most basic VIs I'm working on to make my programming easier is the latching relay (the VI I uploaded). The output should only be on if the trigger has been pressed, and should only turn off if reset has been pressed. (in other words, there's one input to turn the signal on, and one to turn it off)
I suppose I could just wire every reset of every subVI I use to the "firstcall" indicator (which I should be doing anyways), but it makes it quite a pain for testing my code.

Originally Posted by Greg McKaskle

Personally, I then prefer to switch over to the loop shift registers. They aren't necessarily better, but they are what I learned, and to me are simpler to explain things like initialization.

When you are ready to use the code you are writing as a subVI called from other locations, if the loop doesn't belong inside the subVI, but the state data does, then set the loop to a constant to run only once.

I'm not really sure how I can get a feedback node to initialize only once, when it seems to go through initialization every time it is called.

Apparently feedback nodes have a default initialization value. Shouldn't this mean that it resets to its default value when it is called for the first time, before it has a chance to collect data? (or perhaps even when "abort execution is pressed"*)

* I made a mistake in confusing "abort execution" with "stop" in my previous post.

[Greg Marra]

Originally Posted by kamocat

...attached VI...

Can you also attach an image so people without LabView on their home computers can see what you're trying to do?

[kamocat]

Originally Posted by Greg Marra

Can you also attach an image so people without LabView on their home computers can see what you're trying to do?

Sure! (Thanks for reminding me)

I also removed that array-creating function of the FOR loop.

[Greg McKaskle]

Have you turned on the Execution hiliting yet? It is the fifth button on the button-bar, next to the pause. It will animate the data flowing down the wires, and it will show FALSE going to the initilization of the feedback every time the diagram runs.

Delete the for loop and constant and I believe you are in business. What may at first seem confusing is that LV code doesn't reset all values when run. Uninitialized shift registers and feedback nodes keep values as long as they are in memeory, kind of like registers in HW do until powered down.

In other words, from one run to the next, from one call to the next, the feedback node will maintain the Boolean value.

A couple LV factoids:
Every datatype in LV has a default value -- no random stuff.
You can set the default of controls and even indicators, but unwired stuff gets what we call the default default, or the default value for the datatype. Generally these aren't hard to guess, things like zero and FALSE, empty strings and empty arrays.
When possible, LV maintains the value of uninitialized things, controls, indicators, shift registers, globals, etc. between runs and between calls. If you specify a value, it changes, otherwise it keeps its value. Recompiling will reset some of these, leaving memory reset all of them.
You can use an uninitialized shift register or feedback node that is always set to true to tell if code has run since loaded, or you can use the First Run node.

I've also attached a picture using a loop and shift register instead of the feedback.

http://www.chiefdelphi.com/forums/at...4&d=1218632460
http://www.chiefdelphi.com/forums/at...4&d=1218632460

[Russ Beavis]

I'm not exactly sure what you're trying to do but, from what I can gather, you should consider using a shift register per Greg's earlier comment.

One VERY useful bit of LabVIEW advice - when in doubt, RIGHT-CLICK. You'll be astonished by the number of features that can be unlocked by right-clicking on everything.

To create a shift register (or, similarly, a sequence local in a sequence structure for passing data from frame-to-frame), simply right-click on the border of the FOR loop (also available for WHILE loops). It's good practice to always initialize the shift register.

Happy G-coding!

Russ

[kamocat]

Thank you!
I'll just have to reset everything before I test!

(and I do wish that a feedback node gave some configuration options when right-clicked)

[Russ Beavis]

Maybe I'm missing something. If the initializer input is wired to a constant, it will always start with the same value. If the initializer input is wired to a control or local/global variable, it will always start with whatever the control/variable is set to.

A word about controls - the default value of the control can be changed in a number of ways. You can use "Edit->Make Current Values Default" to set the currently-visible values as the default values for the next time that you open the VI. Also (this is my preference), you can use a local variable to force the control to have a known value at the beginning of execution.

Controls and indicators aren't that different. They're both simply variables that can be written to and read from by your software (generally with local variables) but they've obviously got different accessibility from the front panel when running the application.

Russ

[mshafer1]

First note, the feedback node will "default" to what is passed into the bottom on the first execution - and will reset memory only on a stop. This means that if Run continuous or a calling VI is used, the value will be retained from run to run, but if the run button is pressed, the input values are changed, and the run button is pressed again, it will return to the state passed in (False in the picture that was posted).

It looks like you are trying to assemble a JK latch (a variant of the SR flip flop). If this is the case, I would suggest you look at 3937's memory library released on FRC LabVIEW Tutorials.com at http://frclabviewtutorials.com/memory-library/ . If you install the library, you can look at the flip flop to see how they did it (albeit using shift registers instead of feed back nodes - this will retain memory between executions of the calling vi's, only resetting at a power cycle - of on the rio)