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 R&D =- "I do not believe that Hell is a physical place. I believe that Hell is an hour of the morning." -- Jan 16, 2004
