create a list or container for states of a statemachine

[JÞB]

Great read

[glstill]

I am using an type-def enum in my main program's state machine, but this is only a subVI that is in the initialization state of my state machine.

I attached the code for reference.  I had a question about wiring the output queue.  Since the SUBVI is only executed one time, and the device type is the input parameter, can i simply wire the queue out from the last state of the stacked sequence for each of the device types?

[Mark_Yedinak]

---

glstill wrote:

I am using an type-def enum in my main program's state machine, but this is only a subVI that is in the initialization state of my state machine.

I attached the code for reference.  I had a question about wiring the output queue.  Since the SUBVI is only executed one time, and the device type is the input parameter, can i simply wire the queue out from the last state of the stacked sequence for each of the device types?

---

The reference would work as you have it wired. I still think you are missing the point that several of us have been trying to make. There is no good reason to use the stacked sequence structures. Even a simple state machine doing essentially the same thing is a MUCH better solution. As stated earlier you will get self documenting code if you use well named ENUMs. In the long run you will be MUCH better off if you get rid of the stacked sequence frames. It is up to you now whether you want to heed the advice from folks with many years of experience under our belts or to simply ignore it.

[RavensFan]

I would make sure both the test and the device are typedef enums.  Instead of using sequence structures.  I would create an array constant that has each of the required. For device 1 it would be test 1, test 2, and test 4.  All that would be in the case structure for each device is its respective array.  Then feed that array into an auto-indexing for loop that has just the enquue operation.

Now if you need to modify an order of tests, you would just go to the respective case structure for that device and edit the array.

Message Edited by Ravens Fan on 03-03-2010 01:37 PM

[JÞB]

---

Ravens Fan wrote:

I would make sure both the test and the device are typedef enums.  Instead of using sequence structures.  I would create an array constant that has each of the required. For device 1 it would be test 1, test 2, and test 4.  All that would be in the case structure for each device is its respective array.  Then feed that array into an auto-indexing for loop that has just the enquue operation.

Now if you need to modify an order of tests, you would just go to the respective case structure for that device and edit the array.

Message Edited by Ravens Fan on 03-03-2010 01:37 PM

---

Psst Ravens.   Use ini files.  One "main" to hold the station info and test specific config file names and "test specific" inis to hold the "steps" in order.  Then you have No need to touch the code (or recompile the app) to release a new test or modify the order of steps.

You are absolutly correct in requiring the type defs !

Message Edited by Jeff Bohrer on 03-03-2010 12:52 PM

[RavensFan]

---

Jeff Bohrer wrote:

Psst Ravens.   Use ini files.  One "main" to hold the station info and test specific config file names and "test specific" inis to hold the "steps" in order.  Then you have No need to touch the code (or recompile the app) to release a new test or modify the order of steps.

You are absolutly correct in requiring the type defs !

Message Edited by Jeff Bohrer on 03-03-2010 12:52 PM

---

If it was me, I would use an .ini file.  But the OP seemed resistant to go that route.  So I wanted to show a way to do the same thing he was doing already (one VI that statically locks in the test sequences), but without the mess of stacked sequence structures.

[glstill]

That is exactly what i am looking for. I didn't want to have an INI file for each device and then have to make sure that those files are never lost.  One subvi seems like a better approach for this scenario because the test steps will never change for these devices.

[Mark_Yedinak]

You wouldn't need a separate in ifile for every device. You could use a single ini file that contains all of the data for all of your supported devices. You could implement your application to have a default set of tests for a given device so if the file is missing you would be able to run something. However, if you use an ini file you can add tests later without requiring a code change. By using constants in the code everytime you add a new test you will need to touch that piece of code.