Edge Detection Toggle State Machine

[LV_Neophyte]

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

[altenbach]

Simple solution:

1. Attach your Vi instead of a picture (we cannot run a picture)
2. Please explain the purpose of all controls. Is the Day/night state where you want to detect when it changes?
3. What should the final result be? (count number of changes? Flash an LED?
4. What's the purpose of the D_PP control?
5. 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.
6. 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!)
7. Even if you have a case structure, the feedback node should probably be outside.
8. To see if two boolean differ, a simple "not equal" works equally well (no need to negate and AND).

[altenbach]

---

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

[Kevin_Price]

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

[LV_Neophyte]

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.

[altenbach]

---

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

[altenbach]

---

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

1. Program start: D/N=?, D_PP=?
2. D/N =T, D_PP=?
3. D/N T->F, D_PP=?
4. D/N F->T, D_PP=?
5. D/N F, D_PP=?

[Kevin_Price]

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

[LV_Neophyte]

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?

1. Program start: D/N=?, D_PP=?
2. D/N =T, D_PP=?
3. D/N T->F, D_PP=?
4. D/N F->T, D_PP=?
5. 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.

[GerdW]

Hi Neophyte,

I prefer this look:

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