It changes color based on the data type that then gets wired to it.
It’s green in the example because a boolean wire got connected to it.
So it’ll turn green when you wire the button output to it.
If you wired an integer to it, then it would turn blue.
A floating point number would make it orange instead.
Thank you very much! It worked
What about false in the outer case structure of?
The outer false case avoids doing anything at all.
That’s when the button hasn’t been pushed again.
The wire just gets passed from the input tunnel right to the output tunnel.
One of our veteran team members wrote a very simple and effective Toggle vi, which I’ve attached. Just feed the button signal into the input, then use the output with a select block or case structure to select your relay state.
Toggle.vi (9.42 KB)
Toggle.vi (9.42 KB)
I was asked to provide a screenshot of what our team’s Toggle VI looks like, so here’s how it works!
Note: Remember that this VI would have to be set to Reentrant Execution (under VI Properties>Execution) in order to have a separate saved state at the feedback nodes for each instance of the VI. Otherwise it will not work properly at all (rising edge detection fails and all outputs will be locked together…).
Ugh. The LabVIEW Developer in me can’t stand feedback nodes. They make everything so much harder to understand.
Interesting. It’s one of the symbols that seems second nature to me. Perhaps because of many years working with digital controls systems. It’s just Z-1.
I understand them, but they break left to right data flow, which is considered a no-no in most of the LabVIEW world.
I prefer to use shift registers and while loops.
Are you saying this would look clearer to you using shift registers and while loops instead of feedback nodes?
Generally, yes.
I find that vi to be difficult to understand, as the loop that causes the feedback nodes to contain data is outside the scope of the vi. Tracking the flow of the program gets much harder that way.
Can you post a PNG or GIF of how you would re-write that?
This would have identical function to the other one. Similar in compactness, and IMO easier to understand what is happening. Its a style thing though, I fully understand that other people may find feedback nodes easier to understand.
Don’t you need to leave the shift registers uninitialized for this to work?
D’oh. Yes, you do. Fixed.
Yikes. Similar in compactness? Easier to understand? To each his own I guess 
My lip is bleeding.
In the posted example, only one of the feedback nodes “breaks” this flow, the other is oriented left to right. And there is an arrow…
Do you find it easy to understand that what goes into the left hand side of a a left-to-right oriented feedback node is different to what comes out of the right hand side?
Personally, I find it difficult. Especially without the loop there to show that the code you’re looking at is actually being called in a looping fashion to populate the feedback nodes.
I’m pretty sure its a personal preference thing though.
I have little-to-no experience with using LabVIEW in an FRC environment. Are we able to use event structures? Most of the LabVIEW programs I write make heavy use of the Event Structure to control process flow.