From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
LabVIEW
Micro-Nuggets !!! ~~~~ Post 'em if you got 'em
@tst wrote:
@Steve Chandler wrote:
Now we just need a mega-nugget on building this inth the RCF in order to drop the constants on the BD.
If you want to drop VI server class constants, you can use the class browser (Ctrl+Shift+B), which does essentially the same thing, but also allows you to drag constants to the diagram. Personally, I don't use it, probably because it's too much of a pain. If you vote for this idea, that should simplify this process somewhat - http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-Intellisense-support-to-the-property-node/idi-p/15.... The idea mentions the constant near the end.
tst,
Just FYI, Steve was the first person to vote for the Idea back in April. I voted one day after he did. 
New with LabVIEW 2011, the Scripting Property Node UID (Unique Identifier) works on decorations (as well as everyting else), making it an ideal method to locate specific decorations on your panel and perform actions on them. Furthermore, since each decoration will have a unique identifier, you can distinguish between decorations that are physically identical.
Here's what the node looks like in use:
A LabVIEW 2011 VI is attached for your perusal. You must have SCRIPTING ENABLED. And you can Read about the UID node here.
@Darin.K wrote:
Even with the promotion from private to public I am not yet completely sold on the UID property. It is linked to the specific VI so not quite as nimble as I would hope (not the equivalent of say a GUID). Personally I am a fan of tagging objects such as decorations and I have written tools to grab references based on tags as it tends to be more robust than getting them by label. Plus I can use additional tags to provide hints to the object type to avoid some of the usual To More Specific Class until there is no error machinations. If you specify that the tags are persistent than they will be transferred via copy and paste as well.
While I haven't had any issues with the nimbleness of UID, I do agree that tags are a great way to distinguish items and get references later. There are two benefits to using Tags in this manner
1) If you change the Label of an item, the reference will still be valid.
2) You will likely have many less Tagged items than you have items with Labels, so programmatically getting the reference of a tagged item should take only a few iterations (traversals), as opposed to perhaps many hundred* if doing it by Label.
*One of the few times I use a Conditional terminal in a for loop is getting references - I quit the For Loop when I've found the reference I need.
And let me add that using tags is "fun", and easier than ever. They have recently been exposed as an Invoke Node; whereas before, they were wrapped in VI's located in the user lib, and not documented.
Thanks Darin.K.
As an expansion to my thoughts on the UID Property Node and its use on Decorations, I have attached a VI that performs animation. Before the UID Property Node, this would have been sketchy at best.
Granted, this animation can be done with boolean indicators, but it would take a lot of them. It could be done with picture controls, but I think it would be more work coming up with all the pictures required.
While there is a good deal of code, it's not "difficult", just a bit tedious. I have made the code tedious-er than it needs to be to explicitly show what's going on - and there's no Sub-VIs for the same reason. I'm also not closing references or doing error checking. You should.
Below is a GIF of some of the animation. Attached is the VI.
I have always looked for a better way to stop Producer-Consumer loops. I never liked the kill the Queue to stop the Consumer loop so I create the following.
The Producer stops the Consumer loop in the Exit State and the consumer fires an exit user event to stop the Producer loop.
than concatenating the string in the For Loop and using a shift register for the concatenation.
I profiled this with the attached VI and I interested in any confirmation - although I do not expect any PC specific issues with the code.
I see quite often the usage of the "inside loop concatenation" and now asked myself if the additional wiring effort ends up in faster code. It seems to me that I can save some wiring from now on and also save some execution time.
Has there already been a post on that issue which I did not find? Please let me know.
@Guenter Mueller wrote:
I see quite often the usage of the "inside loop concatenation" and now asked myself if the additional wiring effort ends up in faster code. It seems to me that I can save some wiring from now on and also save some execution time.
Well, You can go about 3x faster than your fast solution by autoindexing the numeric and then format and concatenate later (Bottom image).
(With the disadvantage that you can't really control any useful delimiters, but in this case you would use array to spreadsheet string instead anyway, which is also faster than your solution. Not shown).
Even the slow concatenate solution you presented is a bit convoluted. Format into string has concatenation built_in! So a cleaner solution is possible (top in image). Not super fast, but good enough for small arrays.
