statemachine ARCHITECTURE

[Ben]

Christain,

That looks like the example that was presented to us at NI Week 2005.

It suffers from the same problem mentioned in this thread!

The transmit packet should be a cluster of enum and string. Once unflattened, the enum can drive the decoding.

Ben

[Christian_L]

Thanks Ben,

One goal of this particular implementation (which may not be stated in the article) is to support non-LabVIEW and non-Windows clients on the other side of the cable. Therefore the data passed in the TCP packet was kept as generic as possible to allow for easy decoding on a wide range of platforms and programming languages. One focus for this is to be able is to develop RT applications that can run as deployed independent components in a networked system with different tools on each box.

For LabVIEW-only applications your suggestion is a logical extension to this recommendation.

[Ben]

"....support non-LabVIEW and non-Windows clients on the other side of the cable..."

My job is done here!

Ben

[jccorreu1]

tbob mentioned an interesting use of concatenating strings to determine order or states.
just last week I came up with something not quite kind of similar, though much less flexible, using binary logic. 

I've got an event structure in one loop of this particular vi.  The front panel has a ring control, whose elements are populated during run-time, and therefore can change.  And I wanted it to make certain it has the current set whenever the user clicks.  Unfortunately ring events are somewhat constrained so I came up with this hack, using a combination of the mousedown? and valuechange events.
On the ring value change event, I check if the oldval = newval.  then convert the boolean into binary, and pass it to a shift register of the loop.  The next call to this same event does the same, and takes the previous answer, converts each into strings and concatenates them, so that now I have a string of 2 binaries representing the sequential conditions of the 2 calls to the event.  Then I simply compare this string to binary equivalent strings representing the order that I require for execution of portions of the code within the event.

In general, i create type defs for everything.  I use a number of queues and notifiers, whose elements are usually type defined clusters, to pass commands and data within a single vi (they have 2 or 3 loops), and amongst a number of vi's that I have running in parallel with each other.  this whole setup is kicked off by a top level vi that runs in the background, whose purpose is to create all the queues and notifiers and pass them to the major vi's which it also kicks off to run in parallel.  and for queues I only place something at the begining of the queue in the very rare situations (such as needing to interupt a process and shut off hardware)  ( this is not to be construed as a substitute for an actuall physical kill switch)

But this is my first major, dynamic, complex, project.  And I'm looking for other ideas for overall architectures, because I can see ways in which my current implementation is innefficient.

[tbob]

One improvement that I can see right offhand is the replace your two case structures with one.  Wire the string into the case structure selector (?).  Make a case when the string is "10" and another case when the string is "11".  Add a default case to handle code when the string is neither "10" nor "11".  You can add more cases for different string values expected.

[jccorreu1]

all i can say to that, besides thanks, is "doh!"

i did also think that tbob's string concatenation might work using rings or enums with type defs, by extracting the strings from those controls, so as to avoid the problems of typos.

i tend to use a lot of references and property nodes.

any comments on my general architecture?  something i plan on doing in the future is taking advantage of classes.  the overall architecture I use may not be whats cumbersome, but some fo the other things that I didn't know about when I built this (such as classes in labview)

[jccorreu1]

I guess it might also be helpful to say what kind of application my code is for.

Software timed.  Process control and data acquisition for experiments.  Basically its event driven for manual operation and definition of processes.  There is a seperate major vi for the user interface layer, which runs parallel to a seperate major vi for the hardware interface layer.  When a process is actually run the entire thing gets sent to the case in the HIL which solely writes to the hardware, while most of the rest of the program is waiting for very limited set of user activity (i.e. stop), while the data acquisition continues in a different loop of the HIL.

I am considering hardware timing.  But what I'd really like to do is make a linux from scratch for real-time.

[altenbach]

---

tbob wrote:
One improvement that I can see right offhand is the replace your two case structures with one.  Wire the string into the case structure selector (?).  Make a case when the string is "10" and another case when the string is "11".  Add a default case to handle code when the string is neither "10" nor "11".  You can add more cases for different string values expected.

---

Actually, that is not quite the same, because he seems to compare with "not equal". The first case will turn TRUE for [00, 11, or 01]

 and the second case will turn TRUE for [00, 10, or 01]. There is overlap.

Still, it seems a bit convoluted to do all that song and dance converting boolean to a number to a string and concatenating strings.

A better way would be to just keep the boolean in the shift register, built an array from the two booleans, and convert it to a number 0..3 (binary 00, 01, 10, or 11). Now just wire this to a case structure and make cases for the desired values (set the radix of the case structure to binary for even more readable code ;)).

Here's a quick draft, take it as a starting point.

Message Edited by altenbach on 02-13-2008 03:08 PM

[Tushar_Jambhekar]

Good long discussion about Using Type defs and strings

To the first post of joeycao i would like to add one more suggestions

i  keep "No Event" state as my default state instead of startup. Generally when you startup your program you do some initialisation (which is never required afterwards) and then just sit idle till any event is generated. as soon as event is triggered; you respond to the event and become idle once again.

if you keep the no event as the default case then you dont need to tell system "GO IDLE"... "KEEP IDLE"  "STILL KEEP IDLE"

And Regarding Altenbach's response

i was expecting case structure binary radix to be found in Darren's Weekly Nugget!

any ways thanks for a nice tip

[falkpl]

I guess I am in the minority here I often use queued state machines and use STRINGS.  I understand the advantages of enums and there are many almost all to do with code maintains and error prevention.  The reason I use strings SOMETIMES is that I encapsulated functional reuse for a queued state machine anto a couple of subvis, these vis handle much error detection idle states queue order state tracking and some other nice features.  Since I use these vis with many projects and for multiple different queued state machines it is easier to reuse strings than enums.  I also use the trick of making substates with concatenating strings (State:Substate).  Either way I think that either approach works.  To avoid the issue of mis typing I have a default case called undefined which announces the offending invalid string.