WMassey

The NI application builder can save a project's build settings to a ".bld" file. Has anyone here managed to figure out the format of the data contained in that file? Thanks!

Michael, Have you tried updating a version 7.1 VI that contained this diagram reference to see if it makes it through the update intact?

Thank You! I had missed the true worth of that button. I guess the one time I had tried it was with a connector pane that did not have any optional terminals in which case it did not do anything other than change the appearance of the button itself. I guess this "wish" really needs to instead go into the "tips" thread.

This is a minor annoyance but I'm reminded of it every time I use the context help to look at a connector pane that has optional terminals. I do wish their name showed up in some manner rather than being entirely hidden.

The last time I remember being at an NI presentation here at LLNL the presentation team asked what new features we'd like to see in LabVIEW and wire labels was one I mentioned so perhaps if they hear it from enough places it may come to be. One other labeling area that could stand some "fixing" is if you choose to show the label of a subVI you will find that it is the VI's filename and that there is no ability to modify the label to say anything else. I would like to be able to change the text to say or mean anything I choose to use.

Yes it is easy and equally easy to figure out if you make the effort to do so... Help --> Find Examples... --> (tab) Search --> (keyword) serial --> (double click) serial --> "Basic Serial Write and Read.vi" Just eliminate the portion that does the reading and add a "Format into string" node to generate the numeric string to send. QED

I don't know if it will work for you with the original code but I was able to get the breakpoint to go away when I right-clicked the flat sequence and then selected "replace with stacked sequence". It remained gone after converting it back to a flat sequence the same way.

And, for those that don't know about color boxes on the block diagram, you create a color box on the Front Panel and then drag it from there onto the Block Diagram. Delete it from the front panel and use the copy on the block diagram. Click on it with the "finger" to change colors..

Each time the VI restarts (loops) it will see the "1.5" value sitting in the control, it will perform all its calcs and come up with the same answer as before and execute case #4 and give you the same error message. If that includes rerunning the FOR loop then it will rerun and blink the LED 6 times. When everything finishes it will all start over and do it all again. I edited the message above to show one way to do it while retaining the use of the continuous run button. Most of the people who have been using Labview for anytime would not use that button for anything other than quick & dirty testing however. We'd put it all into a WHILE loop . I'll throw something together to show you and attach it to this message in a moment. OK, try the attached revised VI. Don't use the continuous run button when running it. Download File:post-2800-1128970320.zip

Then you are calling the FOR loop multiple times. You need to setup the rest of the VI so it will only execute the loop once, each time your value is entered. Is that the part you are having trouble with? You cannot use the "continuous run" button and expect the FOR loop to run only once.Do you want to detect when your "n" value changes (I assume that is what you mean when you say "decimal number" changes), do your calcs, flash your lights, and then go back to waiting for another change? Actually you can use the continuous run button, it's just not how many of us would do it. Put an event structure around everything on your block diagram. Setup the event to "Fire" when the value of N changes. Then try your continuous run button.

I agree that this is the quick simple fix. You also have the option of adding the MSN Toolbar if you want tabbed browsing within Microsoft's Internet Explorer.

See if this will do what you are asking: Also note I have shown you an alternate way to the one you used to get the NAN value.

Your's was not the only posting that has been password protected and accompanied by the "too messy" defense, whether real or in jest. Here's the one that I was remembering at the time and I believe that I have seen more. After all, it is a very convenient (quick to type, without a lot of explanation) excuse that is easy for most of us to understand (who wants to open themselves up to blunt criticism about some aspect of their style when that was not intended to be the reason for the post). I was quite happy to accept your reason and even happier to get the tool you provided. Thank you for it. And thank you for now posting the unprotected version. I'm sure I will learn from it.

Well, it is setup to remove duplicate references. (You only need to modify the 1st instance of a Call Library function node that you find.) After all, you cannot have one instance of a node setup to be reentrant and another setup to non-reentrant. Again I think I took it too far for you.

What you posted and what I posted are slightly different in that yours returns all objects found and mine just returns one reference to each of the Call Library Function Nodes found which is what I thought you said you wanted in your original post. I guess I took it too far. Before I posted it I did run mine against a VI that had several Call Library function nodes in it and it did indeed pick them all out.

Woops! I missed the obvious. Attached is a VI that may come close to what you need however. Download File:post-2800-1128613768.zip

Easy enough to find them: I'm not too sure how easy it'll be to make them reentrant (have not looked at it, even for a moment).

Gee, if I had know that this was a graded assignment I would have put more effort into it. Michael were you possibly a school teacher in an earlier life? You even break out a red "pencil" when you mark up my block diagrams. I agree and I normally use delimited strings as well for anything more than just a couple of cases. I had purposely stayed away from them in the code I posted because I wanted it to be as basic as possible with as few additional subVIs as possible. In retrospect perhaps that was the wrong thing to do, especially since there was one subVI already included anyway. When I say I use delimited strings I mean in the constants that determine the states to follow. That delimited string is immediately turned back into an array of strings and it is the array that circulates through the shift registers. That allows me to still use array constants and array element concatenation if I find it more convenient and it keeps the next-state-stripper very simple since it is just the built-in delete-from-array function. Is this what you do or do you circulate the delimited string through the shift registers? How about a representative sample of your code? One ability that I found convenient to build into the subVI that does the conversion from the delimited string to an array of strings is the recognition of a comment character. It's setup to default to a semicolon. It allows me easily comment out entire lines in the string constants. It would even allow for me to add trailing comments on each line if that were useful. I usually go out of my way to avoid defaults if at all possible but this is actually a very reasonable suggestion. In keeping with this education theme I'll give you a gold star for it. Since my last post I have been busy with my Select-A-Case VI. Both using it (real work has still got to be done!) and improving it. It now will work with multiple cases across multiple VIs. It has also gotten smarter about remembering what has been selected. I found that I was still spending more time than I wanted to looking down a sorted list of cases trying to remember the name and pick out the case I was looking to find. To make this easier I added a string-search function that allows me to quickly pull up a subset of the cases to select from. I also found that I wanted better control of what was in the History array to allow me to flip back and forth between a subset of cases quickly. To make this easier I added several options that control how cases get added to the History array as well an option to edit the array. And finally I added the ability to move the window containing the block diagram with the currently referenced case structure to the front of the pile of windows that always seem to be open when I'm working. It's all a bit more complex now and there are now several subVIs included, including a few from the LVWUtil32.llb for those people who don't have that library yet. I won't guarantee that it is 100% bullet-proof but so far it has been working fairly well. Download File:post-2800-1128537743.zip

If you have people throwing stuff back in your face then perhaps you are working with the wrong group of people. I personally believe that the event structure is still a work in progress and NI could do a few things to improve it. As you may be aware it takes special effort with it to capture only the final data change event of a control like a slider or knob. Another area where I think it could be improved is if it were possible to specify the type of data change event it should react to. In the case of a Boolean it will react to either False --> True or True --> False. It would be nice to be able to specify just one or the other or both. (For numeric controls it would be nice for it to differentiate between increasing or decreasing values) For most of what I code I only want it to respond to False --> True events which is why I include the case structures. I have tried to contrive an example and have attached it. If the reasoning contained there-in still doesn't satisfy you then just mark it down to what I said earlier, a difference in style. It takes all kinds you know and I'm undoubtedly one of them. You are more than welcome to improve, modify or entirely rewrite a better version of the Select-a-Case VI that I had posted and then repost it and I'm sure we all would benefit from your efforts. Just to make it easy on you I have restructured the VI in the form you like and have attached it. While it is somewhat smaller and the data sources & sinks may be somewhat easier to follow, IMHO it's not a great deal better, just a different way of doing it. I also feel that it has a slightly sloppier user interface since it is possible to start it running with any or all of the various buttons depressed and by releasing any button while it is running the action associated with the button will occur while the normal user expectation is that the action will only occur when the button is pressed. Going forward, if you think it would save the consternation for you and everyone else I could password protect the block diagram of anything I thought might be of value to others and use the time honored excuse others have used that the "code was just too messy to let others see." Would that be better? Download File:post-2800-1128213215.vi Download File:post-2800-1128248648.zip

Sometimes on more complicated systems I do bundle lots of shift register elements up into a cluster and pass that around but I have read at least one critique (NI forums) of that style as well (no reason given) and I never have been sure if there was a performance penalty with bundling & unbundling the elements. I must admit it can be easier to follow the logic with bundle/unbundle by name rather than labels sitting on top of wires. As far as real estate, I'd argue that the way I did it takes up more vertical real estate but what you suggest can take up more horizontal real estate so which you chose in that respect depends on what you've got to spend. And, while it is a small thing, it can also be easier to probe individual wires than cluster wires. I'd love to see a discussion on the pro's & cons of this. It's something I've wondered about! As far as the boolean feeding the case structures inside the event structure, I guess it's just something I have gotten into the habit of doing based on past experience. Over time I've tried doing this many ways and the way I have done it here gives me the highest level of assurance under all normal and off-normal conditions that the action will only be triggered when the button goes DOWN and the button will always be found in an UP state when the user expects it to be up.

Attached is an update to the Select-A-Case VI that I had posted a few days ago. While using it, it occurred to me that it would be really nice if I could easily jump back & forth between several cases while working with the other VI's case structure without having to continually relocate them in the (in my situation, 78-item) list. To that end I have added a couple of "browse" buttons that let me jump back & forth among the cases I have chosen to examine. (I also eliminated the unused shift registers too Norman) Download File:post-2800-1128108046.zip

If you have not discovered OpenG then you really need to get over there and take the time to figure out how to download and install the libraries found there. It all starts with "OpenG Commander"... :thumbup: But, with that said, it can be a bit imposing the first time you download/install it so I've attached a bit of one of the libraries to this message and it contains enough to do what you want to do. It'll open/read/display an image file. I've even tossed in some color lookup table data (in the form of a VI) so you can truely force the display to be gray (or yarg which is gray inverted). Download File:post-2800-1127945724.zip

I recently got it and it is a slick tool. But before I go and rework all my state machine templates I want to see how the scripting stuff is impacted with the release of v8 of LabVIEW.

While playing around with the scripting stuff I noticed a "FP.OSWindow" property that I had not seen before. I suspect it appeared once I added one or the other of these lines to my LabVIEW.INI file: SuperPrivateScriptingFeatureVisible=True SuperSecretPrivateSpecialStuff=True The context help gave me hope that it would provide something that could be turned into a refnum for the WinXP window so I tried it out and it works! The attached VI (LV v7.1.1) will take a VI Name (not a Window name) and return the refnum to the window if it is open. Download File:post-2800-1127861661.vi

Is there any way around causing this error: Error 1060 occurred at Property Node (arg 1) in Shift Label Position Test.vi LabVIEW: Object cannot contain(own) the specified object. when trying to move a control label on the block diagram of a VI which is in edit mode? Download File:post-2800-1127849042.vi