Jump to content

New Queued Message Handler


Recommended Posts

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.]

Download File:post-12-1076669963.llb

Link to comment
OK, have coded an example using this architecture have posted it at:

www.big-tent.co.uk

Please feel free to download it and comment on it.

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.

Link to comment
  • 3 weeks later...

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.

Link to comment

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.

Link to comment
  • 2 weeks later...
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.

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. :thumbup:

Link to comment
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.

Welcome to the forums Michael :beer:

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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.