create a list or container for states of a statemachine

[glstill]

Hi,

I am working on an application where several different types of devices will be put into a test fixture for board level testing.  Based on the type of board, i need to create an ordered list of all of the tests necessary for the device.  I have a state machine and a unique state for each of the tests and am trying to figure out how to create a list of tests for the specific device.  I want to have a check in each of the states to remove the first item of the list and then take the next value and wire it to the shift register used to go from state to state.  This should allow the state machine to switch to the appropriate state based on the device type and its necessary test sequence.

Should this be implemented with an array?  Is there some easier container to work with for this use case?  I need a container that will allow me to easily add between 5 and 30 state names (based on the needs of the device type) and easily remove them or increment a pointer to the next state in the container.

Thanks,

Gary

[MikeS81 · Accepted solution]

Hi Gary,

a string or "enum" array comes to my mind. You can use it for the selection of the states.

Do you have to transfer data?

Another way would be a queue. You can read the states with the enqueue function.

Hope it helps

Mike

[Mark_Yedinak]

I second the use of a queue. This is exactly what a queue is for.

[glstill]

Thanks.  I wasn't sure how i could neatly populate the queue, but realized that i could keep it clean by having a stacked sequence structure in side of the case structure for each device type.

[Mark_Yedinak]

I would avoid using the stacked sequence at all cost. This is not a very good approach to the solution. How are you determining which tests need to be run at which time? I would use a loop to enqueue the desired tests. You can use a separate table (which could be initialized from an external source such as an ini file) which defines all your available tests, hich hardware they apply to and the order they would need to be run. When your specific hardware is selected you can iterate over the table and select the tests that need to be executed. Using the state machine is still a good idea since it allows you to interrupt the exection as well as insert or include other general tasks that may be required during the tests.

[JÞB]

---

Mark Yedinak wrote:
I would avoid using the stacked sequence at all cost. This is not a very good approach to the solution. How are you determining which tests need to be run at which time? I would use a loop to enqueue the desired tests. You can use a separate table (which could be initialized from an external source such as an ini file) which defines all your available tests, hich hardware they apply to and the order they would need to be run. When your specific hardware is selected you can iterate over the table and select the tests that need to be executed. Using the state machine is still a good idea since it allows you to interrupt the exection as well as insert or include other general tasks that may be required during the tests.

---

Exactly the approach I use for the high-mix mainline functional test system i'm currently bringing on-line at CCI.  (and I'd bet Marks got a similar system in his pocket) 

[glstill]

The tests are already known and are not determined dynamically. Inside this SUBVI, I made a case structure to account for each of the different devices.  In each case, I put a stacked sequence structure.  In each sequence i put an enqueue element and planned to wire the appropriate state of the main state machine.  Thus when the app is started, they select the device type, and then a queue is built for all of the tests for selected device type.

Then in the state machine after i execute the code in the state, i would dequeue an element from the queue and take that dequeued element and wire it to the next state.

[glstill]

Why is the stacked sequence structure a bad idea for this SubVI which it's only purpose is to build a queue structure for a selected device type?

[Mark_Yedinak]

---

glstill wrote:
Why is the stacked sequence structure a bad idea for this SubVI which it's only purpose is to build a queue structure for a selected device type?

---

Maintainablility, readability and the horrors of wiring through a stacked sequence. Your stacked sequence may work for the moment but will quickly become a nightmare the moment you start adding new tests. Wiring through stack sequences is a nightmare and the code will quickly get very ugly. You will end up with lots of backwards wires. In addition stacked sequences are undesireable simply because once you get in it you have to complete the whole thing. There is no way to abort processing within the structure.

[JÞB]

---

glstill wrote:
Why is the stacked sequence structure a bad idea for this SubVI which it's only purpose is to build a queue structure for a selected device type?

---

I can't think of a single stacked seq the could not be replaced with a state machine.  If you use an enum for your states you automaticaly add a step description in each state.   A quick search on the forum will yeild several examples of Programmers "seeing the light" and abandoning sequence structures.  With almost no exceptions every post that contains "... I have a stacked Sequence..." the FIRST reply contains "Why use a Seq try a state machine"  Altenbachs nugget has a great discussion. and is required reading for my developers