Re: State machine diagram editor
Paul,
You wrote:
Beware though that if you have enum items set {da,moo} and
supply a string dada or mooable, no error is returned...
I handle this problem via the case structure's Default case. With string
driven state machines, my default case is always invalid case. If a
string does not exactly match the state names, the structure executes the
default case (invalid case) which generates an error and gives the
invalid string. I find this very helpful for debugging as well.
With an enum-based machine, avoiding a Default case let's you know
whether you've included all the desired cases at programming time.
Everything's a tradeoff.
--
EnWirementally,
Paul F. Sullivan
SULLutions (781)769-6869
when a single discipline is not enough
visit http://www.SULLutions.com
Re: State machine diagram editor
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.
I handle this problem via the case structure's Default case. With string
driven state machines, my default case is always invalid case. If a
string does not exactly match the state names, the structure executes the
default case (invalid case) which generates an error and gives the
invalid string. I find this very helpful for debugging as well.
Paul Brown
Upgrades (was RE: State machine diagram editor)
I am always reluctant to upgrade and usually only end up doing so when it is forced on me. In my experience upgrade is synonymous with new bugs and surprises that are going to require time and effort to fix. I'd rather work with features/bugs that I know about than mess with new ones... I still run Windows 2000 on most of my PC's and haven't yet upgraded from LV6.1. When I do upgrade software such as LabVIEW I like to wait until version x.1 comes out, as I make the assumption that the major new features/bugs in version x.0 have stabilized by that time. :) In all fairness though, NI seems pretty good at allowing you to keep multiple LabVIEW versions on your PC. Just be careful to keep original copies of the code in a safe place before doing a mass compile. I have a colleague who remembers punch cards. He still insists on FORTRAN and Windows 98... Johann Junginger. -Original Message- From: Scott Serlin [mailto:[EMAIL PROTECTED] Sent: Monday, January 19, 2004 10:59 To: Paul F. Sullivan Cc: [EMAIL PROTECTED] Subject: RE: State machine diagram editor Paul, Can you elaborate further on where the OpenG toolkit can be found with the Set Enum String Value VI? Is it part of the professional development suite? LV7.0 or LV6.1 or both? I have 7.0 but have not upgraded from LV6.1 yet because I do not like to redo code that is already working. On that note and this will most likely spawn another thread here, how does everyone deal with upgrades on the SSP? Does everyone just upgrade and fix all issues that come about from the upgrade or do people do what I'm doing and hang back for a while until the time is right to make the upgrade. I usually end up leap-frogging my versions. I take big jumps rather than little steps. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Paul F. Sullivan Sent: Sunday, January 18, 2004 6:11 AM To: Mark Smith Cc: [EMAIL PROTECTED] Subject: RE: State machine diagram editor Mark, You wrote: ... I use string driven state machines instead of enum type defs when I want to create a scriptable state machine. That is, the state sequence is driven by a text file that has information about what order the states are executed. This means the test sequence can be modified in the field using any text editor... The OpenG toolkit has a Set Enum String Value VI that would allow a text script to run an enum-based sate machine. I didn't know about the OpenG VI when I first needed this capability so I built a Set Enum with String VI that works with control references. If you'd like that, just let me know. -- EnWirementally, Paul F. Sullivan SULLutions (781)769-6869 when a single discipline is not enough visit http://www.SULLutions.com
RE: State machine diagram editor
Lewis Drake 01/18/04 03:02PM ... when I added a new value to the enum, the state case structure case labels would sometimes shift to ones which were incorrect, and I'd have to continually check every case and manually adjust the case names. Perhaps this is not a problem in LV7.0, I haven't bothered to check it because the strings work fine. Lewis, Just to let you know, this hasn't been a problem ever since 6.0 or so. (can't remember exactly when NI fixed this) John H.
RE: State machine diagram editor
Paul, Can you elaborate further on where the OpenG toolkit can be found with the Set Enum String Value VI? Is it part of the professional development suite? LV7.0 or LV6.1 or both? I have 7.0 but have not upgraded from LV6.1 yet because I do not like to redo code that is already working. On that note and this will most likely spawn another thread here, how does everyone deal with upgrades on the SSP? Does everyone just upgrade and fix all issues that come about from the upgrade or do people do what I'm doing and hang back for a while until the time is right to make the upgrade. I usually end up leap-frogging my versions. I take big jumps rather than little steps. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Paul F. Sullivan Sent: Sunday, January 18, 2004 6:11 AM To: Mark Smith Cc: [EMAIL PROTECTED] Subject: RE: State machine diagram editor Mark, You wrote: ... I use string driven state machines instead of enum type defs when I want to create a scriptable state machine. That is, the state sequence is driven by a text file that has information about what order the states are executed. This means the test sequence can be modified in the field using any text editor... The OpenG toolkit has a Set Enum String Value VI that would allow a text script to run an enum-based sate machine. I didn't know about the OpenG VI when I first needed this capability so I built a Set Enum with String VI that works with control references. If you'd like that, just let me know. -- EnWirementally, Paul F. Sullivan SULLutions (781)769-6869 when a single discipline is not enough visit http://www.SULLutions.com
RE: State machine diagram editor
An important point is that any state diagram (and logic) that you use to control a process should be related to the process and not to internal computer program states or actions. Make the state names represent states of the process being controlled and name them accordingly. For example, Purging Vessel, Filling Vessel, Emptying Vessel, etc. Don't confuse states with tasks. States relate to ongoing (usually not instantaneous) conditions of the process (e.g. emptying tank or filling tank) and tasks relate to process changes (e.g. open/close valves or start motors, read weight). In the most general case, I use 4 asynchronous loops running in parallel and accessing the same Task queue (which contains strings indicating which task is to be executed). First, I create the task queue, then insert the first task, Initialize. The Task queue reference number output from the Initialize Enqueue Element function is wired in parallel to each of the 4 loops. This forces the loops to start after the Initialize task is requested. Not all of the Loops described below are needed for every situation or program that is written. LOOP DESCRIPTIONS LOOP 1--Its job is to pop-up user interface windows. After a user interface window closes, this loop will typically request a task to be executed by placing a string on the Task queue. I use Loop 1 exclusively to handle pop-ups so the other loops may continue to run without being interrupted by pop-up windows. If no pop-up windows are needed then this loop is not present. LOOP 2--This is the User Interface loop and contains an event structure that responds to user push button requests or control value changes, etc. When a request is made, this loop appends a task request string to the Task queue. LOOP 3--This is the State Diagram loop and it implements the state logic using strings for the state values. A shift register on this loop carries the state string descriptors. Each state can call for tasks by placing a task string on the Task queue. The State Diagram loop may contain states such as: Idle; Initialize; Filling; Emptying; Create Report. There is very little logic required to do these tasks within the state diagram loop. Its job is to keep track of the status (state) of the process being controlled and to monitor analog and digital inputs and to call for needed Tasks to be executed by the Task Execution loop. Each state in the State Diagram loop usually contains a case statement with T/F cases. The True case has logic for the first time the state is entered. The False case contains logic for normal operation in the state. You can detect the first time entering a state by comparing the current state with the last state by adding an extra element to the state shift register. When they are not equal then this is the first time in the state. LOOP 4--This is the Task Execution loop. It is the only one of the 4 loops that can cause things to happen directly. It continually monitors and removes the Task queue strings that are placed on the Task queue by the other loops and performs the corresponding tasks. Typical tasks done are: moving process actuators, reading non-scanned inputs like weigh scales, plotting, saving to disk, printing reports, and updating screen controls. Frequently, there are several tasks that must be executed in sequence. For example, assume that after Task 1 is done that Task 2 must immediately be started. This can be accomplished entirely within Task1, by placing a Task 2 string on the Task queue as part of the Task 1 logic. This eliminates the need for the logic in Loops 1,2 and 3 to place both Task1 and Task 2 on the Task queue. Of course, Task 1 can be skipped when Task 2 is directly requested by Loops 1, 2 and 3. In some cases, you may want the state transition logic (or other loops) to wait for all active tasks to be completed before moving to the next state. You can accomplish this by setting a Busy Boolean flag True when the Task Execution loop is processing tasks and clearing it when the Task loop is idle. I've found this architecture to be quite flexible. It is the basis for most of my high level programs. Lewis Drake Process Automation Corporation Belle Mead, NJ 908 359-1011 www.processauto.com
RE: State machine diagram editor
Paul et all, The OpenG toolkit has a "Set Enum String Value" VI that would allow a text script to run an enum-based sate machine. I didn't know about the OpenG VI when I first needed this capability so I built a "Set Enum with String" VI that works with control references. If you'd like that, just let me know. 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. PJM"Paul F. Sullivan" [EMAIL PROTECTED] wrote: Mark,You wrote:... I use string drivenstate machines instead of enum type defs when I want to create a scriptablestate machine. That is, the state sequence is driven by a text file thathas information about what order the states are executed. This means thetest sequence can be modified in the field using any text editor...The OpenG toolkit has a "Set Enum String Value" VI that would allow a text script to run an enum-based sate machine. I didn't know about the OpenG VI when I first needed this capability so I built a "Set Enum with String" VI that works with control references. If you'd like that, just let me know.-- EnWirementally,Paul F. SullivanSULLutions (781)769-6869"when a single discipline is not enough"visit http://www.SULLutions.com Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
RE: State machine diagram editor
Thought I would add my two cents on this sub-topic - I use string driven state machines instead of enum type defs when I want to create a scriptable state machine. That is, the state sequence is driven by a text file that has information about what order the states are executed. This means the test sequence can be modified in the field using any text editor. Clearly, this flexibility is not always required (or even advisable) but when it is, it's really easy to implement in a string driven state machine. Mark Smith ([EMAIL PROTECTED]) I also use files to define the state transition logic plus I use a second text file to define the outputs (actuator values) that change at state transitions. If you write your state logic properly, you can completely control the state transitions and the analog and digital output changes at state transitions, by simply changing the text files. Last year, I gave a talk on this at our local LabVIEW User's Group meeting. If you want, I can send you a simple program I used during the talk to illustrate my approach. The documentation is a little sketchy, but you can figure out what is going on by looking at the diagrams. Lewis Drake Process Automation Corporation Belle Mead, NJ 908 359-1011 www.processauto.com
RE: State machine diagram editor
Mark, You wrote: ... I use string driven state machines instead of enum type defs when I want to create a scriptable state machine. That is, the state sequence is driven by a text file that has information about what order the states are executed. This means the test sequence can be modified in the field using any text editor... The OpenG toolkit has a Set Enum String Value VI that would allow a text script to run an enum-based sate machine. I didn't know about the OpenG VI when I first needed this capability so I built a Set Enum with String VI that works with control references. If you'd like that, just let me know. -- EnWirementally, Paul F. Sullivan SULLutions (781)769-6869 when a single discipline is not enough visit http://www.SULLutions.com
Re: State machine diagram editor
Howard, John [EMAIL PROTECTED] write: It lets you create state machine based LabVIEW programs by 'simply' drawing a state diagram. You can switch between diagram view and code view. It probably mostly useful for documentation, where state diagrams are needed. It is not part of any version of LabVIEW, you have to pay for it separately. The price is $995. (the standard price for any LabVIEW tool from NI) I am selfishly hoping that no one buys it so that they may change their mind and include it LabVIEW Professional or something like that. (For $995 I'll keep using Visio to draw the few state diagrams I need) Well we usually use SmartDraw www.smarttdraw.com instead. It's about 1/10 of the price of Visio and does IMO just a good job at creating state transition diagrams or whatever your favorite state machine documentation is. I have looked at the State Machine Toolkit and believe that it is fine for the standard state machines a lot of users usually encounter but my state machines usually always tend to be just a tiny little bit more involved so that I would have to hand edit the generated state machine afterwards anyhow and once modified manually you can't seem to go back to continue with the State Diagram Editor. If it would be part of the Professional Developer version of LabVIEW I might give it another try ;-) Rolf Kalbermatter CIT Engineering Nederland BVtel: +31 (070) 415 9190 Treubstraat 7H fax: +31 (070) 415 9191 2288 EG Rijswijkhttp://www.citengineering.com Netherlands mailto:[EMAIL PROTECTED]
RE: State machine diagram editor
One tip that I would offer is to consider using a Strict TypeDef Enum to drive your state machine rather than a string. Part of the reason for this is to prevent accidental coding errors such as mis-typing a string or forgetting to implement a case. Also, if you further develop your state machine into a component (based on LabVIEW Component Oriented Design (LCOD) - see the book A Software Engineering Approach to LabVIEW for details) which uses a LV2 style global approach to locally contain component information, the Enum turns into a very simple way of accessing the components functions. (perhaps I should have broken up that 'sentence' a little) One minor drawback is having to save the Strict TypeDef Enum in a separate .ctl file. However, I have also taken advantage of this when implementing multiple components which share the same states/functions. Anyway - just my thoughts. John Howard Scott Serlin 01/16/04 12:17PM Thanks for the info. I was hoping for a faster way to add and modify states to the state machine. Also, does anyone have any state machine tips that they can share? I typically use a string driven state machine. I then call out each state from other states. I also use a nextstate local variable so that I can reuse particular states in the machine over and over again and not have to replicate the state throughout the machine. Let me and the email list know your tips. Thanks. Scott -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: Friday, January 16, 2004 7:48 AM To: [EMAIL PROTECTED] Cc: Info LabVIEW (E-mail); 'John' Subject: Re: State machine diagram editor Rolf K. wrote: I have looked at the State Machine Toolkit and believe that it is fine for the standard state machines a lot of users usually encounter but my state machines usually always tend to be just a tiny little bit more involved so that I would have to hand edit the generated state machine afterwards anyhow and once modified manually you can't seem to go back to continue with the State Diagram Editor. The inability to go back to the editor after you manually edit is true of most computer-aided wizards. The fundamental problem is that the wizard knows how to maintain a state machine under certain conditions and how to modify various pieces when you change something in the editor. Once you introduce a non-standard component, the wizard has no idea how to handle that component as the system changes. The once-you-manually-edit-you-can't-go-back-to-automatic problem covers the State Machine, Express VIs, and a lot of tools built by just about every piece of helpful software ever written on this planet. It requires either a sophisticated AI to recognize all the components that can be introduced into a system by a user or a very restricted set of things the user can introduce. Notice how HTML editors handle non-standard tags. Pojundery, Stephen R. Mercer -= LabVIEW RD =- I do not believe that Hell is a physical place. I believe that Hell is an hour of the morning. -- Jan 16, 2004
Re: State machine diagram editor
It lets you create state machine based LabVIEW programs by 'simply' drawing a state diagram. You can switch between diagram view and code view. It probably mostly useful for documentation, where state diagrams are needed. It is not part of any version of LabVIEW, you have to pay for it separately. The price is $995. (the standard price for any LabVIEW tool from NI) I am selfishly hoping that no one buys it so that they may change their mind and include it LabVIEW Professional or something like that. (For $995 I'll keep using Visio to draw the few state diagrams I need) John H. Scott Serlin 01/15/04 05:53PM Can anyone tell me what the state machine diagram editor toolkit does and which version of labview it is part of? Thanks in advance. Scott
Re: State machine diagram editor
Rolf K. wrote: I have looked at the State Machine Toolkit and believe that it is fine for the standard state machines a lot of users usually encounter but my state machines usually always tend to be just a tiny little bit more involved so that I would have to hand edit the generated state machine afterwards anyhow and once modified manually you can't seem to go back to continue with the State Diagram Editor. The inability to go back to the editor after you manually edit is true of most computer-aided wizards. The fundamental problem is that the wizard knows how to maintain a state machine under certain conditions and how to modify various pieces when you change something in the editor. Once you introduce a non-standard component, the wizard has no idea how to handle that component as the system changes. The once-you-manually-edit-you-can't-go-back-to-automatic problem covers the State Machine, Express VIs, and a lot of tools built by just about every piece of helpful software ever written on this planet. It requires either a sophisticated AI to recognize all the components that can be introduced into a system by a user or a very restricted set of things the user can introduce. Notice how HTML editors handle non-standard tags. Pojundery, Stephen R. Mercer -= LabVIEW RD =- I do not believe that Hell is a physical place. I believe that Hell is an hour of the morning. -- Jan 16, 2004
RE: State machine diagram editor
Yes. When you customize a control, the ring in the control editor may be set to three values: 1) Control 2) Typedef 3) Strict typedef In these last two, it is the word typedef or type definition that is important. It defines a datatype, which exists even if the control itself is never loaded onto a visible front panel. Pojundery, Stephen R. Mercer -= LabVIEW RD =- I do not believe that Hell is a physical place. I believe that Hell is an hour of the morning. -- Jan 16, 2004 |-+ | | Scott Hannahs| | | [EMAIL PROTECTED]| | | du | | | Sent by: | | | [EMAIL PROTECTED]| | | a.army.mil | | || | || | | 01/16/2004 03:15 | | | PM | | || |-+ --| | | | To: Scott Serlin [EMAIL PROTECTED], LabVIEW -Info [EMAIL PROTECTED] | | cc: | | Subject: RE: State machine diagram editor | --| At 14:25 -0600 01/16/2004, Scott Serlin wrote: I do not have any controls to access in my vi state machine. As an example, I control a piece of equipment that labview turns on, gets some measurements, logs those measurements to a database, and then shuts down. I do not access any front panel controls to run my via. All of that is done through a test executive. My state machine is set up by placing a string in each case statement that refers to the next state. The initial string is set outside of the while loop that makes up the state machine. Can I still utilize the strict type def enum solution in a similar manner or better? I think so. If it is an enum then the case statement will automatically allow intermediate states to be created with the correct case when the enum is modified. As an enum you can use the increment primitive to go to the next state in a sequence. As an enum defining the next state to go to is not susceptible to typos. -Scott
RE: State machine diagram editor
At 14:25 -0600 01/16/2004, Scott Serlin wrote: I do not have any controls to access in my vi state machine. As an example, I control a piece of equipment that labview turns on, gets some measurements, logs those measurements to a database, and then shuts down. I do not access any front panel controls to run my via. All of that is done through a test executive. My state machine is set up by placing a string in each case statement that refers to the next state. The initial string is set outside of the while loop that makes up the state machine. Can I still utilize the strict type def enum solution in a similar manner or better? I think so. If it is an enum then the case statement will automatically allow intermediate states to be created with the correct case when the enum is modified. As an enum you can use the increment primitive to go to the next state in a sequence. As an enum defining the next state to go to is not susceptible to typos. -Scott
RE: State machine diagram editor
Thanks for the info. I was hoping for a faster way to add and modify states to the state machine. Also, does anyone have any state machine tips that they can share? I typically use a string driven state machine. I then call out each state from other states. I also use a nextstate local variable so that I can reuse particular states in the machine over and over again and not have to replicate the state throughout the machine. Let me and the email list know your tips. Thanks. Scott -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: Friday, January 16, 2004 7:48 AM To: [EMAIL PROTECTED] Cc: Info LabVIEW (E-mail); 'John' Subject: Re: State machine diagram editor Rolf K. wrote: I have looked at the State Machine Toolkit and believe that it is fine for the standard state machines a lot of users usually encounter but my state machines usually always tend to be just a tiny little bit more involved so that I would have to hand edit the generated state machine afterwards anyhow and once modified manually you can't seem to go back to continue with the State Diagram Editor. The inability to go back to the editor after you manually edit is true of most computer-aided wizards. The fundamental problem is that the wizard knows how to maintain a state machine under certain conditions and how to modify various pieces when you change something in the editor. Once you introduce a non-standard component, the wizard has no idea how to handle that component as the system changes. The once-you-manually-edit-you-can't-go-back-to-automatic problem covers the State Machine, Express VIs, and a lot of tools built by just about every piece of helpful software ever written on this planet. It requires either a sophisticated AI to recognize all the components that can be introduced into a system by a user or a very restricted set of things the user can introduce. Notice how HTML editors handle non-standard tags. Pojundery, Stephen R. Mercer -= LabVIEW RD =- I do not believe that Hell is a physical place. I believe that Hell is an hour of the morning. -- Jan 16, 2004
RE: State machine diagram editor
Hi John, I do not have any controls to access in my vi state machine. As an example, I control a piece of equipment that labview turns on, gets some measurements, logs those measurements to a database, and then shuts down. I do not access any front panel controls to run my via. All of that is done through a test executive. My state machine is set up by placing a string in each case statement that refers to the next state. The initial string is set outside of the while loop that makes up the state machine. Can I still utilize the strict type def enum solution in a similar manner or better? Scott -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Howard, John Sent: Friday, January 16, 2004 12:49 PM To: [EMAIL PROTECTED]; Scott Serlin; Thorpe, R. Mark Subject: RE: State machine diagram editor One tip that I would offer is to consider using a Strict TypeDef Enum to drive your state machine rather than a string. Part of the reason for this is to prevent accidental coding errors such as mis-typing a string or forgetting to implement a case. Also, if you further develop your state machine into a component (based on LabVIEW Component Oriented Design (LCOD) - see the book A Software Engineering Approach to LabVIEW for details) which uses a LV2 style global approach to locally contain component information, the Enum turns into a very simple way of accessing the components functions. (perhaps I should have broken up that 'sentence' a little) One minor drawback is having to save the Strict TypeDef Enum in a separate .ctl file. However, I have also taken advantage of this when implementing multiple components which share the same states/functions. Anyway - just my thoughts. John Howard Scott Serlin 01/16/04 12:17PM Thanks for the info. I was hoping for a faster way to add and modify states to the state machine. Also, does anyone have any state machine tips that they can share? I typically use a string driven state machine. I then call out each state from other states. I also use a nextstate local variable so that I can reuse particular states in the machine over and over again and not have to replicate the state throughout the machine. Let me and the email list know your tips. Thanks. Scott -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: Friday, January 16, 2004 7:48 AM To: [EMAIL PROTECTED] Cc: Info LabVIEW (E-mail); 'John' Subject: Re: State machine diagram editor Rolf K. wrote: I have looked at the State Machine Toolkit and believe that it is fine for the standard state machines a lot of users usually encounter but my state machines usually always tend to be just a tiny little bit more involved so that I would have to hand edit the generated state machine afterwards anyhow and once modified manually you can't seem to go back to continue with the State Diagram Editor. The inability to go back to the editor after you manually edit is true of most computer-aided wizards. The fundamental problem is that the wizard knows how to maintain a state machine under certain conditions and how to modify various pieces when you change something in the editor. Once you introduce a non-standard component, the wizard has no idea how to handle that component as the system changes. The once-you-manually-edit-you-can't-go-back-to-automatic problem covers the State Machine, Express VIs, and a lot of tools built by just about every piece of helpful software ever written on this planet. It requires either a sophisticated AI to recognize all the components that can be introduced into a system by a user or a very restricted set of things the user can introduce. Notice how HTML editors handle non-standard tags. Pojundery, Stephen R. Mercer -= LabVIEW RD =- I do not believe that Hell is a physical place. I believe that Hell is an hour of the morning. -- Jan 16, 2004
