State Machine Cases revert to numbers

[Brian Wells]

I have implemented a case machine using a type def enum to select the cases. The enum is a set of strings identifying each state. Initially the string for each state is listed in the case.
There is something that I occasionally do when modifying the enum which causes the case statement to display the index of the enum string. I am not able to revert back to the string display without completely rebuilding the case statement and cut and pasting my code from the old to new case statement.
I haven't been able to determine how I cause this to happen. What is it that I do to make this happen, so I can stop causing it to change? How to I make the case statement display the string state names again?

[swatts]

I do the same but use strict type defs of an enumerated type, I've never
seen this happen before using them. I have seen it using normal controls
when the enumerated type is changed and there is a string that is similar,
but not the same.
You get round it by finding the offending string in the case and replacing
it (without speech marks).

I'll reiterate I use Strict Type Defs and you have to try really hard to get
them confused.


Brian Wells wrote in message
news:506500000008000000F82B0000-1000509150000@exchange.ni.com...
> I have implemented a case machine using a type def enum to select the
> cases. The enum is a set of strings identifying each state.
> Initially the string for each state is listed in the case.
> There is something that I occasionall
y do when modifying the enum
> which causes the case statement to display the index of the enum
> string. I am not able to revert back to the string display without
> completely rebuilding the case statement and cut and pasting my code
> from the old to new case statement.
> I haven't been able to determine how I cause this to happen. What is
> it that I do to make this happen, so I can stop causing it to change?
> How to I make the case statement display the string state names again?

[Tims]

Hi Brian,

This happens when one of your enums connected to the shift register is
different than the other enums, in this state the shift register reverts
to the common data type of numbers.

I would check if all of your enums are actually type def'ed.

Tim

Brian Wells wrote:

> I have implemented a case machine using a type def enum to select the
> cases. The enum is a set of strings identifying each state.
> Initially the string for each state is listed in the case.
> There is something that I occasionally do when modifying the enum
> which causes the case statement to display the index of the enum
> string. I am not able to revert back to the string display without
> completely rebuilding the case statement and cut and pasting my code
> from the
old to new case statement.
> I haven't been able to determine how I cause this to happen. What is
> it that I do to make this happen, so I can stop causing it to change?
> How to I make the case statement display the string state names again?

[Marcano]

Make sure that all the enum constants are the same. once they all are, the problem will disappear.

[Adam Russell]

If there's more than a couple it would be good to make a custom control that
is strict type definition so that they all are the same even if you decide
to add to it.

"Marcano" wrote in message
news:506500000005000000A2490000-1003545641000@exchange.ni.com...
> Make sure that all the enum constants are the same. once they all are,
> the problem will disappear.

[Dave Karon]

Brian,
I am using state machines a lot, and have found this as well.
There is a very good reason for it, and that is somewhat equivalent to coersion.

The easy thing to do is: (this is what I do, now)
Whenever you change the enum either by adding an item, changing the string representation of
an item, or removing an item, (and maybe disable an item) you want to copy that enum first
and make the change on the copy.
Then copy the changed enum to a place beside each existing instance of the enum, eg the assignment of the
enum to the shift register in each state. I also copy the string of the state name to someplace I can
easily see it, usually just below the case identifier.
(I usually go through all states at least twice if it is a fairly complex state machine)
I then wire the new enum to the initial input of the shift register an delete the old enum.
(At this point the case "names" become numbers .. the numeric index of the names in the original enum)
Then I go through each state and change the wire from the old enum to the new one and delete the old one.
When you get the last one changed, you will see the case identifier change back to the "names".
Then go through all the states and check that the state names are correct. (that's why I copy the names)
Then you can create your new case.
This sounds like a lot of work, but doing this methodically saves headaches!

Of course the alternative would be to design your state machine before implementing it.
And never change it! Hah!!
Dave Karon


"Brian Wells" wrote in message news:506500000008000000F82B0000-1000509150000@exchange.ni.com...
> I have implemented a case machine using a type def enum to select the
> cases. The enum is a set of strings identifying each state.
> Initially the string for each state is listed in the case.
> There is something that I occasionally do when modifying the enum
> which causes the case statement to display the index of the enum
> string. I am not able to revert back to the string display without
> completely rebuilding the case statement and cut and pasting my code
> from the old to new case statement.
> I haven't been able to determine how I cause this to happen. What is
> it that I do to make this happen, so I can stop causing it to change?
> How to I make the case statement display the string state names again?

[CraigGraham]

Dave Karon wrote in message
news:3bb32d99@newsgroups....

> When you get the last one changed, you will see the case identifier
change back to the "names".
> Then go through all the states and check that the state names are correct.
(that's why I copy the names)
> Then you can create your new case.
> This sounds like a lot of work, but doing this methodically saves
headaches!

Waaay too much work. Look into strict typedefs. If the enum is defined as a
strict type definition then you can change the master copy and all
constants, controls and indicators created from that master copy will
automatically update. Saves a lot of time. 🙂

[Dave Karon]

Good point.
Thanks
Dave

"Craig Graham" wrote in message news:3bb338d9@newsgroups....
>
> Dave Karon wrote in message
> news:3bb32d99@newsgroups....
>
> > When you get the last one changed, you will see the case identifier
> change back to the "names".
> > Then go through all the states and check that the state names are correct.
> (that's why I copy the names)
> > Then you can create your new case.
> > This sounds like a lot of work, but doing this methodically saves
> headaches!
>
> Waaay too much work. Look into strict typedefs. If the enum is defined as a
> strict type definition then you can change the master copy and all
> constants, controls
and indicators created from that master copy will
> automatically update. Saves a lot of time. 🙂
>
>

[Dave_Karon]

So, I take back my previous reply.
CraigGraham said use strict typedefs.
I hadn't ever given that a thought.
Actually it doesn't have to be strict.
I still hold that you should design the process first, though.

Here's what you do.
On the front panel, create an enum with your cases.
Then select the enum and "Edit Control".
Change the control (your enum) to a Type Def.
Then save it.
On the diagram, create constants from the terminal.
Copy the constant as needed for your states.
The enum constants are still tied to the Type Def.
When you want to change the enum, edit the TypeDef ctl.
Save your changes to the TypdeDef ctl.
With the ctl still open "Apply Changes".
That will update ALL of the constants that are still connected to th
e Type Def.
It sounds like you are disconnecting the constants from the Type Def or the "AutoUpdate for Type Def" is turned off.
Any chance you created new enums on the diagram which are not connected to the Type Def, and editing the constants.