hooovahh

They cannot be in the same DAQmx task. You will have two separate tasks, one for each chassis. Putting the tasks together means you are telling the DAQmx drivers to have these two signals share the same timing which can't be done without synchronization. But I could be wrong if the task is setup to be single point, in that case the DAQ drivers may recognize it is a software timed read and it may allow it.

Uh...why would they not be in the same EXE? Is that a requirement? It does make my statement about a few milliseconds potentially not true.

The hardware discussed is cDAQ hardware, not cRIO.

If you go with two single slot chassis you will lose the synchronization between them. If you are okay with that then you should be fine. Reading two single point measurements between hardware is no problem. But I don't think you'll be able to put them in the same task because the tasks will try to synchronize the hardware. If this is as seldom as you say then yeah just take two single point readings whenever you want. They won't be "at the same time" because they will be software controlled meaning you probably have at most a few milliseconds between each reading.

Thanks Darren for closing the loop on this. Without someone from NI saying "This can't be done as far as I know" we all just spin our wheels and think maybe we missed something and the feature is there buried somewhere, like with a dot notation.

Yeah I go back and forth. I'll use a VM for each version of LabVIEW, and then realize this works well on a per-project basis, but when working on code say from the internet, I'd like a single machine with many versions installed. Lately I've gone back to the many versions, in one OS technique. It really depends on your work flow. Today all of my testers have a full development environment that is linked to my user name. So I log in and I have the only version of needed for that project for that test with all the toolkits, drivers, and VIPM stuff. So if I need to make changes to software it is easiest to just go to that tester make changes and push it to SCC. But if I were in a place where I was making project builds from my work machine, then I could see problems with upgrading something like DAQmx for 2014, and being forced to upgrade DAQmx for 2011 projects too.

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