hviewlabs

Dear fellow LabVIEWer's, who live in US:

I deeply apologize for this off-topic post, but this

is extremely important and extremely urgent.

I am Stanislav Rumega. Many of you know who I am. For

those who don't: I am a Certified LabVIEW Architect,

the author of LabHSM toolkit for advanced event-driven

programming in LabVEW (labhsm.com). I also recently

made available a free simpler but rather powerful

architecture too (check out the Application

development forum on LAVAG.org) I modified the famous

David Boyd's Tunnel Wiring Wizard for LabVIEW 8 and it

was me who gave you the PMS Assistant, the first tool

to conveniently access the secret Scripting features

after NI hid them in LabVIEW 8.

Some of you may also remember my desparate outburst on

this forum in Summer 2005. I really appreciate all the

support I received from most of you. For those who

don't know: I have lived in US for more than 9 years

absolutely legally. I have a Masters Degree from US

university. Neveretheless my GreenCard is nowhere in

sight! There is about a MILLION people like me,

high-skilled LEGAL immigrants who are stuck in this

"process" for many years. We are bound to employers,

can't accept promotions, our wives are not allowed to

work, can't even get driver licenses in some states,

etc., not eligible for unemployment, or social

security, though we pay for it, etc. If losing a job

we have to start the "process" all over again.

Please see here for more shocking details:

http://immigrationvoice.org/index.php?opti...6&Itemid=25

There is a major piece of legislation, High-Skilled

Immigrant Interim Relief Act of 2006 , introduced by

senator Cornyn that can pass TODAY, which will provide

significant relief to us, educated, high-skilled LEGAL

immigrants. Unfortunately, the anti-immigrant hatred

groups have waged a massive phone campaign to stop

this measure.

Please see details here:

http://immigrationvoice.org/forum/showthread.php?t=2484

http://immigrationvoice.org/forum/showthread.php?t=2498

Easy access to senator's contact info:

http://www.senate.gov/general/contact_info...enators_cfm.cfm?

I BEG FOR YOUR HELP! Please call your senators and ask

them to support this measure. You will help yourself,

because it is the handicapped status of foreign

workers, their boundeness to employer for the length

of the "green card" "process" that allows unscrupulous

employers to underpay us and displace you!

To my anti-immigrant "friends": Don't bother. I am not

gonna start a dispute here. I am appealing not to you,

but to my decent and compassionate American

colleagues.

What else can I do? All I have is my toolkit. I will

give a FREE LABHSM LICENSE to anybody who tells me

(please email me directly) that (s)he called his

senators and congressmen and asked them to support

this measure.

Of course, you can lie that you did. I won't be able

to check. It's your concience only you will have to

deal with if you do.

PLEASE HELP! Please call and let as many other friends

as possible know about this too.

This needs to be done TODAY!

Stanislav Rumega

With best regards,

Stanislav Rumega :!:

EDIT: I want to hear back whether you think anything is an improvement, such as:

1. Confining the action case to true actions
   
2. Not having the action queue enter the action case structure
   
3. Not allowing any actions to update the state
   
4. Providing the event data to the actions (I know you aren't too hot on this one. I think it is crucial to avoiding code duplication, however.)
   

Thank you for your efforts, David! Sorry, no offense, but I don't see any fundamental improvement compared to my original template (Last Event Data and a separate message queue were left out by me for simplicity - they are present in LabHSM and the attached "extended" versions).

I found having special "actions" like "Run State Machine" and "Handle Generic Error" to be convenient places to put that code in. Therefore, I need actions queue and next state wire going into the actions case. You can do it differently, but I don't see much danger in it. It's just a code template after all. Of course, you can also screw up a lot of things if you want!

If somebody prefers your version - it's their choice. I (and hope some other people too) like mine better (not as much as LabHSM, of course!).

Putting SM code into a subVI is fine, if somebody likes that better, but I strongly disagree with your upper loop code, as I said before.

Please note that your state indicator shows next state. For long transitions I prefer to have it displayed the source state rather than the destination.

As far as event data is concerned, you gotta use common sense in defining whether to implement particular functionality you want to have with different events or one event that carries data (then you will need to do the corresponding branching in the processing action(s)). For example, Exit Requested or some event associated with some button may not have much to carry in addition to the name of the event itself! Of course, for several buttons, you always can have only one event Button Pushed which also will carry the name of the button as data. Well, I guess there can be cases when this is preferrable, but obviously there are ones when it's not. I allow for both.

Attached package contains 2 more, "extended" templates. They are still fundamentally less powerful than LabHSM, but I added generic error handling, Last Event Data register, and, in the second one, a separate message queue. Master Slave Example 2 shows how to utilize the extended template with a message queue. I also decided to return to using Post Event subVI.

Please also note that my stand-alone message handler waits on the messsage queue in a separate loop, so it doesn't waste any CPU time. I can remove the UI loop and still be able to accept messages - this makes sense for modules, for example, with which you want to communicate asynchronously, but, say, they never need to display their FPs and hence process user events (daemons)

Download File:post-1166-1165111815.zip

If you don't close the original template then the typedefs will be incorrectly linked. If you do use the 8.0 save where you create a new copy in memory, then you still have to replace the typedef in the new file. The key is step #3

I just checked in 7.1.1: Once you have saved a VI with another name, only the new VI is in memory, the original is unloaded, so you can't screw up the original template unless you modify the typedefs without saving them as separate copies and then open the template again.

Sorry, but I don't understand how you can implement actions that have no information available to them. For example -- If you click on the Nth element, then the action should happen to the Nth element.

Actions have access to all the data of the module, whether you keep it in shift registers of the main ("actions") loop, controls, or LV2 style globals. You may want to have a separate, say, shift register that always contains the last event data (if any).

2. The action queue should be variant anyway so that it can carry information.

Not neccessarily, if they can access all the needed data directly

note - The idle runs are just waiting on the event structure, which is very CPU friendly.

It's still better to have the event structure fire only when a FP event happens

But how does the action know which element you clicked? And if you send a message, might it not contain some attribute data that you need to use, not just to decide which action to fire, but also how to fire the action?

Action doesn't need to know what happened - the SM schedules actions to run depending on event and state. An event can carry data, which can be accessed by a processing action, but the action queue itself doesn't need to carry anything except actions names. By having our own event queue we can assign different events to different values of some control when it changes, or we can have one event but which in addition to its name carries some value which actions that process this event can decode and use (if, say, you have a "Last Event Data" shift register as I already suggested)

I see the problem here. But if you do have different lists of states and actions, then you have the problem I described where you could incorrectly link the enums if you copy a template while a current template is in memory. Having anything module specific in the template would cause this problem.

While making a copy of the template that has typdefs one must folllow the order:

1. Open the template.

2. Save it as a custom named VI.

3. Open state and action typedefs from this new VI and save them as custom named ctl files.

After this point there is no risk of incorrect links. You can open the template itself again and even when it's open you can modify states and actions of your new VI - they will be loaded from stored into different ctl files.

This all becomes irrelevant in 8 if you use LV 8 libraries.

You are right. I had really hoped one could eliminate the event queue with the subVI, but I see that isn't likely.

How about this one? Download File:post-1519-1164406954.zip

OK, so what you have now is pretty close to my original.

The differences:

1.You put the SM logic into a module-specific subVI - fine if somebody wants to handle one more file per module.

2. You subVIed some queue initialization and really made it generic, but at a price - the type for the actions queue is variant now and you need extra conversions between variant and actions enum

3. You added a message queue, I left out for simplicity in my "simple" template (it is implemented in LabHSM). Fine. But all you do with it is just copying everything from it to the events queue. Having a message queue is beneficial for encapsulation. As I said before, to observe this principle, other modules shouldn't be able to write directly to the events queue. They should write to a message queue, but the recepient must validate the messages before generating corresponding events. The simplest is at least to check the message against a list of allowed (exported) ones. If it's not on the list it must be ignored (or you can even send a corresponding reply to the sender).

Please note that for maximum CPU efficiency it's better to read from the message queue in a separate loop (which can be in a subVI - like it is done in LabHSM) . You put your Process Message into the FP events loop and had to use a non-zero timeout there just to be able to check the message queue. This causes idle runs there!

Sorry, I didn't get the purpose of copying all the attributes of an event variant to the action variant. Events variants need (just one really) attribute to carry data in addition to the event name. Why would actions need attributes?

It encapsulates the action queue into a "Process Event" subVI that is responsible for converting events to actions based on state and then sending them to the action queue. Only the template and the Process Event VI need to be copied and modified for each new instance. The support VIs are generic and only require one copy. If you require different states and actions then they will need to be copied as well.

Exactly. Different modules made of the template will have different, module-specific lists of states and actions, hence, i.e. different typedef files. That makes all your subVIs module specific.

Another thing: Out of the same RTC considerations, pulling the next event from the queue must be done only when the action queue becomes empty. Only then enqueuing new actions and possibly modifying the state based on the current state and the discovered event should happen. In your template the "Process Events" VI (what you suggest as an alternative place to store the code I have in the Run State Machine Action) is called in more than one place, not necessarily when the actions queue is empty and, finally, I don't even see the means to change the state in there!

I am very glad I have somebody to discuss (and argue about) these things with! Thanks, David!

Trying to design a template such that there are no generic subVIs (i.e. VIs that would be copied over to other projects) is certainly possible but it isn't necessary.

I agree, but I am hesitant of creating non-generic, module-specific subVIs.

Just make a .lvlib file that contains your project starting point.

That's a possiblilty. Agree.

Or make some scripted interface to build your project skeleton (such as LabHSM for instance).

Well, that will be a little bit too much for a "simple", limited functionality, template, won't it? ;-)

I prefer the subVI because otherwise the functionality is buried in the action engine. It makes the lower loop unnecessarily busy. Having a subVI makes for one location for that code and more flexibility.

Well, all the behavior logic is concentrated in the Run State Machine action, so it is in one location and it doesn't get in your way at all while you are dealling with your custom actions. Alternatively, as in LabHSM, the entire behavior description can be stored in a data structure in a constant or an external file.

I admit that I do "open up" the action queue. It wasn't really with the intent of inspection or manipulation. Mostly it is meant to add actions. It would be better to encapsulate it such that the queue is unavailable. Make a "Fire Event" subVI that handles creating the array of actions and sending them to the action queue. You would have to make it some sort of LV2 global and initialize it to keep the queue reference invisible, but that would allow for any implementation for the message passing. This has already been mentioned as a nice feature.

Again, it's no business for any action to add other actions into the actions queue. This is the SM business! Which actions to run and which state to go next (event handling/processing) must be decided in one place in an RTC manner.

"Fire Event" can be created, but there won't be much to it beyond placing an event into the events queue (not actions!). Well, events carrying data as an attribute require one more function and two more wires and one more string constant (to name the attribute). In my first version of this template there was such subVI

I didn't understand what you meant by Run-to-Completion. I thought you referred to the entire list of actions that is generated from an event. In your implementation (and mine) the list is completed without any option of flushing the queue upon error or anything of that sort.

The information you provided refers to running EACH ACTION to completion. I completely agree that this is preferrable. The complexity you would have to add to NOT do this would be staggering. The complexity to do it right is beyond my humble skills so I would never even attempt it.

No, Run-to-Completion must be observed for the entire action sequence that is scheduled for the transition.

Yeah, you can flush the remaining actions on an error using some generic error handling code. However, that is a "shortcut". Think about this: the actions that had already been run before the error happened may have done something that the system is already not quite in the state it was in when we started the transition. But, since it hasn't managed to run all the scheduled actions (it stumbled on the error), it's not quite in the destination state either! If you decide to allow for interuption on error in the middle of a sequence of actions you must ensure that you undo (roll back) all the changes made by the actions since the start of the transition to make sure you are still in the state from which you started this unsuccessful transition.

Alternative way: The fact that some action resulted in an error can be looked at as an event. In a general case, if such event/error makes it necessary to flush the remaining actions, you'd better make that action the last in the transition, check for that error right within the action case and throw a corresponding event depending on which further branching happens - either the other original actions are run (no error) or the whatever necessary error handling actions are scheduled (if any) and the system is ordered to go into an error state (generic or specific).

Stanislav

David:

Thank you very much for suggesting improvements to the EDQSM template. However, I can't agree with the suggested modifications.

First, subVIing any code that has references to the actions and states typedefs makes those subVIs module specific, i. e. the user will have to create and maintain separate copies of them for each particular module he creates of this template.

Second, I don't see it beneficial to explicitly manipulate (or encourage the user to do that) the actions queue from other actions (except for generic error handling maybe, where, for example, you may want to flush all the remaining actions when you encounter an error) Actions can be sources of events, but it's no business for an action to determine which actions to run on that event - that's the business of the SM logic itself.

Third, the Run-to-Completion (RTC) principle is very important.

Please see below an excerpt from an excellent book by Dr. Miro Samek, Practical Statecharts in C/C++. I strongly recommend reading at least Chapter 2 to anybody who is trying to implement any state machine pattern in LabVIEW or any other programming language.

"

2.1.7 Execution Model - Run-to-Completion Step

In practice, executing actions always takes some time to complete. The state machine therefore alternates between two modes: idle

I have to agree, I was expecting some kind of simple state machine toolkit, e.g. with methods to add state(s), get next state etc.

Well, sorry if didn't meet your expectations. Sorry, if this is not as simple as you expected too. I hoped that on this forum the majority of people would not consider it too complex.

I didn't quite get this about "methods to add state(s), get next state etc." The next state is always in the respective shift register. You can check it from within your actions but in general it's only the Run State Machine action that is supposed to do that. To add a state you add an item to the enum list in the state type definition. Cases in the main loop are not states (I know, in the pattern NI presents as THE statemachine they call them "states")! But in this pattern they are actions. Well, in the classic Moore pattern, the code in "the state" case is also nothing else than a bunch of actions associatied with entering the state really, not the state itself. Making each case to have a meaning of a separate "action" rather a "state" (actually, all the actions associated with entering the state") makes it possible to reuse the same actions' code in different transitions without subVIing them. How many times did you realize: "Oh, when this happens and we are in that state, we need to do this too!"

Regarding wiring, wires are going up/down, inside/outside of loops and this becomes pretty hard to follow.

Would you prefer them running behind other objects?

I'm also missing shift registers and error handling within the loops.

Nothing prevents you from adding additional shift registers for your data. The pattern itself uses one to store the next state.

It also seems like a good idea to bundle all your references as they seem to be more or less needed everywhere.

Well, I disagree that " they seem to be more or less needed everywhere". Within the main loop for example, Actions and Events queue refs are used only in the Run State Machine action (unless you want to peek or interfere into those queues from within your actions)

In any case, if somebody sees what exactly can be changed to improve this pattern I would love to see that code modified by you. Where exactly can we straighten the wires, where do we bundle/unbundle, etc?

Error handling: Well, yeah, I could have added generic error handling, but in many applications errors are handled (different actions run, different error states exist) differently depending on what that error is. Plus, this would have added more stuff to this pattern that is already perceived as too complex by some.

I would recommend to catch specific errors inside your specific actions and throw a corresponding specific (or generic) error event which would cause the module to go to a specific (or generic) error state. This would allow you also to handle requests for error reset differently for different errors (again, if needed, of course).

Alright, I think I might be missing something here. I looked at the program attached in the 2nd post of this thread, and I think I'm a bit confused about its purpose. What is it that this is meant to provide? By reading the post and the title of the thread I was expecting a vi that could be used as a template to create a simple event based application. Now of course NI does provide examples of how to do this, so I was expecting something vastly superior to them.

My first impression when I opened the block diagram of the program was that it wasn't as simple as I was expecting. I see there is a lot going on, and I can follow most of it, however I guess I'm just missing something because I don't get the advantage to using this over a single queued event driven state machine. Another thing thats clouding my understanding of the code I think is the confusing routes of most of the wiring.

I'm hoping that someone can help explain what it is that makes this a more powerful queued state machine. I might also recommend straigthening up some of the wires where possible in hopes that maybe it will make the reasoning for using this as a simple event driven state machine template more clear to someone looking at it for the first time.

Dave

Here is a package that, in addition to the example provided earlier, includes a very generic template and, also, another example of two asynchronously communicating VIs. The latter example demonstrates how you can build applications as a collections of asynchronously communicating modules based on the same suggested template.

I am not really sure which single queued pattern you are referring to. Anyways, the actions queue contains the list of actions scheduled to run as the result of the last event happened (this actions "to do" list can depend not only on the event happened but also on the state at that moment). Having a separate event queue enables the module to asynchronously accept events from FP or from another module while running some actions (which also can generate events) at the same time. Processing of the events is done in RTC (run-to-completion) manner: though the code can accept events at any moment, it doesn't check for the next event in the events queue until all the actions of the current transition are complete.

This pattern allows you to design and implement the module behavior in terms of states, events and actions by defining for each transition the target state and which actions to run depending on which event happened and which state the module is in at that moment.

This implementation adds functionality of a Mealy automaton, which allows you to associate (arbitrary number of) actions with transitions between states as opposed to the Moore automaton where actions can be assosiated only with entering a state (the standard NI SM pattern) Mealy automaton allows to implement the same functionality with fewer number of states than Moore. In practice, a combined model can be used. Please note that this pattern can be easily extended to have state entry actions and even state exit actions (actions always run when a certain state is entered/exited) in addition to transition actions, i.e. to support a combined model as well.

See here, for example, for more details:

http://en.wikipedia.org/wiki/Finite_state_machine

As mentioned before, due to the flat state space, this pattern is still much less powerful than a hierarchical state machine implemented in LabHSM toolkit.

Sorry, I really don't see where the wiring is confusing, but I will appreciate any corrections that would make it clearer.

Download File:post-1166-1163459532.zip

Here is a modified version with a more convenient external timer dynamically created of a VIT. You can have multiple timers in the same state machine easily controlled this way.

Download File:post-1166-1163125044.zip

Here is an example of a simple event-driven queued state machine with front panel events and a timer. Made in 7.1.1.

Features:

Makes a distinction between state, event and action paradigms

Allows reusing the same code (actions) within a VI.

Concentrates coding all the behavior information in one place, the Run State Machine action, which is more convenient than spreading it all over the place.

The events are implemented as variants with a tag for the event name. So, they can carry any data in addition to the event name itself (this feature is not used in this example). The event data can be decoded in the respective

I think that that thread already makes the point pretty clearly.

Agree. The certification helped me to find previous gigs. The main (negative) factor in my personal job search is not the posession/lack of certification but the xenophobic, cruel, exploitive, unfair and simply totally screwed up US immigration system, in which I and hundreds of thousands of other people are trapped now. (See immigrationvoice.org, for example, for shocking details that are unknown to the majority of Americans.) So, as Chris knows, I am on the world wide job search now and hope my CLA will help me.

You need to be a premium member.

Just follow the link in Chris's signature.

Ok , I will consider that as soon as find a job.

If you don't want the traffic, you might want to edit your original post and remove the link there.

Nah, it's not a big deal.

However, editing previous posts - that's interesting! I can see the Edit button for my latest post, so, apparently I can edit it, but how can I edit my earlier posts?

OK, here: this sentence was added after posting the above had been done: at that moment my 2 last posts had Edit button, but not the one where I posted the link!

Here, let LAVA have all this traffic, not my site.

Download File:post-1166-1147021095.zip

Could you please describe th way of using notifiers or queues in detail

First of all, this is definitely a wrong forum to post such questions

Well, OK

Nu vot tak, naprimer.

Here is a simple event-driven state machine example. Of course, there exist simpler and more advanced patterns.

Using car analogy the state machine pattern NI pushes as THE state machine will be a Ford Escort (that's for for US readers, Zaporozhets - for former Soviet Union residents). The attached one is then a Chevrolet Malibu maybe. For the Rolls-Royce of state machines see labhsm.com

First of all, this is definitely a wrong forum to post such questions

Well, OK

Nu vot tak, naprimer.

Here is a simple event-driven state machine example. Of course, there exist simpler and more advanced patterns.

Using car analogy the state machine pattern NI pushes as THE state machine will be a Ford Escort (that's for for US readers, Zaporozhets - for former Soviet Union residents). The attached one is then a Chevrolet Malibu maybe. For the Rolls-Royce of state machines see labhsm.com

Sorry, can't upload anything from my computer for some reason right now. Not even to my web site with Frontpage. Gotta talk to the ISP

OK here it is:

http://labhsm.com/Simple_event_driven_SM.zip

Its done, see

http://forums.lavag.org/index.php?showtopi...745entry11745

Sweet, Brian! Congratulations. :thumbup: So you figured out the object creation technique, PJM demonstrated in his animation. Well, if you add the ability to change the properties and methods on the existing node, nobody will need my PMS Assistant any longer. And if you add the ability to create all (including private) objects themselves, not just their property and invoke nodes, then it will be even better.

:!:

Looks like nobody bothers to read readme files nowadays...

So here itis - I am explicitly telling you: this version is written with my LabHSM toolkit (I pretty much do all my applicatuions with it now). So you will need to download and install it from http://labhsm.com. Please make sure you get the correct version depending whether you use LV 7 or 8.

And, NO, you don't need to buy LabHSM license to run this utility. It will work without any limitations as soon as you install the LabHSM Library under user.lib

And YES, I hope you will get interested in LabHSM and explore it (unlimited trial period!) and maybe even buy it some day...

Here is the new version.

1. Property and method lists are hard coded as constants now. For LV8 the lists reported by LV8 itself are augmented with all the items that are listed in LV7 for the same classes. The lists still may not be complete.

2. You can select class now!

Enjoy.

Download File:post-1166-1143163934.zip

PLEASE NOTE :!: :

I have discovered another inconvenience for now. When you don't have those well known keys in labview.ini (SuperPrivateScriptingFeatureVisible=True and SuperSecretPrivateSpecialStuff=True) the lists will be missing the private properties and methods too (at least in LV8 I cheked that). Again, you can still type them in and set, but I will try to fix the lists as I described in the previous post ASAP.

My profuse apologies. It must have been a spurious anomaly.

Chris:

So, did you manage to make it work finally? That's what's most important.

Stan

Please post any properties and methods you find here. I will be glad to add them to the lists for the respective classes (just like I have done for the VI Diagram property for LV8).

I can already see, that the Diagram property for VI class is not the only one that's missing from the lists returned in LV8 (I had to add Diagram manually to the latest versions).

Well, even with the curent version, you can still select them in LV8 if you know their exact spelling. However, for everybody's convenience, I guess, I will need to (programmatically) retrieve the properties and methods in LV 7 and 7.1.1 and then add all the missing ones to the lists for respective classes even when the utility is running in LV8. This way we will get them all! :ninja:

I am also thinking about adding an ini file into which we could add the newly found properties and methods.

Stay tuned...

Adding the ability to drop selected properties back on the diagram has been on my list of "things todo"

Nice looking browser, Brian! :thumbup: Have you updated it for LV8 yet? PJM has figured the class hierarchy:

http://forums.lavausergroup.org/index.php?...findpost&p=7314

The key part (or even all the job) in generating any node and dropping it onto BD is performed by a very elusive BObjectCreate1. It is a VI, I guess, but it doesn't have the .vi extension! You can see its name showing up while dropping any node onto BD with any VI which monitor App.ActiveVI property (for example, with the Tunnel Wiring Wizard). The problem is you can't open a reference to it (even if you remove the B) - you will get "VI is not in memory". Therefore, I don't know yet how to replicate the LV8 Class Browser's node generating functionality. It's apparently done the same way as regular dropping a node from the Functions pallete. Something simpler can still be done like dropping the node onto the BD of a new VI. You can copy/drag it to the desired position in the desired VI from there. This is not as elegant, of course, but still can be useful. Maybe later, this week I will make some rough prototype.

Now you can try ANY string for a property or method name! Who knows, maybe you will find something new! Well, after a while, I guess...:headbang:

Please post any properties and methods you find here. I will be glad to add them to the lists for the respective classes (just like I have done for the VI Diagram property for LV8).

Ok, now we're finally getting interesting... :thumbup:

Do you you mean this utility had not been interesting before I added this last feature?!

But I also can envision that NI might try to close that loop hole too, putting even the execution of certain nodes behind the licensing.

Rolf Kalbermatter

Well, at least "mom" can't rehide the toys before we move to our next home (next LV version)

Check out the latest PMS Assistant, now you can try ANY string for a property or method name!

Stanislav