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
Highlighted

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
(564 Views)
Highlighted
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
(532 Views)
Highlighted
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
(529 Views)
Highlighted
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

 

 


LabVIEW Champion. It all comes together in GCentral GCentral
0 Kudos
Message 4 of 18
(523 Views)
Highlighted
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
(492 Views)
Highlighted

@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

 

 

 


LabVIEW Champion. It all comes together in GCentral GCentral
0 Kudos
Message 6 of 18
(490 Views)
Highlighted

@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
Averna BV
Message 7 of 18
(472 Views)
Highlighted
@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

Message 8 of 18
(463 Views)
Highlighted

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
Averna BV
Message 9 of 18
(442 Views)
Highlighted

Perfect!  Problem solved.  Thank you to everyone.  

0 Kudos
Message 10 of 18
(425 Views)