hooovahh

Please don't generalize. The testers I use, are I think the feeling around here, is test systems can fall apart for any number of seemingly insignificant reasons. And if my tester blue screens after a Windows update, I'm going to blame the update. And if my program was working fine on F1 patch and then it auto updates to an F2 patch and all of the sudden things stop working, my boss and customer aren't going to give a hoot what cause the problem they just want it to not happen again. Having as much control over that environment as possible helps me ensure I can do my job. I see automatic Windows updates, automatic driver updates, automatic patches, anti-virus, and firewall programs and ways of me loosing control over my environment.

There are several discussions on LAVA about what references should and shouldn't be closed. The statement that I think holds true about 90% of the time is "If I did something to open a reference in my code, then I need to close that reference". Did I use OpenVI reference? Then I need to close it. Did I use a reference tied to a control? Or the ThisVI reference? Then I don't need to. It starts to get a little confusing with things like an invoke node that can give you a reference to an already open thing. But throwing close references around shouldn't cause any problems. LabVIEW will try to close that reference, and realize it can't for some reason, like the VI that owns a control is still in memory and it won't do anything. I've often wrote a simple VI that is just a while loop that runs forever, which will perform some kind of operation that I think might be making new references, over and over without closing. Then I'll look at the memory usage in the Task Manager. If it doesn't go up, then that reference doesn't need to be closed, if it does then I need to close it.

This isn't too difficult. Once you have the read data as an array, go into an auto indexing for loop and process each row one at a time. Then concatenate the sum to the end, and rebuild your 2D array before writing it again. Attach the code you've tried.

Thanks for this, I always assumed it was NI just putting resources into making something that users didn't want. Now I actually know it is the users fault for asking for something that they shouldn't need.

Are you talking about the NI Service Updater thing? Yeah I have never used that to update any PC, and never will. I have a hard time trying to convince it to stop bothering me. I don't upgrade software, drivers, operating systems or anything in the PC ecosystem unless there is a good reason. It just adds new risk changing the environment from what you've been using. So unless you are in an academic environment, or just playing around and not making production level applications, why would I ever want you updating a thing?

So the app.allcontext property node is a private method. It is something NI uses, but doesn't fully document, doesn't support, and I'm sure they'd prefer if no one other than NI used it due to it's possible non-completeness. You see if NI is playing around with some new property nodes that are private, they can change the behavior between LabVIEW versions without needing to update the public, or worry about backwards compatibility. Because they should be the only ones using it. But if us pee-ons start using these functions, and then they change how they work between versions, now all the sudden users of LabVIEW complain to NI about how some obscure private method broke their production code. That being said many private methods have useful functions, that appear more or less stable. Over the years NI has tried opening up more private functions, to be public and to that I thank them. But I'm not sure this function will be made public any time soon. With it you can screw around with the inner workings of LabVIEW. But if you are the adventurous type, you can enable these private methods. Here is a thread where I made a tool for enabling and disabling these methods. https://lavag.org/topic/16612-enabledisable-private-methods/ But please be aware that code that uses private methods can be dangerous, can change functionality at any time, is undocumented, and can break things. You also won't get the support you might want from NI.

I quite like SVN. Yeah I know there are times when it has problems and you need to do some manual fixing, but those are generally times when I screwed up. So I just try to not do what I just did again. The problem comes when every person using SVN needs to learn those lessons one at a time. You can say "Don't create orphan locks" but until you learn it and fight to fix some SVN screw up you won't remember it. I could probably get used to some other SCC but it does what I need.

Some have asked for the Variant Repository VIs to be available as non-XNodes. So I wrote some scripting code to make polymorphic instances, edit VI icons, and make the polymorphic VIs. But what I hope this illustrates is just how useful XNodes are. The Non-XNodes version is 252 VIs and one control. That's a lot of VIs to have to load into memory when using these polymorphic instances. That's 60 normal VIs inside each of the 4 polymorphic VIs. And it doesn't even support all of the features the XNode counter parts do. From a reusability stand point polymorphic VIs have many things that make using and maintaining them difficult. From the number of files loaded, to custom help, icons, and terminals from each instance, along with supporting more types than the polymorphic could. Don't get me started on when a bug is found and it isn't something you can easily fix with scripting. So then you need to open up each of the polymorphic types and make changes to each one. Oh and ever try to use the polymorphic editor with 60 instances? Yeah I've stopped trying and use a combination of tools so I never need to. Some day, hopefully NI will be able to invest the time needed to make XNodes an official feature. But until then I'll likely need to support many polymorphic types, when XNodes aren't trusted. Variant Repository Non-XNode.zip

Is there a reason you are re-inventing the wheel? If there is a good reason like trying to understand how to communicate with a DLL then go right ahead. But if you are doing this for some fear of using NI-VISA I'd highly recommend you confront your fear.

Topic moved. Also have you contacted NI about this? If this is a real problem they will want to make a CAR for it so it can be fixed.

No problem. I know the stigma around express VIs very well. To be honest I only use two express VIs in a very large amount of my own code. The Elapsed Timer, and the File Dialog. When I do use them, I try to always view them as a normal subVI and remove the label. Still for these two functions, the simple stuff just works. Sure it doesn't have a pause resume feature, but when I need that I'll start with the Express VI, convert it to a normal VI, and then add that funcion. I try to use the native functions first, then OpenG, then other 3rd party tools, then I'll write my own if none of these options fit my needs. I'm sure others prefer similar chain of tools. There are goofy times that maybe the native solution works, but only for half the cases in which I need to remember what ones work in what cases and what ones don't. Like it is nice that there is now a native "Get File Extension" under File I/O. Too bad it only supports the path data type, and not the string like OpenG. In this case a path to string conversion can fix it but there are several examples of this type of partial overlap in functionality.

Oh yes that is a nice little trick to use. Be sure and share that nugget when you find others that don't know that is how it works.

So I know this is a few years old, but I wanted to update it. I stumbled across Altenbach's post here, about converting a 2D to a 1D array. So I combined his code to the code in this post and made two polymorphic VIs that support a few more features. From the 2D to 1D it has several more polymorphic types, and supports concatenating by rows or columns. From the 1D to 2D it has several more polymorphic types, supports specifying the number of rows, or number of columns to make, and supports iterating over rows, or columns when splitting. I wanted to make individual icons for each polymorphic type but didn't get around to it. I also pulled these out of the LLB but admittedly that was just so it was easier to work on, on disk. 1D to 2D Array.zip 2D to 1D Array.zip

Is there a reason you are using this function and not the native "Elapsed Timer" express VI? I've never used the OpenG function and wasn't sure where one would be better suited than the other.

Here is a quick solution that just looks at the value change seeing if the string changed value and if it did read the value of the boolean. A better solution might be to look at the Mouse Down event, and find which index the mouse has entered then read the boolean value and do something else like force key focus off of that control so the user has no way of even entering a string. The way it is right now is sorta strange where you are allowed to enter text in the control, and then it revers back. I feel like a better user experience would be to prevent them from entering the control in the first place. EDIT: Okay another quick and dirty solution, poll the key focus of the string and if it is true then read the value of the boolean, and if it is false, then remove the key focus. I did it this way because with the mouse down event you could still tab into the control, and edit the string control. This way is less efficient because you are checking for key focus but it prevents this edge case. Editable Disable Array.vi Editable Disable Array Poll Keyfocus.vi

I understood some of those words...okay no I didn't.

Your sentence doesn't make sense. That being said no one in the beta program is allowed to confirm or deny the existence of new features due to the agreement with NI. There is no need to spread rumors about what is or isn't in the beta. However, having a discussion about what things you'd like to see in the next version of LabVIEW is fine.

You should really attach your whole build log. That being said the FPGA compiler has gotten much better of the years and can help pin point where in your code the problem is. I'd expect 2013 to give you more debug information. Also if possible post your code.

So my company has site licensing for Windows products. So for me I'll make a new VM (right now I prefer VM Player). When making a new VM you provide the ISO and Windows license and it will do the rest. Then I activate Windows the normal way, if it didn't do it automatically. Then I setup my VM the way I like with various utilities, .NET installs etc. Then I'll shutdown the VM and copy away the virtual hard drive as a clean OS. Then I'll make multiple VMs using a copy of my clean OS multiple times. In each VM I'll install the one version of LabVIEW, along with the appropriate drivers and libraries for that project. When I have a new project I'll make a new VM using that clean OS I backed up. Each VM is then using the same site license of Windows, and each is already activated. Getting major updates can be a bit of a pain, but I just try to keep whatever VM I'm using frequently up to date. Windows 7 also comes with XP Mode which essentially means you get Windows XP in a VM for free. So licensing there is taken care of. I would just make the clean OS in the same way I mentioned before. This means being restricted to XP 32-bit, which is too limiting right now which is one reason I go with VM Player which supports 64 bit guest OSs, and multi-core support.

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.