topic Re: Edge Detection Toggle State Machine in LabVIEW

Edge Detection Toggle State Machine

LV_Neophyte — Mon, 27 Sep 2021 00:44:24 GMT

Hello,

I have a larger design (not my own) that I'm attempting to modify. I am VERY new to Labview. I needed something that would toggle back and forth on a false to positive edge.

I used some edge detection logic that I've seen suggested in some other posts to try and do that inside a case statement that used what I think is a local variable.

Logically, it seems simple enough, but it also seems that at times either it does NOT toggle, or perhaps it toggles 2x (the result being the same). The input is from "inside" the larger project, so in a hardware sense, it would not seem to be asynchronous (to everything else in the project, so to speak) at least to me.

However, I will admit to NOT understanding race conditions in Labview, and maybe that is the issue here.

I've given up trying to use this approach, but I am still trying to use the edge detector for another purpose (being driven by the same signal) and am worried that since I don't understand why this occasionally had a problem, that my use of the edge detector is also doomed to fail on occasion.

Any explanation why this case statement toggle approach seems to fail, especially as it involves edge detection would be GREATLY appreciated.

BTW, I'm doing this (for free - at least right now) for a company that can't afford to update from the 2009 version (maybe they're getting what they're paying for....)

Thanks (just for reading this far).

Re: Edge Detection Toggle State Machine

altenbach — Mon, 27 Sep 2021 07:14:03 GMT

Simple solution:

Attach your Vi instead of a picture (we cannot run a picture)
Please explain the purpose of all controls. Is the Day/night state where you want to detect when it changes?
What should the final result be? (count number of changes? Flash an LED?
What's the purpose of the D_PP control?
You should also decide on a reasonable loop rate. Spinning as fast as the computer allows (millions of times per second!) is not needed to detect a rarely changing control.
Why is there even a case structure if both cases are nearly the same? Only what differs belongs inside. (Still, the logic makes no sense!)
Even if you have a case structure, the feedback node should probably be outside.
To see if two boolean differ, a simple "not equal" works equally well (no need to negate and AND).

Re: Edge Detection Toggle State Machine

altenbach — Mon, 27 Sep 2021 07:31:43 GMT

@LV_Neophyte wrote:

I needed something that would toggle back and forth on a false to positive edge.

I assume "toogle back and forth" means flash the indicator LED ON/OFF
You can detect a F - T transition when the new state (T) is greater than the old state (F), e.g. as follows.
Make sure you place a reasonable wait inside the loop, else the led flash is too short to see.

Re: Edge Detection Toggle State Machine

Kevin_Price — Mon, 27 Sep 2021 16:53:06 GMT

To the OP: this is purely a preferred style thing. One of the very few things I'm inclined to disagree with altenbach about is the use of "Greater than" for boolean comparisons. While he finds it very intuitive, I definitely don't.

So if your brain's wired more like mine than his, here's the same code using the style of boolean logic I prefer to use. It's the node named "Compound Arithmetic" which has nice properties of expanding for multiple inputs and the ability to individually invert any of the terminals. The little circle on the upper input terminal in the pic below means that input is being inverted.

The logic for seeing a F->T transition then reads literally as: "prev value NOT True AND present value True", or more casually as "was False before and is True now". That feels more intuitive to me. YMMV.

-Kevin P

Re: Edge Detection Toggle State Machine

LV_Neophyte — Mon, 27 Sep 2021 17:11:29 GMT

Thank you for your reply. I'll attempt to address each of the items in your reply in the same order.

1. I've attached the VI as requested. Please remember I'm stuck on version 2009.

2. Yes, I want to detect the night to day transition (but NOT the day to night transition).

3. & 4. I was attempting to use this (in effect D_PP - "Day Ping Pong") to select every other day, or even and odd days, if you like. It then when on to select the case in another case state.

5. Not sure that I understand "reasonable loop rate". As you may have surmised, this transition only occurs once every 24 hours, and that's when I want to flip the state of D_PP. (Sorry if that doesn't address your concern.)

6. So the case structure would have a NAND gate for the "True" case and an AND gate for the "False" case, with the feedback and inversion outside - OK I understand that, but I'm not sure how to accomplish the same thing without a case structure - sorry I guess I'm just not experienced enough....

7. Do you mean that I should skip (what I think is) the local variable and wire an output of the case statement back around to the input?

8. I think this suggestion would give me BOTH edges, and I only want ONE.

Re: Edge Detection Toggle State Machine

altenbach — Mon, 27 Sep 2021 17:17:35 GMT

@Kevin_Price wrote:

To the OP: this is purely a preferred style thing. One of the very few things I'm inclined to disagree with altenbach about is the use of "Greater than" for boolean comparisons. While he finds it very intuitive, I definitely don't.

Once we agree that T > F, my version is, at least for me, easier to read than boolean gymnastics (I even use "not equal" instead of XOR, for example!). Using plain comparisons on booleans (=, !=, >, <) is simpler than fancy, partially inverted compound functions, or even "implies". 🙂 I am sure the compiler reduces it to the same machine code anyway.

True, LabVIEW has some holes where it forgets that T>F. While we can sort boolean arrays just fine, we cannot use array Min&Max on them to get the desired index (1D, 2D, etc.) even though we can guess what the result should be 😞 )

Of course we also have the boolean crossing tool. No extra code needed. 🙂

Re: Edge Detection Toggle State Machine

altenbach — Mon, 27 Sep 2021 17:41:40 GMT

@LV_Neophyte wrote:

1. I've attached the VI as requested. Please remember I'm stuck on version 2009.

2. Yes, I want to detect the night to day transition (but NOT the day to night transition).

3. & 4. I was attempting to use this (in effect D_PP - "Day Ping Pong") to select every other day, or even and odd days, if you like. It then when on to select the case in another case state.

5. Not sure that I understand "reasonable loop rate". As you may have surmised, this transition only occurs once every 24 hours, and that's when I want to flip the state of D_PP. (Sorry if that doesn't address your concern.)

6. So the case structure would have a NAND gate for the "True" case and an AND gate for the "False" case, with the feedback and inversion outside - OK I understand that, but I'm not sure how to accomplish the same thing without a case structure - sorry I guess I'm just not experienced enough....

7. Do you mean that I should skip (what I think is) the local variable and wire an output of the case statement back around to the input?

8. I think this suggestion would give me BOTH edges, and I only want ONE.

Mine detects the T -> F transition. You need to define which boolean value corresponds to day vs night and adjust accordingly (e.g. replace the < with a >).
Your loop is spinning many millions of time per second. It is sufficient to poll every fraction of a second for millions of times less CPU use! Your loop without wait will redline one of your CPU cores forever (see also).
Yes, you don't need any local variables.
If the D_PP needs to get inverted from the Day/Night input, just make it an indicator and wire it to the control using a NOT. No other code needed. D_PP should never be a control, because it should not be operated by the user at run time.

Can you explain in detail what your desired states are?

Program start: D/N=?, D_PP=?
D/N =T, D_PP=?
D/N T->F, D_PP=?
D/N F->T, D_PP=?
D/N F, D_PP=?

Re: Edge Detection Toggle State Machine

Kevin_Price — Mon, 27 Sep 2021 18:49:44 GMT

Good call on the use of the built-in Boolean Crossing function. Both more clear and more versatile than our raw code. Same startup behavior too -- edge detection output always False on first call.

-Kevin P

P.S. ....although FWIW, its internal logic IS a version of my boolean "gymnastics" rather than > or <. 😋

Re: Edge Detection Toggle State Machine

LV_Neophyte — Tue, 28 Sep 2021 15:19:49 GMT

Sorry for the delay, NI put me in a 24 hr timeout for being a new user!

In answer to altenbach's questions:

Can you explain in detail what your desired states are?

Program start: D/N=?, D_PP=?
D/N =T, D_PP=?
D/N T->F, D_PP=?
D/N F->T, D_PP=?
D/N F, D_PP=?

1. Program start D/N - could be either, I can't control this; D_PP - I don't care, could be T or F

2. D/N = T, D_PP = D_PP

3. D/N T->F, D_PP = D_PP

4. D/N F->T, D_PP becomes NOT D_PP (it toggles).

5. D/N F, D_PP = D_PP

FWIW, I changed the scheme based on my (in retrospect) incorrect interpretation of altenbach's point #7 in the first response.

I went from this (which fails to switch properly at times):

To this (which seems to be more robust):

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

This leads me to believe that my original attempt caused a race condition whereby both the T and F cases were evaluated in the same loop iteration meaning that D_PP switched twice when it should have only switched once.

With the added feedback (delay), that's impossible, I think.

Thanks to everyone for their time and effort - I feel good about solving the problem.

Re: Edge Detection Toggle State Machine

GerdW — Tue, 28 Sep 2021 15:43:06 GMT

Hi Neophyte,

I prefer this look:

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

Re: Edge Detection Toggle State Machine

altenbach — Tue, 28 Sep 2021 16:52:25 GMT

@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.

Re: Edge Detection Toggle State Machine

altenbach — Tue, 28 Sep 2021 16:46:32 GMT

@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!

Re: Edge Detection Toggle State Machine

LV_Neophyte — Wed, 29 Sep 2021 17:06:56 GMT

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.

Re: Edge Detection Toggle State Machine

altenbach — Wed, 29 Sep 2021 18:02:57 GMT

@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!