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 :!:

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

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. 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). Not neccessarily, if they can access all the needed data directly It's still better to have the event structure fire only when a FP event happens 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)

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

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! I agree, but I am hesitant of creating non-generic, module-specific subVIs. That's a possiblilty. Agree. Well, that will be a little bit too much for a "simple", limited functionality, template, won't it? ;-) 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. 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 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

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!" Would you prefer them running behind other objects? Nothing prevents you from adding additional shift registers for your data. The pattern itself uses one to store the next state. 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).

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

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.

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

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

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

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.

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

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

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.

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). Do you you mean this utility had not been interesting before I added this last feature?!

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