How to easily add a state to a state Machine

[Mentos]

Hi,

In my project I'm implementing a state machine using Enum constant in the same way shown in the attached vi file.

It works fine, but the problem is I must know the number of tests (or tests names) at the beginning in order to copy the same Enum again and again for every new state.

Lets say I have a state machine with 3 states only.

If I want to add a forth state after the vi is already done then I have to update ALL the "states" Enums with this new state, otherwise the vi is broken. In case of a project with a great number of states this can be very time consuming... It doesn't seem to be the best way to update each Enum in the vi every time I want to add a state.

Is there a way to update all Enums in my project at once ?! Is there a better way to implement this ?

Thanks in advance,

Mentos.

[MikeS81]

Hi Mentos,

you should use "type defs".

Mike

[Mentos]

Hi Mike,

I'm not sure what you mean by "type defs".

Can you send me an example ?

Thanks,

Mentos

[MikeS81 · Accepted solution]

Hi Mentos,

see this link please.

Mike

[Mentos]

OK,

I think this is what I need.

Please have a look at the attached file.

I used an Enum control called state to define 4 states (State 1 through State 4, kept in the type def. file, not attached) and then I wrote and read to/from this control variable to select the next state. This way the links are updated when I add an additional state.

It still looks a bit odd to update the state like this. Is this what you meant ?

[Jan_HeG]

No, why would you use local variables...?

All you need to do is this: 

[Mentos]

Of course you're right.

I tried to use it before with constants like you suggest and had errors (probably some kind of silly mistake on my side), so I went for the variables.

Any way it's working now and its exactly what I needed.

Thanks Jan,
Thanks Mike!

[johnsold]

The reason you had problems with the constants originally was that your enum was not a typedef.  When it is a typedef, all the constants change along with changes to the control.  This is a major reason for using ypedefs.

Lynn 

[onrb]

JKI has created a relatively simple state machine construct.

Has NI thought about simplifying something like this to a programming structure within the procramming menu?

This would eliminate the added wires and make for a cleaner VI.

I have tried several approaches for programming a measurement system and have it handle the UI and the SM seems to be the only scalable approach which is clean and simple. It would be great to see it even cleaner by eliminating the queue VIs and wires.

If simplified down to the common fundementals of a scalable queued SM, then there would be little debate about implementation (i.e KISS).