JDave

I also like how the properties and methods are listed in alphabetical order in the right-click menu. It took a little while to get used to but it is much faster to find that property you are searching for. Now I just need to use the Class Browser more often.

Unfortunately, I didn't get the security system installed in time... Though I don't think any security system would work against the combined efforts of a 4-year old and a 2-year old.

Those sets are amazing. I am apparently not into trains quite enough. My train was a fun object to create, though. I like the duplos because when I am done I have a 3' high object. I set my baby inside of the cab! Can't do that with the little legos (or those model trains, BTW)

I thought you engineers would appreciate some Lego sculpture for your alternate job title... I thought about integrating with Mindstorms NXT, but after considering the associated HW/SW incompatibilities I opted not to. So I posted to this forum instead. David

I hear nothing but negative, Stan. Don't you like anything in there? Even the nice straight wires? But this will mis-link the original template VI if there is another VI in memory that calls it directly. And if you are using 8.x then you have a choice of how you save and you could leave it in memory. My only point here is that ANY module specific items make for potential mislinkages. Picky, picky. :laugh: That is a bit too purist. You are talking about front panel user speeds on blazing fast computers. This would have no effect on CPU usage nor program performance. It is so close that I wouldn't be surprised if a separate loop for the message queue actually used more CPU usage. YES. This is good. I don't get the "if any". Do you really want to create dozens of different events for all the possible FP configurations? I really like the "Last Event Data" idea. That cleans up the code a bit and gives you your typdef'd queue back. I think this event data really is missing from your template. EDIT: I want to hear back whether you think anything is an improvement, such as: Confining the action case to true actions Not having the action queue enter the action case structure Not allowing any actions to update the state 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.)

In fact, the correct order is (pre-8 where you can save as with options) : 1. Open the template 2. Save it as a custom named VI. 3. Close the original template 4. Open typedefs and save as 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 1. Yep 2. The action queue should be variant anyway so that it can carry information. 3. I made the message handling a subVI so that one could add all that checking logic. note - The idle runs are just waiting on the event structure, which is very CPU friendly. 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. 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? Some other differences is that the action queue reference does not enter the action case structure and the state only enters the actions (read-only). This helps to enforce the type of behavior you were wanting.

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

If you right click on the Project Name in the Project Explorer (top line), the last option will be Properties. You can set them in there (Conditional Disable Symbols).

Here is a small update to the template. I renamed it EDAM for Event Driven Action Machine. It is different enough from a State Machine architecture that I gave it a new name. 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. Putting the "Action Send" inside of the Process Event cleaned up the diagram a little, but it basically looks the same. The main difference in terms of what I was discussing is that the action queue is only used to read actions in the bottom loop. I considered making the "Get Next Action" a LV2 global as well and completely remove the action queue from the lower loop. But this would make another non-generic VI to be copied around. One thing I am not liking is the copying of the template. Most often there would be multiple versions in memory. If you copied from a template you had already modified then the new copy will have links to the module specific VI and controls. If you then open these and "Save As" you can easily mis-link the new copies to the original template. David Download File:post-1519-1164156231.zip

You're welcome. I am also enjoying this discussion. Of all the subVIs I added to the template, only one is non-generic. That is the event-to-action (SM) VI. The main template allows for events (FP and external message) and for actions. These are tied together with the SM VI, which acts as the interface mechanism between this producer consumer structure. I see it is in one place, but it does get in the way. What business does the SM have in the action case structure? It just complicates the lower loop. And if there is a subVI for converting events to actions, then you can enqueue actions in the subVI. This is the same as enqueueing them from the SM case. I am not arguing with you on this. Whether it is a subVI or a case, I agree that one place to handle event-to-action logic is preferable. But if it is so important to not allow this, why is the action queue there in the bottom loop? And why does the Run State Machine action look like any other action and it can add actions to the action queue? Having the action queue in the lower loop and then adding actions directly to it seems to be encouraging such behavior in other actions. I have only programmed this way so far and I would have to see some driving need to do otherwise. I agree that it is a potential problem, but I don't think it is always a problem. Actions don't always change system state and sometimes actions in a sequence do depend on the success of previous actions. I think that most often this can be handled without aborting the process and thus preserving the RTC principle. Again, if this is so important then the action queue should not even be available in the action loop. I will create another template (hopefully tomorrow) to illustrate some of my ideas. David

I understand the desire to have all of the code in a single VI, and it certainly was apparent that you were trying to do that. From the aspect of distributing a template and keeping things simple for people I concede there is a desire to keep it all in a tight package. But you already have two controls that are dangling onto the template that need to be copied around. 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. Just make a .lvlib file that contains your project starting point. Or make some scripted interface to build your project skeleton (such as LabHSM for instance). I prefer the subVI because otherwise the functionality is buried in the action engine. It makes the lower loop unnecessarily busy. I have seen people put the event structure in the state machine too and I don't like it for the same reason. It seems like a carry over from polling architectures. Having a subVI makes for one location for that code and more flexibility. 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.My first attempt at this type of architecture (which was inspired by your LabHSM, BTW) had some hybrid event-actions in the lower loop. The upper loop would pass events to the lower loop (with a prefix to make it readably obvious they were events). The case structure would handle events and actions. Events would contain the functionality general to that event and then some logic to decide what actions to enqueue. I felt that a subVI to handle event-to-action logic was unnecessary for my application. So it is somewhat similar to your template here, except that there is a case for every event instead of a single case to handle all events. Having looked at your template, and rethinking my first attempt, I am inclined to think that the subVI for event-to-action logic is a better implementation. It cleans things up and provides a replacement for the hsm logic box from your LabHSM stuff. I prefer to have scripting engines that build skeletons and then I tweak them. That was one of my big complaints about the HSM code was that the logic was completely hidden. It has its pros and cons but as a programmer I prefer to see the code. I thought, as I was looking at your simple template here, that you were trying to create a simple template by removing pieces from the HSM template. The idea is still good but there are perhaps some carry overs left in there. 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. I would like to hear your thoughts on what I wrote here. I am open to correction. David

I don't know why anyone would want to settle for a five-dimensional existence. There is so much more out there. Consider this small example that I picked up on a brief hyper-dimensional googling experience:

It is in the "Dialog & User Interface" palette. For the front panel it is still in the "Numeric" palette.

I like the general idea presented here (events causing actions to occur) and I use a similar approach in my programming. There are several limitations in the template presented, many of which have already been discussed. One that I find quite limiting is the inability to send data with enqueued actions. I attempted to clean up the template and add this data sending ability. Download File:post-1519-1163630345.zip Improvements: Increased readability (judicious use of subVIs) Reduce bottom loop to handling actions SubVI for converting events to actions Allows sending of events or actions through message queue Allow data to be sent with actions (via variant attributes) Queue errors will shut down the VI I prefer errors to be handled by the actions, so only queue errors are used to shut down the loop. I used subVIs because hiding a lot of the functionality in subVIs makes for a cleaner look and a better place to modify behavior. The wires are also hopefully as suggested... I did not include examples, though the behavior should be apparent. There are other aspects which I still do not like, but did not address. I don't like the queue naming as the mechanism to allow other VIs to communicate. I don't think using enums as the actions allows for complete flexibility, but they have some benefits. Strings might be more general purpose, plugin friendly. This implementation does not allow errors to interrupt a sequence of actions. All actions are performed regardless of the success of previous actions. But this was supposed to be simple, right? This really can be a powerful method because you generally think about VI behavior this way. A message from another VI should cause something to happen. A front panel event should cause some things to happen. Often the behavior is dependent on what state your software is in. By having a subVI to convert a message or event to a list of actions, and allowing it to be state-dependent, you avoid a lot of problems associated with a strict QSM as seen in the examples. Problems include state explosion, handling transitions, code duplication, and just calling something a state that is really an action. David

I tried to do the same thing once and ran into the restriction that ALL events must be specified in ONE (the first) event registration node. If I understand your situation, the workaround could be to register for all of your potential events upfront, using an empty reference constant for the ones that are not wanted yet. Then you would wire the correct control reference when you want to dynamically add that event. And you wire the empty constant to dynamically unregister the event. I have used this method successfully before. As Ton said, if you leave any of the events unwired they stay unchanged. David

crelf, You reminded me about my promise to look for that pattern. If I have it, then it is stuck in a tub somewhere. Like I said, it was a busy year with the newborn and we didn't get the Halloween decorations out at all However, you can see the pumpkin at Pumpkin Masters. It is not available for download, but at least you know where it came from. BTW, nice pumpkin :thumbup:

But wouldn't 1337 be outside of the rules anyway? It is more like a translation... A good spell checker might help with misspellings of LabVIEW. I added LabVIEW to my FF2.0 dictionary, and now I receive no red underline for LabVIEW. However, these all have red lines under them (as does the majority of your above quote, sheesh!) LabView Labview LABVIEW David

Or if you are on the right boards -- L4b\/13W

At the expense of more raspberries, you may notice that the automatic spell checker feature is not available when typing from within SOME browsers.

I don't have 7.0 so I couldn't test this 7.0 version, but I was able to open it with 7.1 successfully. Try it out. David Download File:post-1519-1162706506.llb

I will look for it. Hopefully I still have it.

I was a little too busy this year, but here is one from last year.

It is a property of the Numeric Class David

I also benchmarked this some time ago and got varying results. Depending on the data I got better results with explicit or implicit coercion. However, the difference was minimal. So for most applications it would be better to do explicit coercion because it exposes what is happening a little more clearly (or more correctly if you fix any latent bugs ). David

That is a really nice example VI. :thumbup: I have found scripting to be fun and rewarding, but it is quite an undocumented jungle to deal with. This makes a nice path. David p.s. Yes, I know. Very droll.