10-13-2016 07:06 PM - edited 10-13-2016 07:29 PM
I am getting stuck on the logic now... I've summed up the logic below:
OLD NEW Action
F T Macro: Iniitlaize Measurement
T F Macro: End Measurement
T T Macro: Measure
F F Event Strucuture >> Idle
I've also attached the vi. Does this look right?
Edit: My worries are that the NEW and OLD values of the event structure will be the same cause the event happened during the procedure and not during the Event Strucuture case...
10-13-2016 07:31 PM
The VI doesn't help as it looks like just a template of a state machine.
One way to work your logic. Place the boolean values of the old, coming from a shift register, and the new into a boolean array. Use boolean array to number to convert it to a U8 value. Now FF is the value of 0. FT is the value of 1, TF is the value of 2. TT is the value of 3. Just a binary number construction. Use that number to drive a case structure.
You might have to play around iwth the order of the build array to be sure the numbers are correct.
10-13-2016 07:37 PM
@RavensFan The vi is a modified template, the original being the JKI State Machine.
I guess your methods works ,too, and it would make the code cleaner.
I have heaps of hints now, so I'll just try them out and see what I get.
Thanks
10-13-2016 07:46 PM
What I often do in State Machines is to have the "next state" fed by a Queue (making it a Queued State Machine). Suppose I have a loop that I want to run when the Run button is True, and stop when the Run button is stopped. Consider the following States:
So you have two loops, an Event Loop (with no Timeout needed) and a Queued State Machine in its Idle State, waiting. You push Run, sends Start to State Machine, puts Loop on "Do Next" leading to Loop being called. Loop "does its thing" and calls whatever is on Do Next, i.e. Loop, so Loop keeps looping. Finally, you "unpush" Run, enqueuing Stop State which is inserted (probably) while Loop is runnning. Now the Queue has Stop followed by Loop (put on since Do Next is still Loop). Stop changes Do Next to Idle, but doesn't put anything new on the Queue, which still has final Loop. So final Loop runs, puts "Do Next", now Idle, on Queue, so presto, we're back at Idle. No muss, little fuss.
Bob Schor
10-14-2016 07:19 AM
@bockdoug wrote:@aputman This seems like what I wanted. So lets say one iteration of the procedure is done and I enqueue the message "Idle". This goes to the event strucutre that I've wired a timeout of 10ms to. There I put a case strucuture that, depending on the value of the button enqueues a message that goes to the appropiate state, yes?
What will happen if I press the button during the procedure? Will the new value be recognised?
I use aputman's setup all the time. All you do is in the Value Change event case is enqueue a Start state. The Start state then enqueues all of the states needed for the sequence, another Idle (or Wait For Event, whatever you want to call it), and another Start. So the state machine goes through the states of the sequence and then comes back to Idle. Do nothing in the timeout case. The Idle state will not need to add any items because there is still a Start in the state queue. And so it repeats until an event is captured. And yes, it will be added to the event queue even if the button was changed during your procedure. When the value of your boolean changes to FALSE, clear out the state queue and go back to Idle with no timeout.
10-14-2016 08:43 AM
The key is to not put any loops in your state machine (procedure) because they block execution of the event structure. Your create an artificial loop by calling the same state over and over, with a jump back to IDLE to check the status of the button. If the button changes value, clear out the state queue or go to a procedure shutdown case that eventually takes you back to an IDLE state.