LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Switching pulse trains on the fly

Solved!
Go to solution

Hello.  I'm having a problem with my state machine.  For my experiment, we need to have a two different on-demand pulse trains of varying properties with and idle state of n activity.  For this, I thought a simple state machine would satisfy all of my needs.  However, my state machine appears to be locked in whatever case I have selected when I hit the run button.  I suspect this has something to do with how I generate my pulses, which involves calling a task query node repeatedly using a while loop.  My initial solution was to just include a button to stop this loop before switching my case, but this was ineffective.  Not even stopping the state machine's while loop was able to halt the signal.  

 

Now, I suspect that I what I'm looking for involves either changing how the Stop Task VI and the Clear Task VIs are called (simple wiring in my case), or some command that will reset any process when I switch my state machine to another state.  This is probably something simple that I'm overlooking, but I really don't know where to start.  It seems like this would be easy considering the nature of state machines.  I've attached a sample VI that is a compact version of my working VI, which involves a synchronization pulse to synchronize multiple channels that would all switch when changing states.  

 

Note:  The idea is to have the program running at all times and trigger with a knob or switch in the experimental area.

 

I'm using 2009 SP1, if you're curious.

0 Kudos
Message 1 of 4
(2,089 Views)

Firstly, you need a fly. 😄

 

0 Kudos
Message 2 of 4
(2,086 Views)
Solution
Accepted by topic author RBeck

If you want the numeric to be read at every iteration of the loop, you need to place the control terminal inside the loop. Currently, it is only read once at the start of the program and then never again.

 

Try execution highlighting to see for yourself.

 

Overall, you should rearchitect the entire program. It currently requires controls to be pressed in a certain order.

0 Kudos
Message 3 of 4
(2,083 Views)

Thanks.  I knew it was something simple.  I need to kill the while loop processes in the cases momentarily after switching to the idle state to reset the cases so they start again when I switch to those cases, but I can incorporate an extra toggleable 3 state switch in addition to my 2-button goal and be happy.  I'll do some experimenting with retaining two buttons by incoporating a state machine within a state machine so I can also use the buttons that reset the while loops to also change state, but that seems a bit unwieldy and it will be no big deal if I can't.

0 Kudos
Message 4 of 4
(2,061 Views)