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!

I couldn't find the diagram reference property. Has it been moved... or removed?

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?

I may be missing something, but doesn't the first button at the bottom-left corner of the context-help window show optional terminals?

-Khalid

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.

Just need to send a 10 digit's string to the RS-232 port.

No handshake ore error detection.

No need to read from the port, just need to send some decimal numbers to a microprocessor through the RS-232 port.

I'm know this is easy, but I cant figure it out..

Kalle

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

ok,the attachment is the strange BP vi.i delete the non-relative parts.

i hope that's not a bug. good luck.

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.

It did work! But I don't know how to set the colormap of the Intensity Graph. I tried to find the corresponding property node but failed.

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

Ok lets say that if I put 1.5 into the "n" field the case structure that I have in the vi will go to 4 there isn't a way that from within that case theres a LED that will blink 6 times and stop while running continously?

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

I've been able to get that far but it keeps blinking. I need it to stop blinking at the 6th blink.

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.

You could use Mozilla Firefox for this. With tabbed browsing, you can open a complete folder of links in different tabs at once.

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.

I have this factorial vi all set up but now I need to add an LED that will blink for only 6 times when a decimal number is inputted. Any help will be greatly appreciated.

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.

Ouch! If you were referring to my post here, please re-read the subsequent discussion at the time and note that I was only joking.

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.

I investigated a bit more, there are strange things in your VI; if the vi I'm gving in parameter is not opened, it finds nothing. If it is opened, it finds 2 Call Library Function Nodes over 6. I think it is because the recursion is not remembering every objects found in structures.

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.

Thank you! :thumbup:

Unfortunately I couldn't get it to work for my code (it doesn't find anything).

I coded and attached something that works for me, any comments/corrections are welcome

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.

Hi, I'm willing to make numerous Call library function nodes reentrant.

Of course I thougth "scripting!" and started to code a VI that can find a CLFN, and make it reentrant.

But when I tried I realized that since they are everywhere in my VIs, I need a fucntion that can get all objects in a BD, by recursing in the structures, cases, sequences... Has anyone done that, or is there an easy way to do this?

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.

This routine will only work for CBR nodes that are directly on the block diagram. If they are located inside of other structures (like Case or Loop Structures), then they will not show up in the AllObjs[] list. You will need to recursively traverse the hierarchy of objects on the diagram, in order to make sure that you have looked in every location for the CBR functions. I don't have time to create an example; but I'll try to later, unless someone beats me to the punch.

Woops! I missed the obvious.

Attached is a VI that may come close to what you need however.

Download File:post-2800-1128613768.zip

Hi, I'm willing to make numerous Call library function nodes reentrant.

Of course I thougth "scripting!" and started to code a VI that can find a CLFN, and make it reentrant.

But when I tried I realized that since they are everywhere in my VIs, I need a fucntion that can get all objects in a BD, by recursing in the structures, cases, sequences... Has anyone done that, or is there an easy way to do this? :question:

Thanks

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

As far as your revised application using bundle\unbundle by name, I would give it an A.

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.

One reason is the use of array of strings. I used to program using array of strings and evolved over time to using standard strings with linefeed delimiter. I just recently had this discussion with a colleague and asked them to try using delimited strings instead of array of strings. He was reluctant at first but after he tried it, he was totally converted to this new method. Delimited strings allow easier editing of your state sequence lists because you can just double-click in the textbox and start typing. You can also quickly select text copy past etc.

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.

Another item of note in your revised code is the use of wiring a TRUE though every output to your conditional terminal of the while loop. Again, it works but it's a lot easier to just use the "stop if true" option on it. This means you only really have to wire a constant out on the frame that terminates the while loop. In your case it would be the "finished" and "default". All other cases can just use the "use default if unwired" option. This means if you add a new case, you can just ignore this terminal. A Minor thing but it's nice not to worry about those pesky little constants.

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

Well the performance penalty is relative. If you work with a team of developers and others have to dubug and work on your blockade of wires then it suddenly becomes an issue. They throw it back in your face and ask you to redo it. So ya, your performance goes down.

If you have people throwing stuff back in your face then perhaps you are working with the wrong group of people.

Can you explain what an "off-normal" condition is? I still don't follow your argument. Using the mechanical action "latch when released" covers this. I have not (since the event structure came out) seen any condition where I would have to "make sure" the button was going down. I may be missing something here, so please enlighten me. I disagree with any code on a diagram that is superfluous. It just causes the programmer to pause and have to think about what is going on. Slows comprehension of the code. Makes me think, "ok, so why is this like this?"

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

Nice tool!

Some nitpicks on style though. Have you considered the use of bundling all the shift register elements into one cluster and only requiring a single wire to cross through your cases? Those wires take up a lot of real estate and it can be messy to debug.

Another thing. Why do you take the buttons and feed the value into a case structure inside the event frame? This is unnecessary coding. Obviously the button value is true otherwise you wouldn't be in that event case. If you are worried about button staying down then set the mechanical action to "switch when released" Which they should all be set to anyway. I'm not following the purpose of the cases in every event frame.

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

it looks like you need to d/l the tunnel wiring wizard to get rid of all those extra shift registers in the state machine.

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.

The "Get Window RefNum.vi" in the "Windows API Function Utilities" referred to earlier in this thread assumes you are passing it the actual title bar text. And since, to the best of my knowledge, LabVIEW itself provides no means of providing what it actually places in the window title bar, you have to try all the various permutations.

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