hooovahh

Okay this solution would work but sucks if there are no other suggestions. You can make a sub VI with just the property node you want in it. Then using scripting you can copy that function and paste it where you want, then wire it up. I'm really hoping this isn't the only solution by the way. I'm sure someone at LabVIEW R&D could answer if it is possible to do this with scripting.

Okay so attached is some code that probably puts into words what I can't. Unzip and run Get Properties. It would try to get the property of a property node which is in a second VI. This property is the FontBold, but this is not referencing the control, it is now referencing the label of the control. So we return the Unique ID String but this unique string is not a valid one for the current property node, which happens to be for a control reference, not a label reference. I think what you want to do can be done with scripting by adding two property nodes, one for getting the label and one for setting the font bold. I hope this is an oversight on my part and there is a way to do this in one property node but I can't figure out how using scripting. Property Selection Issue.zip

You can, you just need to know what the unique string is. In this case on LabVIEW 2013 SP1 it is 632d809. The way I found this is by getting the property node reference, then using the Invoke node Get Prop Item, with index 0. This gets the reference to the first property item on a property node. Then using a property node I read the "Property" cluster which returns the current selected property item of that property. EDIT: Maybe I need to look into this more it didn't work as expected. Double Edit: So it looks like I can use the property node to get a reference to the Label, but not to a property of that label.

No problem, I figured you of all people would be interested and I was hoping you'd see this. There is plenty of room for improvement but I've been using it without any problems for a while. I sorta feel bad that I didn't share it sooner.

Yeah if you do ever get around to updating it, there has been improvements to the OpenG array functions since this release. I opened the template source and noticed that it does things is a different way than the OpenG does with the latest release. And even the latest OpenG array stuff could use some improvements. Still lots of great things to learn about with these XNodes.

In my opinion the XNode version should be updated every time it is released, assuming there were some changes made to it. If the version of the XNode stays the same then the UpdateState will never be called when opening loading an existing XNode. If the data types changed then as I mentioned some mutation may need to take place and this is done through calling the UpdateState. I handled this in my Circular Buffer XNode as well. I did several tests where I would open a VI that has version 1.0.0 of the XNode, when version 1.0.1 was installed. If you look at the UpdateState you'll see the data mutation, but you'll also see it goes through the re-init process. Otherwise the code behind the XNode would still be version 1.0.0. So my code will replace all the 1.0.0 XNodes with 1.0.1 which has improved algorithms and may have different terminals. Basically updating version numbers, and the UpdateState ability ensures that when I install a new version of the XNode, all of my existing copies of that XNode are updated. Otherwise they will stay the same code as before. XNodes aren't like subVIs. If you install a new version of a subVI, when you open a VI that called that it will load it from disk and you'll have the new one. But with an XNode the VI lives in the calling VI, not entirely on the location on disk. Installing a new version of the XNode doesn't automatically replace all the existing versions, but loading the UpdateState can cause that to happen.

Yeah lets see, there also wires going backwards, and error terminals being in a nonstandard location on the connector pane. there's also unnecessary wire bends but whatever. To be honest I've seen much worst vendor drivers.

For loop with a shift register is the right way. But one thing to mention if you didn't know is arrays in the FPGA are of a fixed size. So another (less modular) solution is to have an index array function which pulls out all of your elements, and then wire that to a compound arithmetic. This only works if you know the array size and on the FPGA you will know it at edit time.

Am I missing something? Has there been some underground points program for years? Because as far as I know the re-certify by points program came out less than a year ago. http://www.ni.com/white-paper/9605/en/ As for me I sent an email in December mentioning I have some points. Then in early February I sent another email saying I had some more. I've yet to get any response. but I still have a while before my certification expires.

Yeah you have a good point. In other industries you see some random small company out of nowhere come up with some new way of doing things that ultimately is good for competition.

I've seen several attempts at making a text based language have a graphical interface. Something like "drop blocks down" and "generate text code" which just feels bolted on in my opinion. I haven't look at this product itself so my comment might not be applicable. One thing I feel NI has that is an advantage is many years of doing graphical programming. That's not to say they aren't sometimes stuck in their ways, but I feel like they have tried a bunch of things, and have a decent idea of what things historically worked, and didn't work. And as a result I'd hope that the tools NI develops are more mature because of their history in the graphical programming world. Only time will tell if some up and coming language does some stuff right that NI did wrong in hindsight.

Yeah this problem has been posted on these forums, and the JKI ones. I believe you get a more informative error screen if you try to just install one package, by going to the File >> Open Package File(s). 2014 adds some new features that weren't supported in 2013 so JKI pulled an NI and just don't support opening 2014 packages, in 2013 VIPM.

There is an XNode ability that can define how the data should mutate between versions. When the data behind it doesn't change between versions this is usually just a VI that converts from variant to the same data type but when versions need new data this mutation can mean more work. I'm guessing this UpdateState ability was accidentally not made for this XNode and so LabVIEW doesn't know how to convert the data from the old library to the new one.

Who likes to resurrect 6 year old posts...this guy. So over the years I've updated my LabVIEW Tray Launcher tool. It has very similar functionality as the one mentioned 6 years ago, but with some new features, and a few features that are the same but done better. Launching, killing, and restarting LabVIEW versions should work on all versions, but it is untested with 64 bit versions. It has been tested in 64 bit Windows, with 32 bit LabVIEW. Aborting VIs should work on all versions 2011 a newer. Older versions can be supported with more effort. Aborting VIs don't abort asynchronous clones. LabVIEW Run-time, or development 2011, 2012, 2013, or 2014 needs to be work. Others can be supported with more effort. By default opening VIs, and CTL files is done through this program and not LabVIEW. This allows these files to be opened in the right version. Other file types have varying level of support, but should work if they are added to the settings. If multiple versions of LabVIEW can open a file a dialog will show the available options. If only one version of LabVIEW can open the file it will open it with that version. If multiple versions of LabVIEW can open a file, but one is open already that can open it, it will open it with that version. If Shift is held when opening the file, a prompt will always be shown giving the option of what version to open it with. When opening the file VI Server is used, so unique server ports are needed between LabVIEW versions. If VIPM is configured and works, so should this. Pressing CTRL at the LabVIEW selection screen will open it in the default version of LabVIEW, or the oldest if the default isn't an option. This is all hosted on my personal site for now. It is a little large for a forum post, and the Code Repository blocks it, probably because it contains EXEs. So for now it will live on my site here.

If it were me, I'd go with the solution that can work today, using two channels to read and adding the currents as suggested. I like these quick and dirty solutions some times. But yeah the right way would be to buy the right hardware for the task.

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.