jgcode

Well I am under the impression the flat sequence structures are better than stacked sequence structures, namely because all the code is visible, you don't need to use sequence locals to pass data and the data is available to other nodes after a frame executes rather than then entire structure. It still suffers from other things like rearranging frames, or cannot execute the same frame twice or stopping half way through. Oh yer and it this is another great use case too. But there was no announcement, but I am sure if you have 20 frames strung out in a single structure you may get one from your co-worker

Why would you suggest it then?

The .lvproj file is xml, so it might be the easiest to cut and paste in a text editor. Otherwise I am sure there must be a way you could read it out programmatically using property nodes and add it to your project. I would be interested to see your example if you go that way.

Well, technically that would now come under my first example - natural data flow

There are traditionally three ways to sequence nodes in LabVIEW Natural Data flow Artificial Data Flow Sequence Structures Natural data flow sequences nodes from the "natural flow of data" i.e. you wire up A + B = C and the "+" operation cannot execute until data has arrived at both it's terminals. Artificial data flow refers to the use of wires connected to nodes that are not required however, in connecting the nodes you have created a data flow dependency (albeit a fake or artificial one). Finally you can use sequence structures - stacked or flat - these can sequence nodes that are independent of each other. As each subsequent frame will not execute until the previous one has completed. You will find a plethora a reasons on why people consider the use of sequence structures to be bad style e.g: Cannot change execution order with cutting and pasting code Forced to wired from right to left when passing data between frames due to the use of sequence locals Cannot run the same frame twice Have to run the entire sequence from start to end - cannot conditionally abort half way through etc... Cases are hidden Using error clusters and connecting them up is a great way not only to create a basic error handling scheme but to sequence nodes too. See attached example.

Cool

Hi Sharon One way to do this is to use the Description and Tip of a control. When the VI is running and the user hovers the mouse over the control the Tip Strip will appear. When the user open the Context Help and hovers over the control the Description will be updated. No need for events, as it all handled internally.

No worries, glad you got it to work!

Agreed. While its nice, in this case, you have taken the time to go into detail, there is always more in-depth knowledge available out there, and can't you feed everyone. That is why I posted links to design patterns. I was also answering one of the topic starter's original questions: And I did post this disclaimer: Anyways, because they are not a basic topic, I am sure you can make a hell of a mess using dynamic events, the user could easily: E.g. Pass the reference deeply into their app (like your control ref example) and fire them from anywhere in an application making it difficult to debug. As this would be down to having good programming style (or not). I actually can't see using a user event or Val(Sign) is any different is this case (aside from the point you mentioned of asynchronous firing of sequential Val(Sign) nodes)? Branching the Event Registration Refnum and passing it into two Event Structures, causing missed events (when you should have branched the User Event Refnum and creating a second Event Registration Refnum). Not understand when events go into memory - statically registered events go into memory when the top level VI goes into the reserved state and are removed when the top level VI finishes executing. Dynamic events have the ability to go into and out of memory meaning the user can control this, meaning there is more that could go wrong as they have the potential to destroy the queue and registered event. etc... Additionally if an Event Case takes a longer time then human reaction time to complete, handling the event in the User Interface Event Structure may cause the front panel to lock up. Regardless of whether front panel locking is disabled (only for notify events), the UI will still be unresponsive. A PC-(Events) design pattern or similar would be required, or handling setting the cursor. Whilst everyone has an opinion based on their experiences etc... and yours is that you obviously detest the Val(Sign) to point where using one is very bad which is cool, mine include: Everything has a place, I am not saying I use technique all throughout my code (in fact I rarely use it) - but it does have a use case, saying originally to never using it, IMHO is not that helpful. You need to walk before you crawl - if you don't understand firing off an event, or basic design patterns, I am sure the use of a Val(Sign) property will not make or break your code. And while it is definitely less flexible, it may be much, much less complex and get the job done (especially if the software's lifespan is short (test stub or prototyping something), a high quality level is not a requirement, the user is completing an example project (e.g. assignment)... Knowledge will increase through ones own trial and error, backed up an intermediate ability to search for resources and good comprehension skills of those resources (I find that this is a cycle as I get better at one, I get better at the other etc...). All in all nice posts, but I think bashing the Val(Sign) is a little harsh. My 2 cents

This code has been updated and added to the LAVA-CR. It can be downloaded here. Cheers JG

This code has been updated from this post and added LAVA-CR.

lol First I totally agree with you that this can be bad as in using globals is bad. But everything has a place, and everyone is at different programming levels and knowledge levels, so I think depending on a per use case it needs this needs to be judged. So taking the topic into perspective: You think someone who has openly stated they are new to LabVIEW is going write beautiful code, first time, off the bat? Understanding dynamic events is hardly a basic level subject. Especially given they are unfamiliar with design patterns (also stated). I am by no means having a go here, just establishing an estimated LabVIEW experience level based on the facts posted. So if someone starting out has a basic application, and the use of Val(Sign) property works and gets the job done, but they learn stuff along the way - is that such a bad thing? I never stated to abuse it like a red headed step child, I stated a method that could achieve the result outlined in the original post. Additionally I am of the opinion that it is not detrimental that somebody has knowledge of how the Value Signaling works. If they do not know it exists, or do not understand how it works, then how are they to know why its bad? Programming is a journey (well at least for me), it is about finding stuff out, trying different things (can always skin a cat different ways). So telling someone to disregard the Val(Sign) property means discouragement from learning something and from trying it out for themselves. This in my opinion, is counter-productive to that journey. Bad, bad, bad Norm.

Name: Rename LVOOP Labels Submitter: jgcode Submitted: 28 Nov 2009 File Updated: 30 Jan 2012 Category: LabVIEW Tools Network Certified LabVIEW Version: 2009 License Type: BSD (Most common) This package is Open Source This package is a LAVA distribution - visit 'http://bit.ly/team_lava' to learn more about Team LAVA Visit 'http://bit.ly/rename_lvoop_labels' for this package's support forum This package contains a Plugin which renames a Class Member VI's Top Left and Top Right Connector Pane inputs to 'Class Name In' for control and 'Class Name Out' for indicator. Qualified Namespacing is ignored (i.e. parent Libraries). All VI control terminal labels are aligned left and indicator terminal labels right. Addtionally the Class icon will be refreshed. Use this Plugin e.g. after you have renamed a Class and you want to update it's labels or when you have cloned (Save As) a Class This plugin was designed to be use with 'LVOOP templates' therefore, the following Connector Panes are supported: 4815 - 4x2x2x4 4833 - 5x3x3x5 4834 - 6x4x4x6 4835 - 8x6x6x8 Restart LabVIEW to refresh Menus after installation Use the Tool Menu or NI Example Finder to view examples of how this tool works. Tools Menu: Plugins can be found under Tools>>LAVA>>Rename LVOOP Labels 'Rename Selected VI Only' - operates only on the selected VI 'Rename All VIs In Class' - operates on all VIs in the selected VI's Class 'Open Example' - demonstrates features of this tool Quick Drop (QD): Press Ctrl + Space to launch QD The default hotkey for this plugin is 'Z' 'Ctrl + Z' - operates only on the selected VI 'Ctrl + Shift + Z' - operates on all VIs in the selected VI's Class Help Menu: Help can be found under Help>>LAVA>>Rename LVOOP Labels Installation Locations (relative to LabVIEW directory): '\vi.lib\addons\_LAVA\rename_lvoop_labels' - main code '\project\LAVA\rename_lvoop_labels' - tools menu plugin code '\resource\dialog\QuickDrop\plugins' - quick drop plugin code (z.vi) '\help\LAVA\rename_lvoop_labels' - help menu plugin code '\examples\LAVA\rename_lvoop_labels' - example code '\examples\exbins' - .bin3 file Click here to download this file

The example attached can fire an event for Control 1 using the control or another event, which makes use of the Value Signaling property node. The counter will increment in the Control 1 Value Change Event case. Pressing either Control 1 or Progammactically Fire Control 1 Event will increment it. So anywhere in your code you can write to this property node to create a Control 1 Value Change Event. It is just another way to programmatically fire an event. It is the same as doing it registering an User Event (as jcarmody has posted) albeit most likely a little easier to start with, but not as flexible. Value Signaling.vi [LabVIEW 8.2]

Dude, thats nasty! I had the flu (swine?) bad this winter too, it sucks. Wishing you a speedy recovery from the swine flu - hope you feel better soon!

Programmatically writing to a control, local variable, global variable, datasocket or a value property will not cause the Event Structure to fire a Value Change event. One way to do this programmatically is to use the Value Change (Signalling) property node of a control. This will cause a Value Change event to fire in the Event Structure that has registered for this event. If you search for design patterns you will get a lot of hits e.g. LAVA WIKI NI NI Darren's Nuggets JKI Design patterns help you solve problems and stops you from having to reinvent the wheel.

I have now added support for when "Include Error Handling Terminals" is unselected and included my preferred default save names e.g. set<DataMemberName> (in camel notation). The VIPC file is now a list so the download is back to being small as well. ********** This was a bit of a code and fix job, as I was exploring scripting and try things out. Everything works nonetheless so I figured it was worth posting. However, I plan on refactoring the code in order to neaten it up for the next release and have a few other ideas too. Anyone got any feedback or suggestions? They would be much appreciated. Cheers JG

Haha got it! Thralled - thats the word I was having trouble remembering

Hi François Nothing sinister here, if the LabVIEW data member VI (dynamic or static) has its class input wired to it's class output then you will not see a coercion. Otherwise you will see a coercion. AQ made a post about this relationship recently in explaining some checking that occurs - I can't find the link yet - sorry! . But you may find it an interesting read!

Ah, a picture speaks a thousand words - I understand now thanks. Do you do this?

Darren has created a new group on ni.com for Quick Drop Euthusiasts. Check it out, as he is discussing possible 2010 release ideas. Cheers

Thanks Jim I used to be an enum/variant guy myself (I was exposed to my first LV State Machine in an NI course). And I was reluctant to use strings. I started using the JKI State Machine when it came out and after a while, I couldn't stop using it. When I combined this with encapsulation (in particular LVOOP), I started to make some really neat code (IMO ) that did, as you say, cut down the number of unnecessary states (and logic) due to encapsulation. Is there an agreed maximum number of states before readability becomes a factor? I find I can still easily fill the State drop down menu list out of the screen for medium-large UI's - there is already quite a few states in the template to start with. For dialog boxes, and small UI's this is not such a problem, but for my main UI it does become harder to read, I find, by scrolling. I usually find states map to user functions (play, stop, pause) so that is ok, but I can have a lot of "UI" states. This are normally quite basic e.g. Set A, Get A, Set B, Get B etc.. Maybe I need to encapuslate the UI more with X-controls, but I don't know if that's the best work-time tradeoff if the UI is not going to be reusable? Do other people find encapsulating the UI using X-controls is worth the effort? Another way is to push out UI commands via a queue to another loop. Benefits of this is that updates to the UI can be asynchronous and the UI can be abstracted from the main engine VI (if user inputs are also accounted for) but this limits sharing the statefullness of the original state machine which, IMO is one of the key benefits I get e.g. I can use more LVOOP and not worry about sharing data byRef with another loop (this makes me very happy). [Thinking out loud] Maybe I have too many UI states because updates are not asynchronous... removing the UI states would serve to reduce the length of the State drop down menu which in turn may help with my readability hmmm..... Thanks Paul, I thought it would be quite common for developers to use some type of queued messaging for a UI architecture? If not, what design pattern do you prefer? Please post (I love discussions on design patterns). Thanks Michael I too, have met some people that swear by string based state machines as that can parse *anything* from a string (sub states, arguments, data etc..). Cheers for the heads up on your experiences. I have found, as mentioned above, that encapsulation has led to neater state machines. When you talk about using more subVIs do you mean you would use encapsulated State Machines (in subVIs) over Sub States? Positives I can think of is that they could be unit tested (so they are easier to debug) and make the main UI more readable. I do try to use a Integration subVIs so I never use multiple states just because I have exceeded the BD size available within a state. Or do you mean something else? Thanks Jim Your first point is the the first thing that came to mind that I was worried about - readability. Although the design has parts that are already nested: (I though I few more would be ok ) - Idle (event) case is nested, but it does not lend it self to readability issue (at the end of the day it has to be there, but its readable). - And I usually have to nest my menu handling (from the RTM) in the event structure as well. If it's complex though, that normally goes in a subVI though to help with readability. And with your second, yes you would have to cut and paste instead of a nice "Rearrange Cases..." While this may be avoided by good initial design, this would crop up again in maintenance - so you would loose some a lot of flexibility there as well. Thanks Vugie That is a great idea also. Do you do this? I was trying to keep all the original functionality of the JKI State Machine so if need I could still pass arguments as well as Sub States so the syntax is the same. I was trying cause less confusion by not deviating too much from the original design. Thanks Ton Are you able to elaborate? I do not think I am following (sorry!). The owner is the "---------- UI ----------" case Any Group of states registered as a Sub State will get sent here. ---------- Summary ---------- Summary: A poll would be nice to see who likes using Sub States and who doesn't. Summary: Thanks to everyone who's posted so far for the great feedback!! Summary: Please continue to post your feedback it has been very, very much appreciated. Summary: I like to keep trying new things, so I will keep busy experimenting with this. Cheers JG

LabVIEW has great HELP documentation on LVOOP that ships with it. That would be my first stop for electronic info. Along with the white papers in NI's KB. Just do a search on their website.

Howdy, I wanted to post what I have been working on lately in order to get some feedback. There has been some discussion about managing a large number of states in a state machine neatly. Jim Carmody came up with this brilliant solution. This particular implementation is also based on the JKI State Machine mainly due to the fact I now seem to be using it all the time (I have become addicted). I have been working on modifying the architecture of the state machine to accommodate a large number of states by introducing sub states. I also want to do it in such a way I can upgrade existing code quickly and easily. If a group of states (e.g. UI) gets too large, I will move all UI states to their own case (owned by the separator case). This seems to be neater and easy to read then having to scroll the state drop down menu when the number of states starts getting large. Plus the states are all grouped, so it is quite natural for them to sit together (IMO) in an owner case. The JKI Syntax lends itself really nicely to this. So I wrote a parser that is a wrapper for the JKI Parse State Queue.vi. If no sub states are configured with the parser, then the VI behaves exactly the same as the JKI parser. With respect to the state machine, everything else stays the same, so no code gets changed as such, just its location really. I guess a disadvantage to this is readability from the point of view that I have now have increased the nesting of case structures. But so far adding depth the the state drop down menu on the block diagram works fine. I am sure other people have done this before, anyone care to discuss the advantages and disadvantages to such a design? Cheers JG JKI State Machine with Sub States (LV8.2).zip [LabVIEW 8.2]