LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Alternative to case structures when triggering an event with a boolean control.

Solved!
Go to solution

I am really stuck with something that I though would be very straightforward.  I want to initiate a dynamic event every time a Boolean value is true.  This is easy enough if I create a front panel control, which I can use to generate a dynamic user event that executes some method.  However, if I have some signal that is being read which has values of 0 or 1 (e.g. a digital waveform) and I want to use that signal to trigger the event, it does not work as expected.  I tried using a case structure within the event, but that simply does not work.  Imagine my program is sampling a digital waveform, but doing so at a very high rate (much faster than the changes between low and high), then what I'm finding is that the event is triggered at the rate determined by the sampling and not by the actual change in values between high and low (like a normal hardware trigger would do).  I tried all sorts of things; for instance, I can write the Boolean values to a reference and use the property node with value(signaling) to try and trigger the event that way.  I tried using case structures so that the event is generated only when the Boolean is equal to true.  No matter what I do, the event still triggers at the sampling rate and not at the rate at which values are changing.  Say I read 0 0 0 1 1 1 0 0 0 1 1 1 0 0 0…  then I can’t help but trigger the event each time a value is read instead of each time it changes from 0 to 1 or vice versa.  Any ideas?

0 Kudos
Message 1 of 18
(3,666 Views)
Solution
Accepted by speclabAI

You need to test for a change of state of the signal, and only then generate the event.  Like this:

et.png

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 2 of 18
(3,634 Views)
Solution
Accepted by speclabAI

You can create a dynamic event (also called user event), that is only generated when the desired transition is found. See below for a couple different bits of transition logic.

 

Capture.PNG

0 Kudos
Message 3 of 18
(3,631 Views)
Solution
Accepted by speclabAI

@Gregory wrote:

See below for a couple different bits of transition logic.


Using comparison functions is simpler and makes the code easier to read and understand. 😄

(of course the global init value depends on the situation, so modify as needed)

 

 

altenbach_0-1584842941733.png

 

 

0 Kudos
Message 4 of 18
(3,625 Views)
Solution
Accepted by speclabAI

There is a built-in option:

B PxP.png

--------------------------------------------------------------------------------------------------------------------------
Help the forum when you get help. Click the "Solution?" icon on the reply that answers your
question. Give "Kudos" to replies that help.
--------------------------------------------------------------------------------------------------------------------------
0 Kudos
Message 5 of 18
(3,594 Views)

@stevem181 wrote:

There is a built-in option:


 

Yes, we know about that one. And if you look inside, you'll recognize code similar to what has been mentioned. These days I would probably rewrite it using a feedback node and no while  loop ... 😉

 

But it is less flexible ...

 

Often code can be simplified significantly by using arrays and the feedback node method can be more easily adapted and made scalable. This will tell you if at least one element has changed in the specified direction. A little more code is needed to determine which ones.

 

altenbach_0-1584861534099.png

 

 

 

0 Kudos
Message 6 of 18
(3,592 Views)

@altenbach wrote:

@Gregory wrote:

See below for a couple different bits of transition logic.


Using comparison functions is simpler and makes the code easier to read and understand. 😄


I would disagree! 😀 Boolean logic is clearer in my opinion than a comparison except maybe for the equal and not equal comparison which would be an Exclusive (N)OR.

 

But that might be because I come from electrical engineering rather than mathematics, and I find an upcoming project where I have to do some rather involved FPGA programming on a sb9651 rather interesting 😁.

Rolf Kalbermatter
My Blog
Message 7 of 18
(3,574 Views)
@altenbach wrote:

Using comparison functions is simpler and makes the code easier to read and understand. 😄

@rolfk wrote:

I would disagree! 😀 Boolean logic is clearer in my opinion than a comparison

Yeah, I disagree too.  I don't find > or < comparisons for Booleans all that intuitive.  I can recall a time when I was first programming where boolean True was represented by the value -1, which would make that comparison logic wrong.  In retrospect, I'm guessing that the underlying integer datatype turned all bits ON but the language default was to treat booleans as signed integers.  In 2's complement, a signed int with all bits ON = -1.

 

I tend to make heavy use of the "Compound Arithmetic" function, both because it expands to multiple inputs and also because the input and output terminals can be inverted individually.   I also tend to force my "transition" detection to return a False on the first iteration.  So here's what I'd be inclined to do:

 

boolean transitions.png

 

-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).
Message 8 of 18
(3,565 Views)

I usually wire the Init input from the Feedback node to the input. Seems to have the same effect but avoids to have to think about the value of the boolean constant depending on the slope you want to detect.

Rolf Kalbermatter
My Blog
Message 9 of 18
(3,544 Views)

Perfect!  Problem solved.  Thank you to everyone.  

0 Kudos
Message 10 of 18
(3,527 Views)