LabVIEW
State machine won't stop
Solved!
I'm going to point out a several things about this architecture that I don't like and think could be causing you problems.
1. I don't consider what you have a state machine. A key principle of a state machine is a shift register that will tell the next iteration of the while loop to what case of the case structure, i.e. "state", to execute next. Usually, that will involve some decision making at the end of the loop to help determine if any alternative states should be executed in the next iteration. You are just using the i terminal to determine which case to execute. What you have is pretty much a while loop alternative to a stacked sequence structure.
2. You only have states defined for 0(default), 1 through 6, and 20. So iterations 7 through 19 are just going to execute 0. I bet you think you are returning to state 0 after executing state 20, but you may actually be executing state 7, 8, 9, 10 etc. since they don't exist and will default to state 0. Since each state takes a long time to run, it will take what feels like for ever to get to state 20 and have the program stop.
3. Very long wait statements in most of your cases. Why do you have waits of 90 to 190 seconds in your various states. Each state will take a long time to run. It will make your program seem to be very slow. There is no way for a user to stop the program without it reaching the end without aborting it. One execution of your program will take over 34 minutes to run.
3. Your use of semaphores and single frame sequences to determine exeuction order. You acquire a semaphore and then execute a VISA write and read. IN parallel you wait at another semaphore before executing some instrument code and file writing after also waiting a long time of 70 to 190 seconds. If you wired up things in series you can guarantee the instrument executes after the VISA write and read without needing any semaphores.
4. You also have a memory leak on semaphores. You create them in each iteration. You acquire and release. But you never release the semaphore reference.
5. Since many of your states are similar, you don't need to duplicate all of the code among the different cases. It seems like the only difference between cases 1 through 6 is the command you write, or the amount of time you wait. Common code should be in a subVI that is shared among each case. Or just use a single case and as part of your state machine determine which index of an array of commands you will execute when you enter that case.
EDIT: I took so long creating a thorough write, I missed on timing to get the quick solution message out.
@RavensFan wrote:
I'm going to point out a several things about this architecture that I don't like and think could be causing you problems.
1. I don't consider what you have a state machine. A key principle of a state machine is a shift register that will tell the next iteration of the while loop to what case of the case structure, i.e. "state", to execute next. Usually, that will involve some decision making at the end of the loop to help determine if any alternative states should be executed in the next iteration. You are just using the i terminal to determine which case to execute. What you have is pretty much a while loop alternative to a stacked sequence structure.
2. You only have states defined for 0(default), 1 through 6, and 20. So iterations 7 through 19 are just going to execute 0. I bet you think you are returning to state 0 after executing state 20, but you may actually be executing state 7, 8, 9, 10 etc. since they don't exist and will default to state 0. Since each state takes a long time to run, it will take what feels like for ever to get to state 20 and have the program stop.
3. Very long wait statements in most of your cases. Why do you have waits of 90 to 190 seconds in your various states. Each state will take a long time to run. It will make your program seem to be very slow. There is no way for a user to stop the program without it reaching the end without aborting it. One execution of your program will take over 34 minutes to run.
3. Your use of semaphores and single frame sequences to determine exeuction order. You acquire a semaphore and then execute a VISA write and read. IN parallel you wait at another semaphore before executing some instrument code and file writing after also waiting a long time of 70 to 190 seconds. If you wired up things in series you can guarantee the instrument executes after the VISA write and read without needing any semaphores.
4. You also have a memory leak on semaphores. You create them in each iteration. You acquire and release. But you never release the semaphore reference.
5. Since many of your states are similar, you don't need to duplicate all of the code among the different cases. It seems like the only difference between cases 1 through 6 is the command you write, or the amount of time you wait. Common code should be in a subVI that is shared among each case. Or just use a single case and as part of your state machine determine which index of an array of commands you will execute when you enter that case.
EDIT: I took so long creating a thorough write, I missed on timing to get the quick solution message out.
1. Then why is it popular advice to "change a stacked sequence into a state machine?" I think it's a rudimentary state machine always executed in the same order, but it can easily be adapted to run states as needed instead. Would it have been any different if he just had an array of states 0-7 connected to shift register?
edit - ugh, i had a lot more that got wiped when i posted this
I'll just say I thought it was pretty cool for a newbie to construct something this advanced in the first place. But I do agree with everything else you said.
@johnsold wrote:
I agree. A key element in the definition of a state machine is that the next state is determined by the results of the current state and possibly external inputs which become available at the time the state completes execution. Code which cannot alter the sequence of execution is not really a state machine.
Lynn
I would say that it is common, but required, for the current state to determine the next state. Furthermore, it is also common, but not required, for the next state to be determined by outside influences.
My arguement says what is so different between the code that was written and a queued state machine that had all the states queued in an array but none of the states happened to be influenced by either of the two influencing factors mentioned above?
But your argument if the above conditions are true, it's not really a state machine? Then the advice given about turning stacked sequence structures into state machines cannot be true?
[edit]
I guess you could make a "true" state machine by simply having the current state influence the next state, but isn't that really cheating because you'll never have a choice of which state to execute next.
[/edit]
Hey, guys:
Please understand that I am debating you only because I want to be proud of this CLD badge, and any ill-conceived notions I have need to go away quickly.
Oh, and in case you didn't know, I truly appreciate your patience.
Okay, so following your train of thought, would a numeric constant in a shift register and an incremnting inside each state be closer to or be an actual state machine?
