LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Alternative to this one-time trigger?

Good day community, I have faced some issues regarding one-time triggers of a boolean.

Because some times I need to trigger an event only once when a state of a boolean changes, so I have made a piece of code that does that, the code is simple, and what it does is when ever the input is a true value, it will set the output to true for 1 frame, then it will set it to false, until the input is set to false (reset) and to true again for an other 1 frame pulse.

I made this to avoid using shift registers, but I also heard that is not a good idea to use feedback inside the code.

So I wonder if there is a better method to achieve this goal, thank you

Capture.PNG

 

 

 

0 Kudos
Message 1 of 8
(2,669 Views)

I think that, technically, using a feedback node is a tiny bit more expensive in terms of CPU usage, but there's nothing inherently wrong with using them.  In fact, sometimes there is no practical way to avoid them.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 2 of 8
(2,629 Views)

I think the feedback node is fine. I do question the need for the other logic. It looks Rube-Goldberg to me. Why not just AND the current Input and the inverse of the previous Input? Does that not accomplish the stated goal? If Input is TRUE AND previous value of Input is FALSE then Output is TRUE. Otherwise Output is FALSE.

 

johntrich1971_0-1575922136359.png

0 Kudos
Message 3 of 8
(2,609 Views)

@johntrich1971 wrote:

johntrich1971_0-1575922136359.png


This is the "rising edge" detector.  What caught my attention is that the above is the negation of what is probably the most "unused" Function on the Boolean palette, namely "Implies".  Here is the same function, with explanation:

 

Rising Edge.png

In Symbolic Logic, an Implies Statement (A Implies B) is True except when A is True and B is False (in other words, with a False premise, you can imply anything, but with a True premise, you can truthfully imply only something True).  Here the Premise (the previous condition) is the Feedback loop, so if the Input is True and the previous input was False (precisely the condition we want to be True), this is exactly the condition where the Implies function returns False, so we negate it and we get "Rising Edge".

 

Isn't logic fun?

 

Bob "Makes Your Head Spin" Schor 

 

 

 

Message 4 of 8
(2,599 Views)

Yeah, I used to get a kick out of using the "Implies" function when it fit, probably mainly *because* of its relative obscurity.

 

IIRC, I changed my habit a decade or more ago after reading a thread here where altenbach made an offhand comment about the excellent readability of a multi-input AND with a negated input, just like johntrich just posted.  He was right (of course).

 

That's one of several areas where I've learned that code clarity is usually more valuable than cleverness and often more valuable than small improvements in efficiency.

 

 

-Kevin P

 

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 5 of 8
(2,593 Views)

@johntrich1971 wrote:

I think the feedback node is fine. I do question the need for the other logic. It looks Rube-Goldberg to me. Why not just AND the current Input and the inverse of the previous Input? Does that not accomplish the stated goal? If Input is TRUE AND previous value of Input is FALSE then Output is TRUE. Otherwise Output is FALSE.

 

johntrich1971_0-1575922136359.png


If I am understanding the OP correctly, they only want a single trigger just once. The rising edge will trigger whenever there is a rising edge. I believe that is the reason for the R-G code, which may or may not, be able to be simplified.

 

mcduff

0 Kudos
Message 6 of 8
(2,587 Views)

@mcduff wrote:


If I am understanding the OP correctly, they only want a single trigger just once. The rising edge will trigger whenever there is a rising edge. I believe that is the reason for the R-G code, which may or may not, be able to be simplified.

 

mcduff


You may be right, mcduff. In that case adding a simple OR would do the work.

 

johntrich1971_0-1575982579348.png

 

I've not really used the Imply that Bob_Schor suggested, but I'm not sure that I would want to as I prefer that my code be obvious to someone who may have to edit it in the future. As Kevin_Price suggested the Imply is less readable because it is less well known.

Message 7 of 8
(2,528 Views)

I am in complete agreement that Imply fills (as we used to say) "a much-needed Gap in the list of Boolean Functions"!  Indeed, when I first noticed Imply, I had to remind myself of the syllogisms I worked through in PL10 (Symbolic Logic) many, many moons ago.  It is great for logical proofs, and I recognized its strange pattern of 3 Trues and one False, and puzzled when I ran into the first time I needed a "Rising Edge" function that was three Falses and one True, and said "Is this Implies-Not?", but after drawing truth tables for a few minutes and trying to puzzle it out, I realized that it was too weird to be used anywhere except "buried" inside a sub-VI (where you could write a little Test Routine and say "Yes, this only detect Rising Edges" and not worry about the obscure details ...).

 

Bob Schor

0 Kudos
Message 8 of 8
(2,523 Views)