Firstly, this is just an extension of Jack Hamiltons ideas on the State Machine Architecture, so credit where credit is due.

I have taken the queued message handler from the NI examples and added a variant to the queue. This enables you to pass data directly to a state, this saves memory if this data only has a short lifetime. It also alows the introduction of a general error handling frame. I have also added the event structure with a 50ms timeout as a frame in the main application. Best thing is to look at the example..

Has anyone employed this architecture before, if so how did it pan-out? Otherwise it would be good to hear your views on this idea. Must stress, I haven't used this in anger yet; i am posting it here for comments.

Thanks, Tom.

[EDIT: Just spotted some mistakes in the first version i posted here, have updated the file.]

This post has been edited by TomWP: Feb 13 2004, 10:59 AM

OK, have coded an example using this architecture, see below.
Please feel free to download it and comment on it.

This post has been edited by TomWP: Feb 19 2004, 02:04 PM

Is this an advertisement?

I use the queued state machine and the event structures almost to the point of over use.

One method I use passing information in a comma separated string.

State,other info.

When I dequeue the element I can run the string through a match pattern to match the "," The before match is always the initial state case. The After substring is passed into the state. The state called handles the substring.

Variants are useful as well as passing clusters in the queue. I have used both methods but the string approach still is my favorite method. I never worry about needing to change the cluster when I need to pass more information than originally planned. Just add another match pattern inside the state that requires more information.

Sorry, wasn't supposed to be an advert. Have changed it to a post rather than a link. Was just trying to save posting it here.

Shouldn't have asked.

The download seems to be missing a few files.

Program looks clean.

I am not sure I see the the advantage of using variants as compared to flattening and unflattening to string since each data type used to transform the variant back to a the data type is held inside the case structure. The only advantage is the "to variant" primitive is a smaller symbol that "Flatten To String".

OK I am new to the group. How do I get the smiley faces on the note.

As this statement will probably prove I have not used the variant data types much. Yet one advantage I see is the ability to package attributes with the data. Say, what device the information comes from, the date and time information is sent, data type. This information may be set or retrieved and moves with the data. Variant functions seem to be more forgiving. You can coerce a double to an I16 numeric type using the variant functions. Flatten a double and try to bring it back as an I16.
Whether or not one would consider the things I mentioned as an advantage is entirely up to the programmer and the application.
I tend utilize the string functions more for queue element and find that when I resort to clusters sooner or later I regret it. As far as using variants is concerned I can see a few possibilities for the variant data type and glad the option is available.

I always use clusters for the queue elements and haven't had any problems aside from transient idiocy on my part.

Are you using strict typedefs for your clusters?

Usually it is the feature creep monster that bites my clusters. Plus it is a hold over from programming on 486 machines with limited resources, keeping the data as flat as possible was more important then.

Strict type def on the cluster is something I haven’t done. Will this correct all places where the cluster is bundled unbundled?

In conjunction with bundle/unbundle by name everywhere, yes.

Since the variant carries data type information with it it is possible to create a generic unpacking VI. Also by passing an array of variants rather than just one, (or a cluster) you can have a generic variable/data list that can be passed to subVIs in the State Machine. These subVIs can have a strict typedef VIServer interface _or_ free form front / connector panels and still communicate with the State Machine. This lets you implement the subVIs as plugins.

Essentially, with a little extra work you can have arbitrarily complex subVIs plug in to your State Machine, add new ones at any time and never have to change the main state machine interface definition to the subVIs.

For a hint of the interface power of variants look up the Universal_Probe.vi that Jim Kring did. This has a generic variant parser built in, which populates a tree control with whatever data type you point to.

Welcome to the forums Michael

Yes, I agree with you 100%. Using variants is much more flexible. I use the array of variants implementation you mention as the main pipeline for passing data to test modules in a test engine. Check out this related post:

Passing variant data through string comm link.