hooovahh

Here's a fun little video done by LabVIEW R&D Stephen (now Loftus) Mercer, AKA AQ, from NI Week a few years ago. At points he talks about what the compiler will do and he admits there are times that he couldn't predict what it would do, and needed more research to find out. https://www.youtube.com/watch?v=YnjeZxhAolY

This can be setup in your user's notifications. Go to your profile and click Edit My Profile, then on the left there is Notification Options. Maybe some of these should be turned on by default since it seems most other forums work this way.

Yeah for me it is my morning routine to check LAVA and the NI forums. I'll spend a few minutes seeing if there are people I can help, and similarly if I can solve some peoples problems, or make some demo code of what the poster was thinking of it brightens my day a bit.

I've discovered that there is some kind of issue with this XControl. I don't know what it is, but running it for a while will cause LabVIEW to take a longer than usual time to close, indicating that there is likely references that go unclosed. Attached is a VI that I think demonstrates this issue which I've seen in 2011 SP1, 2012 SP1, 2013 SP1, and 2014. Basically I've seen that updating the tree XControl many times will cause LabVIEW to take a long time to close. I use this XControl as a probe actor looking at various variant data. This usually runs in the background updating a circular buffer as it runs. The windows is only ever seen during debug but I had the control get updated throughout the test. After a test was ran over night it took several minutes to close LabVIEW. After some investigation I have isolated down to this XControl. For me the fix is simple, if the UI isn't being shown, don't update the data. It is a debug window and won't be seen often. Still it should probably be looked into for those that do update it often. Variant Tree Close Bug Test.vi

Most voltage DAQ cards state they have a sampling range. Let say they are -10V to 10V. Then they have a rated maximum input voltage say 20V, then sometimes you see a overvoltage protection at say 30V. This current card appears to be different, where it has a normal sampling range of 5ARMS, but a maximum sampling current of 14A if it is a single sample reading. All other documentation I found doesn't mention current over 14.9A. http://www.ni.com/datasheet/pdf/en/ds-194 Will this mean your card will blow up if 25A is put into it for a microsecond? I can't say. Best case it is fine, worst case it blows up. My guess is it is somewhere in between and it will work fine for a while, but will shorten the life of the card and some day that input will stop working. A better design would be to use some kind of current measuring device, which changes the range of the reading, which you then can scale. Something that maybe has a 0-30A range, and converts that to 0-10V. I know Omega, and Analog Devices make hardware like this, but many other companies do too.

I totally agree that these are basically the two mind-sets between these two methods. And to me this could be seen as like a framework, and in my mind I would rather put more code and effort into making the framework easier to work with, with as few steps for the developer to implement it. Which is a reason I prefer the inline method. It means less work for the user, and more work for the developer...but in this case they are both developers but I think you get what I'm trying to say. Another thing I like is that my XNodes that use the inline method don't have any other dependency packages to make them work. I'm not into duplicating work, but I'd rather not force people to install a package, that they aren't going to use, which will just clutter up the palette more. But on the other hand maybe they will find something valuable there. I still don't think the inline method I show is perfect. There is plenty of room for improvement. Over the weekend I thought of a neat way that I could make a wizard, where you provide the template VI. You can then tell the wizard what terminals should be adaptive, and then it using scripting, creates the XNode for you. This could be a simple way for people to get exposed to the power of XNodes. Of course cautioning them along the way about the experimental technology. As for mixing classes and OO with XNodes. I tried and failed. I didn't try long but when I first was working on them I tried having a class with multiple XNodes in it and editing one would lock all the rest, and made working on any of the files very difficult. I also noticed really long name space names because it would be something like "This is my OO Class::This is my XNode Class::This is my VI.vi". I don't know if a name could ever be too long but I was curious if it could break something eventually. NI has more or less stated XNodes are stables in some use cases, and not tested in others. So I'm guessing the combining of OO and XNodes is one thing that NI may have experimented with, but not tested for, or coded for. At some point your application may crash, and if you are using an XNode you will likely blame it for your problems, because it is the biggest unknown in the application.

I've given this VI to NI to see if they can figure out why it behaves the way it does, and possibly so the next version of LabVIEW has this issue fixed. I'll update this with the CAR if I get one.

I'm confused about this. Were you under the impressing adding this INI key to your application would do something? This is generally used to show hidden development features that NI thinks isn't ready for prime time yet. I'm not aware of it doing anything to an application.

I'm pretty sure this was reported on the NI forums and the easy fix was the LabVIEW band-aid the always copy. I tried in 2014 and it also is broken.

It has issues for sure, but it is my preferred file format for the majority of the test software I write. And NI keeps investing in it. It seems every version of LabVIEW has some new TDMS functions under the advanced palette. Few I actually use but still.

You wouldn't happen to be writing 2D data and performing a transpose before the write? And on version I think 2011 or older? http://forums.ni.com/t5/LabVIEW/WARNING-TDMS-memory-leak-in-LV-2010/td-p/1874575 That was a nasty one that got me all the time. If you can isolate it like that user we can get NI working on it, or testing it on different versions of LabVIEW. What version are you using for this by the way?

Name: Traffic Jam Game Submitter: hooovahh Submitted: 04 Feb 2015 Category: *Uncertified* LabVIEW Version: 2011License Type: BSD (Most common) Has your stressful day at work got you down? Want to take a load off and relax with a game? Why not a LabVIEW game? Here is a game I made a while ago and forgot about. It is called Traffic Jam similar to this, or this one called Rush Hour. The basic goal of the game is to get the red car out of the parking lot, by moving the other cars. Cars can only move in one direction and can't turn. My coding style has improved over the years, but I'm not yet ashamed of the work I did on it. It was fun working with the picture control and generating the UI based on the level files. This game comes with 122 levels. Why 122? Because I forgot to put in the last 18. Feel free to add them yourself by editing the Set text files. This game also keeps track of your high score, so you can try to go back and do it in less moves. Click here to download this file

Ahh okay, lets get to the meat of the XNode. Good job by the way in making the template I think everything is how I would have done it more or less. You'll need to have that cluster be a control. Then wire it to the Variant to Data you have at the end, and make an indicator for it. Both these terminals will be adaptive in the GetTerms function. What this will mean is they will accept any data type as the input, and the output will be changed to whatever is needed, which in this case will be the same as the input. In the AdaptToInputs you can read the type of the input, and if it isn't a cluster, you can choose to then go back to GetTerms, where you can break the wire for that adaptive input. This way it will accept any input, as long as it is a cluster. Several of my XNodes do this like the circular buffer on init when you are defining the type. The type is adaptive accepting anything, but then it checks to make sure the input is a scalar, otherwise it will break the wire. So you are probably familiar with some of the XNode abilities and the descriptions help you understand their purpose but how to use them is up to you. And there are pit falls that can be a problem so I generally stick to a few methods that have worked in the past. When using the GenerateCode ability you basically start with a blank VI. At this point all you'll have is the control terminals on the block diagram that you defined in the GetTerms ability. So one method is to wire up from scratch those terminals to their respective locations, and drop down all the functions you would want to making this VI. For you that would be quite a task. You would basically be writing code, which can make your VI with all the case structures, OpenG functions, for loop, and everything. This can be done sure, but a much easier way is to write the code once in a template, then just plop it down and wire up the terminals through scripting. The method of doing this isn't standard. I started coming up with my own way which more or less works but could be improved. My method will drop down your template as a subVI, wire up terminals to matching control names (so wire "error in" to "error in"), then it will inline that subVI, meaning replace the subVI call, with the actual code from the subVI. This works well enough, except it needs to know what terminals are adaptive because they don't wire up nicely until there is a type defined. But now that I think about it I could probably catch this because the type will be void, and just don't wire any terminals if the type is void. Another issue is if you have any control names that may change it needs to know that too. Like say your subVI has a terminal called "Tests" but your XNode can work with a scalar or array so you may have a terminal called "Tests" or you my just have a terminal called "Test". You'll need to know that you can wire "Test" to the subVI "Tests". This is what the "Custom Connections" input is intended for in the Insert and Wire XNode Template. The other method of using a template I think is not a simple, or as manageable. This is the method seen in the OpenG Array XNodes. It basically works by wrapping the entire template in a sequence structure. Then through scripting set tags on each of the terminals going into and out of the structure, and save that tag data with the subVI template. Then the GenerateCode will copy the sequence structure (and all of its contents) to the new XNode, and wire up the controls to terminals, that have a tag with the name of each terminal. I don't like this method because it means more work for making the template having to set custom tags, when the information should already be there based on the control names. Also you'll need to remember to wrap your template in a structure and have it be identified in some way so you can know what to copy. I talked to AQ a while ago about my method of inlineing and he showed concern but once I mentioned that the regular expression XNode used inlineing he seemed to think it was safe. Oh and one other thing, how did you get your data needed for the GetTerms? Attached is a subVI that you provide the template VI to, and it should generate the data for the terminals. You obviously can make changes like choosing which terminals are adaptive, but it is a starting point. Sorry it is so ugly it did goofy things when I back saved it a few times. Get Terms Data From Template.vi

Fantastic, if it wasn't so long it would be my new signature. And a rare few have been to the architect orgy (CLAO?) that don't hold CLA certification. At the LAVA BBQ last year a door prize that was given away was a invitation to a non CLA to go to the CLA Summit. Not sure who won, but there was even some discussion last minute to not give it away. Now wither that mere mortal could understand the strange spells and voodoo discussed is something different.

I agree, but that information wasn't given until after I asked that question. I meant using something like system exec to run a command line version, of a 64 bit built application. Here was a quick and dirty solution using this method a while ago.

Yeah this is a year old but I just saw the Teensy LC (Low Cost) was just announced for $12. http://www.pjrc.com/teensy/teensyLC.html Similar capabilities as the 3.1. Runs a little slower, has no CAN bus, pins aren't 5V tolerant, less memory and a few other limitations. But other than my CAN gateway project, all the other projects I've done with the 3.1 could have been done with the LC for 40% less cost. It is only a few bucks more than a Trinket but much more capable.

Settle down there partner, you can make all the requests you want, no need to justify that to me. I was just trying to help by giving you an alternate solution until a better one is possible. If this matter is as urgent as you made it sound, I figured you might be interested in some kind of temporary solution, like complicating your build process with command lines, or moving to 32 bit if it is possible. That's what the purpose of that information was.

I feel like more information would be useful. Why is the x64 needed? What is wrong with LabVIEW 32 bit on x64 Windows? And is this a place where a command line 7-zip built for 64 bit could be used?

Okay new version posted with the changes I mentioned earlier so now it supports objects without labels. Sorting still works with objects without labels.

I don't believe is is just an anti-aliasing issue. Your image is going to also need to be an image that is in a vector type format. The only format I know that is supported is WMF. The Image Navigator is part of the DSC toolkit and comes with a bunch of WMF images and allows you to change the color then copy them, then you can replace the buttons with that image. Then these images scale well. Attached is a switch I made by replacing the True and False images with two from the WMF format. Now if there is more NI features to make anti-aliasing better, I don't know. But I do know of the enable secret popups as mentioned by Christina here. https://lavag.org/topic/18469-i-found-some-more-hidden-ini-keys/#entry110810 EnableSecretPopups=True I was hoping that would have the menu might have something else for handling this but it doesn't. WMF Switch.vi

I've wanted for some time now to make an improved version that integrates with LabVIEW better, but I don't know if I'll ever get around to it.

Oh you just had to ask didn't you. Well I was going to reply without trying it cause I assumed it would work...turns out it doesn't. It doesn't take much to make it work. You have to modify the Search Filter 1D Array of String to return the item as always matching, if the search string is empty. I'll look into adding this to the next version. EDIT: Another advantage of this is then the label input can be optional.

Name: Find References XNode Submitter: hooovahh Submitted: 03 Feb 2015 Category: XNodes LabVIEW Version: 2012License Type: BSD (Most common) Description This zip contains an XNode which makes finding references to objects easier. The core of the attached XNode is a modified version of the Find References by Label VI that can be found in the vi.lib. This VI will return the first match of a control that has the label provided. This modified version has the ability to find all references that match a label given a string which the label contains, starts with, ends with, or it can be an exact string. So for instance it can find all objects that start with "Numeric". This XNode still has the ability to return a single scalar reference like the original, which can be done by right clicking the XNode and un-selecting "Find All References". By default it returns an array of references found. If multiple references are chosen, the order of those references can be changed. An enum is used to change the sort method from String Sort, Numeric Sort, Sort from Left to Right, Sort from Top to Bottom, or Sort from Top to Bottom then Left to Right. This is most useful when you have controls on a front panel arranged in a grid. Another improvement over the native function, is the output reference type is changed to a selected class. Right click the XNode and go to Select VI Server Class to select an object type. There is also a browse button which brings up a dialog where the list can be alphabetized, and a simple string can help find the type desired. Other features of the native function are still provided like using caption labels on controls, and searching the front panel, block diagram, or other owning reference types. Demonstration Below is a video showing the basic operation of the XNode. It demonstrates how to find control references, and how the sort, and search features work. It then shows that the same technique can be used to find any object type on the block diagram too. http://screencast.com/t/gFBen503rg XNode Disclaimer NI does not provide support XNode development. It is an experimental technology and neither I, nor NI can be held accountable for unexpected operation. For an introduction to XNodes read Adam Rofer's "XNodes - A Crash Course" presentation (http://lavag.org/files/file/56-xnodes-a-crash-course-powerpoint). Dependencies OpenG Error Library-4.2.0.23 OpenG Array Library-4.1.1.14 OpenG String Library-4.1.0.12 OpenG LabVIEW Data Library-4.2.0.21 Click here to download this file