Edge Detection Toggle State Machine

[altenbach]

---

@GerdW wrote:

Boolean logic/algebra was part of my apprenticeship, before I repeated the same stuff at the university…

---

For those without all that background in logic, here's my alternative. Same difference 😄

Or, if the loop is big due to lots of other code, you can avoid long wires by replacing the shift register with a feedback node.

[altenbach]

---

@LV_Neophyte wrote:

Note that LV added the feedback node when I wired the output back to the input.

---

Nothing to do with race conditions, just caused by the fact that you created a dependency loop. Since the case structure cannot execute until all it's inputs have new data (dataflow!), but one of the inputs depend on an output of the case structure, you create a deadlock. LabVIEW has a questionable option enabled by default to auto-insert a feedback node to "solve" the problem. While the wires are now no longer broken, it typically results in very questionable code, making things even worse (see this idea and my comment here).

About your code in general:

No, you don't need three feedback nodes and a local variable. Go with one of our suggestions instead. Maybe there are even simpler solutions. Did you understand my comment about the need for a small wait? It is still missing one!

[LV_Neophyte]

Altenbach,

Thank you for your feedback (pun intended).

WRT the wait, everything that I've "submitted" has a while loop purely for testing, which I remove prior to compiling the larger project. Again, it's just piece in a small part of a large design - the only part I intend to modify. The larger design has a while loop, but I'm WAY too chicken to add a wait to it.

My "preferred" solution, did not use any local variables, so  I'm not sure I understand your last comment about not needing local variables.

WRT the feedback nodes - I understand your comments about not needing 3 nodes, but I was attempting to make the smallest change to see what actually helps. If I change EVERYTHING, then I really don't learn as much - i.e. change one thing at a time.

Also, about feedback nodes, even if they come out of the case statement, I'd still need 2 right? One for the edge detect and one for the actual feedback of the case statement output, ignoring for the moment some other solution that doesn't involve feedback nodes.

Now, about the feedback node on the output of the case statement. I'm not uncomfortable with it. My background is hardware design, which I started back when using gates (AND, NAND, OR, NOR, etc) was common (so it's not boolean gymnastics for me). To me, in this instance, the feedback node is akin to what happens with a flip-flop that will determine the "next state" after the next clock edge in a state machine. I've read at least some of the links you've provided (and others besides), and do NOT see any reason to avoid using it, other than perhaps personal preference. If you can point me to some objective evidence that it really is a poor choice, I'm all ears.

WRT the feedback node in the edge detect, it would seem that ANY solution would require either the feedback node itself (or something VERY similar like the shift register) to perform that function. I'm talking about the crossing function, for example, which to me, is simply a higher level of integration than a delay and a few gates - which, again, I'm comfortable with.

Lastly, in the interim, I've been experimenting with the VI that this pin-pong toggle was a part of. I've found a solution that does NOT require a case statement. That means that I don't need the feedback node that LV added for me, so in a sense there should be a little less concern.

BUT

I am still using the feedback node for my edge detect, and the edge detect (when I had problems with the ping-pong toggle) MIGHT have been the source of my problem. I am no longer worried that it was the problem. Feel free to tell me that I am wrong, but please explain why.

Thank you.

[altenbach]

---

@LV_Neophyte wrote:

My "preferred" solution, did not use any local variables, so  I'm not sure I understand your last comment about not needing local variables.

---

There was no way to tell from a picture, especially since we cannot see what's in the other case (earlier, you showed two pictures, one for each case and here was again another picture with a local right next to it). The less information we get, the more blanks we fill in and the more misinterpretations can occur. 😄

Yes, you need two feedbacks (or shift registers), one for the change detection and one for the output state, unless you use the boolean crossing tool (not sure if that's available in LabVIEW 2009). You definitely don't need any case structure.

Of course a limited static "picture" view into some code extracted from a much larger application limits our capabilities to give detailed advice, but it seems you have things under control now. 😄 Good luck!