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.
Teams can use event structures, but few do. This is RT, so very little UI and not much need for user events.
As for the shift register versus feedback node. It took awhile for me to warm up to the feedback. I was so used to doing it with loops. I now use a mix. I typically use a shift register if it already has a loop or if it is a functional global. I use a feedback node if it is like the button example and is super local. I find that I change direction on the node when doing a compare for change, it makes much more sense to me. If I need the i-1 term for something else, I typically leave it in the default direction. I donāt go for separating the init from the feedback. As you say, it is a style decision.
Greg McKaskle