Keep button inside state machine on true

[Godeko]

Hello guys,

I'm having a struggle here and I hope you can help me.

I reduced the problem to the most necessary. A sketch can be found in the appendix.

My aim is an alternating digital output with pulse width t (time for which I have a true boolean - laser on) and frequency f (thus the time which the boolean is false is 1/f-t - laser off).

I realised this by a for-loop inside a while-loop. I replaced the digital output by a simple LED (,,on-off") for simplicity.

Finally this results in an endless modulated Laser, or in this case: LED. This continious modulation is always running no matter whats happening in the other parts of the program.

This is denoted by "Laser-Modulation".

So far so good.

Meanwhile I want an analog output (voltage). Denoted by "Voltage-Output".

I replaced the DAQ-Assistent by a numeric indicator ("voltage") for simplicity.

As long as the user doesn't do anything the output remains at e.g. 2V while the LED keeps blinking.

At one arbitrarily point one can press the "Start"-button.

Now the next time the LED turns off, the output has to change to e.g. -5V.

It has to stay in that state for e.g. N=2 blinks. After the 2nd blink it goes back to the base state.

Im close to be done with it.

I configured a state machine with two states:

Base: The default state with a output of 2V.

Target: State with a output of -5V.

The target state is finished (staying on target state for N blinks and going back to the base state afterwards).

My problem is the transition from base to target state.

I realised this by an AND: Once the LED turns off I get one true. The second true comes from the "Start"-button. Once both are true the AND gives out a true and the SELECT changes the state to target.

This is the theory. When replacing the "Start"-button with a true-boolean constant it works out fine.

As soon as I replace the true-boolean with the button it doesn't work anymore.

I just want the button to stay on true once its pressed until the LED turns off the next time and triggers the change to the target state. Then the button has to reset itself.

This is really frustrating me.

I hope one can help me with that.

Thank you for every help.

[Lysandros]

In generall, two loops running in parallel might create issues regarding timing/parallelism and inter-dependency. I would try to use one loop is possible. There is also Timed Loops which have a "fixed" period that might be helpful here.

[johntrich1971]

Your code is working such that you're getting the Start button (the first TRUE) and then looking for the second TRUE. There are a couple of ways that you could remedy your problem with the button changing. One simple way would be to change the mechanical action of your button to switch then use a value property node to set it back to FALSE at the appropriate time. 

Another option would be to add a transition state to your state machine. When you get the TRUE from the Start button you could enter the transition state and only move to the Target state once the second TRUE is reached.

You might also investigate the use of a notifier instead of all of that logic that you're using to find the state change of the laser pulse.

Finally, you don't need the Val(Sgnl) for the counter - val(Sgnl) is only when you have an Event structure that you need to activate when you change the value of the control. You can actually get rid of that property node altogether by moving the indicator outside of the case structure and just passing the value.

[Bob_Schor]

The "problem" is the Start Button.  [Well, the real problem is that you haven't learned, or have forgotten about, the fact that LabVIEW's Boolean Controls have Mechanical Actions ...].

LabVIEW's Boolean Controls have Mechanical Actions that govern how they work -- when do they "switch" (when you press them or when you release them?), do they "stick" in the new State when released, etc.  In particular, the Controls that are frequently represented as "Square Buttons" (like Start and Stop) have the Mechanical Action "Latch when Released", which means when you release them, they "register" the change (typically from Off to On), and when you read them, they "unlatch" and return to their default state (typically "off).  So "reading" a Start Button will always turn it Off!  You can "fix" this by right-clicking the Button and changing its Mechanical Action (I recommend Switch when Released).

Bob Schor

[Godeko]

Thank you for the mentioning of timed loops. I will look into it.

In the meantime Ive found a solution to my problem. Its probably WAY to complicated but atleast it works.

[RTSLVU]

Never mind  

[altenbach]

---

@Godeko wrote:

In the meantime Ive found a solution to my problem. Its probably WAY to complicated but atleast it works.

---

Still lots of Rube Goldberg code:

• One stop button is sufficient.
• local variables are much more efficient than value property nodes for the same functionality. change all of them!
• A "Select" node with two different booleans as you wired it is either a "noop" or a "not". 
• Your lower loop spins as fast as the computer allows, redlining your CPU cores.
• All your boolean logic is way too convoluted.
• A "Counter" is an integer, why do you have it in orange?
• Same for N.
• Your green "array" only has one element. If the user is not supposed to change it, use a diagram constant of a boolean array with two elements. You could even eliminate it completely and do a i=0 to get the desired boolean value inside that FOR loop.
• Index array" in the upper loop can be replaced with autoindexing.
• There is a primitive for 1/x.
• I still think that you can eliminate 80% of your code and still do the same functionality.

[Ben]

---

@johntrich1971 wrote:

..

  - val(Sgnl) is only when you have an Event structure that you need to activate when you change the value of the control....

---

 A corner case I found back in LV something old...

Spoiler

When updating a 3D picture via a reference in a sub-VI "Property node >>> Value" the display did not update. I replaced the "value" property with a value signaling and it worked.

I reported as a bug but have never returned to that code to see if it was ever fixed.

Ben