How to configure states in state machine

[ravik1990]

How to I modify i.e. add/delete states in a state machine architecture without having the problem of coercion dot?

[tusharsharmapec1]

Usually users tend to make a mistake by adding more items to the enum constants that creates the coercion dots in all the associated enum constants used in the state machine.

A simple way to avoid this would be-

1. Convert the enum constant to a control.

2. Edit the items present in the enum.

3. Now convert it back to a to constant in the existing state machine

4. Replace the previous enums in the state machine to avoid creation of coercion dot.

Or 

The user can also save the enum as a type def so that whenever there are any changes made to the original enum they are reflected in the other enums placed in different parts of the state machine.

[ML927]

Hi Ravik,

You just need to make your state enum a type definition.

http://zone.ni.com/reference/en-XX/help/371361J-01/lvhowto/creating_type_defs/

Any time you need to add or delete a state, modify your type definition, apply the modifications and it will update all your enums at once 😉

[Bob_Schor]

A Corollary of Maxime's Reply is the following Good Rule for LabVIEW Programming -- Whenever you create an Enum, immediately convert it to a TypeDef, replacing the original Enum with the TypeDef.  You should do this even if you intend to only use the Enum in one place -- sooner or later, you'll need it again ...

Bob Schor

[natasftw]

---

@tusharsharmapec1 wrote:

Usually users tend to make a mistake by adding more items to the enum constants that creates the coercion dots in all the associated enum constants used in the state machine.

A simple way to avoid this would be-

1. Convert the enum constant to a control.

2. Edit the items present in the enum.

3. Now convert it back to a to constant in the existing state machine

4. Replace the previous enums in the state machine to avoid creation of coercion dot.

Or 

The user can also save the enum as a type def so that whenever there are any changes made to the original enum they are reflected in the other enums placed in different parts of the state machine.

---

Doing option 1 is quite the mistake.  Don't ever do something this silly.  You want to take the second option.  In the state machine, you're going to use that same enum in every single state to determine the next state.  You'd have to take those excessive steps with every instance of your enum.  Don't do that.  As this user, and the several that followed, pointed out, you want to use the typedef option with your enum so you can quickly update them all.

One thing to be careful with: when you delete states from the enum, you'll want to delete those cases from your case structure as well.

[palanivel]

The best for enumerated based state machine is using typedef enum

Which will allow you to add/modify cases at any point of time with minimal effort....

don't prepare for "add cases for every value" during modification of states,which will add cases for all the entries in enum and adds case inconsistently "cases will mess up with logic inside case" especially during modification...

[palanivel]

If coercion dot is main concern

Coercion dot is created just because there is a mismatch in the enum initialized to shift register and value passed to shift register inside loop....

typedef will solve this issue

[spastichawk]

---

@ML927 wrote:

Hi Ravik,

You just need to make your state enum a type definition.

http://zone.ni.com/reference/en-XX/help/371361J-01/lvhowto/creating_type_defs/

Any time you need to add or delete a state, modify your type definition, apply the modifications and it will update all your enums at once 😉

---

While this works for adding states it seems to break the case structure when deleting or renaming a state. I have tried combinations of just deleating the state in the typedef or typedef and case structure but each time I get a coersion dot and all the state names are blank in the case structure. Is there a prober way of deleating a state without polluting with 'dummy' unused states?

[Ben]

---

@spastichawk wrote:

---

@ML927 wrote:

Hi Ravik,

You just need to make your state enum a type definition.

http://zone.ni.com/reference/en-XX/help/371361J-01/lvhowto/creating_type_defs/

Any time you need to add or delete a state, modify your type definition, apply the modifications and it will update all your enums at once 😉

---

While this works for adding states it seems to break the case structure when deleting or renaming a state. I have tried combinations of just deleating the state in the typedef or typedef and case structure but each time I get a coersion dot and all the state names are blank in the case structure. Is there a prober way of deleating a state without polluting with 'dummy' unused states?

---

I can only speculate but I think ...

1) at least one of the cosntants in your diagram is not an instance o the type-def

OR

2) You did not apply changes and do a "save All" after editing the type def.

Ben

[crossrulz]

---

@spastichawk wrote:

While this works for adding states it seems to break the case structure when deleting or renaming a state. I have tried combinations of just deleating the state in the typedef or typedef and case structure but each time I get a coersion dot and all the state names are blank in the case structure. Is there a prober way of deleating a state without polluting with 'dummy' unused states?

---

If the enum is wired directly to the case structure, then the case selector should show the enum names.  So if you have a case for A and you delete A from the enum, you should have a broken VI because you have to fix something.  Likewise, if you add values to the enum, your VI should be broken because you need to add more cases to handle the new values.  I have never seen a coersion dot on a case structure do to changing enum values.  Could you post an example of this?