statemachine ARCHITECTURE

[johnsold]

Can you please release a black hole VI? If placed on a diagram it would pull all programming errors within its event horizon where they would never be seen again. Hmmm..., maybe just add this as a special event case in the event structure - the event horizon case.

Lynn

[Christian_L]

Lynn,

I think that is called the Diagram Disable Structure. You can place it around all of your code and remove all run-time errors in your application. 

[Christian_L]

A more serious query; how frequently are you using the following techniques in LabVIEW:

1. Buffered or queued state machine - using a queue or FIFO or something similar to buffer up a series of states in advance

2. A static code framework with dynamic code plug-ins, i.e. you have the core of your LabVIEW application that runs and during run-time you develop new LabVIEW modules that you call dynamically from your main application. I'm thinking of something like a PLC, where you have a static I/O scan engine which retrieves data from I/O channels and places it in a memory store. The core application may also perform data logging or passing data to another application across the network. You then develop VIs for control or process logic that are called dynamically by the core application and interact only with the memory store for their I/O data. The I/O scan engine runs all the time, while the process logic may be updated at run-time.

[Ray.R]

---

@Christian L wrote:

1. Buffered or queued state machine - using a queue or FIFO or something similar to buffer up a series of states in advance

If this includes the use of Event Structures, then I use "queued events" all the time in my main vi.

2. A static code framework with dynamic code plug-ins, i.e. you have the core of your LabVIEW application that runs and during run-time you develop new LabVIEW modules that you call dynamically from your main application. I'm thinking of something like a PLC, where you have a static I/O scan engine which retrieves data from I/O channels and places it in a memory store. The core application may also perform data logging or passing data to another application across the network. You then develop VIs for control or process logic that are called dynamically by the core application and interact only with the memory store for their I/O data. The I/O scan engine runs all the time, while the process logic may be updated at run-time.

Not quite this elaborate, but I use the Open VI Reference to run VI's that are selected at run-time, thus allowing to develop code in parallel, while the main vi runs.  Once ready, it can also be selected and run by a UI.

---

However, what we really need is a Warp-Event Structure, which creates code as you define it.  It should come with a Neural Interface to convert brain waves into vi's.

[johnsold]

Christian L,

I use a variation of the queued state machine extensively, although under normal conditions I do not expect more than one element in the queue at any given time. Typically I send commands from the GUI loop to the Process loop via queues and the receiving loop uses the information from the queue along with current state information to define the next state. I usually do not queue up the states directly. I find the overhead to insert a higher priority state at the other end of the queue and to decide what to do with already queued states to be more hassle than it is worth given the relatively infrequent need to queue up several states.

An example I am working on now uses a shared Wait state for several different functions. I have a shift register with a "Mode" signal which defines whether it is in Cycle, Average, or Delay mode. The Wait state uses that information, along with other data, to determine the next state.

I have not used any form of dynamic plug-ins.

Lynn

[richjoh]

I know I'm a little slow here but TBob only mentions 1 reason to use strings vs enums. I can think of strings disavantages (i.e. easier typo errors) vs enums. If you type def your enum its hard to go wrong...

Tbob wrote "Here is one advantage to using strings:  If you have a requirement that the next state depends on two conditions, A and B, you can concatenate strings to call the next state.  Example, condition A might be Red, Blue, Green.  Condition B might be 1, 2, 3.  If the conditions are Red and 3, you can concatenate to form a string Red3 and use it to call the next state.  Sure you can use enums, all possible combinations of conditions, and use logic to determine which enum to select from the array, but using strings is easier in this case.  However, for the most part, enums are better.  I suspect people use strings instead of enums because it is easier and faster to code at first.  I'm guilty of this in simple applications done quick and dirty.  But one typo can destroy the time savings."

richjoh

[tbob]

That was the only advantage I could think of for using strings instead of enums.  There shouldn't be a set rule on what to use.  I think it is up to the individual to use what he feels comfortable with.  I believe enums are much better to use and has much more advantages over strings, however I find myself using strings most of the time.  Go figure!!!!  I guess its because I find it easier to create strings on the fly rather than create an enum and have to edit the list for each new entry.   If I make a typo, my default case, "Developer Error", gets called and I code a pop up message to tell me: "Stupid!  Learn how to type!!!!"

Here is another big advantage of enums.  When you edit the list, the new entries are automatically available to the case structure that the enum is wired to.  You don't have to type it again when creating a new case.  Note to self:  use more enums in state machines.

[JDave]

I agree with all of the reasons why enums are *better*, but I also don't use them as often as I should.  A couple things that come in handy when using strings in a Queued Message Handler.  They may be clever, or they may be problems waiting to happen.  I am still enjoying my explorations of LabVIEW architectures.

• I can have a single event for multiple controls (like on a custom toolbar), then use the controls' labels as the string sent for processing in the consumer loop.
• If I use a delimited string for several commands at once, this is just a string.  This means that queueing up a single action or multiple actions looks exactly the same.  Then I convert the received string to an array of strings and execute each one.
• Commands sent across TCP/IP already show up as strings.  These can then be used directly on the state machine.

I have never used the strings for a plug-in architecture, and I think if I had to I would be in way over my head.

[Ray.R]

---

@johnsold wrote:
I use a variation of the queued state machine extensively, although under normal conditions I do not expect more than one element in the queue at any given time. Typically I send commands from the GUI loop to the Process loop via queues and the receiving loop uses the information from the queue along with current state information to define the next state. I usually do not queue up the states directly. I find the overhead to insert a higher priority state at the other end of the queue and to decide what to do with already queued states to be more hassle than it is worth given the relatively infrequent need to queue up several states.

---

I do the same as Lynn.  There are 2 variations:  2 loops or 3 loops.

The first loop always contains the Event Structure.

The 2nd loop contains User Interface / Display event handling.

The 3rd loop takes care of any acquisition, number crunching (calculations), etc.

For simpler vi's which have 2 loops, the second loop contain what are descibed in the 2nd & 3rd loops above.

So far, I implement this only in the main UI vi.  However, I am now starting to implement it in a sub-vi, which must have an algorithm ( intelligence) to find P1dB faster.  In this case, the Event Structure would take care of memorizing past measurements and provide directions for the power adjustment loop.

I want to explore ways of creating more efficient vi's & sub-vi's using this method.

RayR

[Christian_L]

Thank you all for your feedback and answers to my questions. Please keep them coming.

As part of my work in the Systems Engineering group at NI, I am working on designing and developing recommended architectures and application components for use in developing typical LabVIEW applications. These architectures and components are published as Tutorials/Application Notes on DevZone. This is a relatively new project for us and so there aren't a lot of these in place yet. One example of such a component that has been around for a while is the Command-based Communication Architecture for RT-to-Host communication. Of course the common State Machine implementation using a Case structure in a Loop with a shift register could be considered another such recommended infrastructure component. Using queues or FIFOs to extend this to a queued State Machine would be an extension to the recommended architecture.

As LabVIEW applications do vary widely in scope, market, application type, etc. we see more value in providing recommendations for individual infrastructure components (such as a state machine, event handling in a UI, etc.) rather than developing many large architectures for complete applications. These infrastructure components can be used in a range of applications and can be combined 'a la carte' according to the needs of individual applications. In effect, we are not doing anything different than most experienced LabVIEW developers are doing on their own (i.e. developing reusable application components), but we hope to share what we learn and develop with a wider audience and help new LabVIEW developers to come up the application development curve more quickly. Newer LabVIEW users tends to focus on individual features and mastering them, while we focus on the LabVIEW application architecture as a whole before thinking about the specific implementation for each component of the architecture.

Thanks.