> >One can also just use the "Scan From String" primitive with
> >the enum type def constant as the "default value 1" and the
> >string you want to set as "input string". This way "output 1"
> >will return the enum type def with the "input string" value.
>
> Ouch! How could I have missed that? As long as you watch
> the error output for error 85 (the string is not an element of
> the enum), it works great. Even in LV 5.1, which is as far
> back as I have on this machine.
Beware though that if you have enum items set {"da","moo"} and
supply a string "dada" or "mooable", no error is returned. You'll
have to test the if the remaining string is empty. But even when
doing that it might not be wise to rely on enum item sets such
as {"bah","ba"} to lead to non-ambiguous results. Given an
input of "bah", result "bah" or result "ba" with remainder "h"
are both reasonable, though it seems to do the former.
As to state machines: the LuaVIEW toolkit provides for
Lua-driven state machines. These allow you to move the
state transition logic into a script while implementing the
state functionality in LabVIEW, all on a single diagram.
See http://www.citengineering.com/luaview/overview.html
The middle of that page shows an example.
Separating out the state transition logic solves the main
problem with pure LabVIEW state machines: as the state
machine grows, it becomes increasingly difficult to get an
overview of the full state transition logic by looking at the
diagram. The more cases you have to flip through and
examine, the worse your short-term memory is taxed.
Of course, this is also the motivation behind the state
diagram editor. Scripts, however, can be modified
together with diagram code. Modifying generated
diagram code, on the other hand, effectively detaches
it from the visual state-transition description.
Best regards,
Albert-Jan
---
Dr. A.C.J. Brouwer
CIT Egineering Nederland BV
http://www.citengineering.com
