hooovahh

A fun little experiment I'll do is write some code, and then if I'm unsure if something needs to be closed I'll throw it into a while loop (or use the continuous run for the first time that year) and monitor memory usage. If it goes up, then I'm not closing everything, if it is steady, then all references that need to be closed, are.

Exactly. JKI was delivering a framework that is meant to be light weight, flexible, and with as few dependencies and extra steps as possible. Enums are great, but there is flexibility with strings that JKI wanted. I don't use it often, but allowing for arguments to be passed is also a handy feature. I can do something like "Wait >> 100" and have my state wait 100ms. Or "Close References >> Shutdown" which will close some set of references, but ignore any errors, because we are shutting down and I don't want an error to interrupt the shutdown process. Or how about the steps involved in adding a new case? It isn't a ton of work with an enum, but it certainly is less work with a string based design.

It won't work in the Run-Time engine for several reasons, one is generally there is no block diagram, and many scripting things don't work. As for the application instance. If you launch it from the tools menu, you may want to pass in the instance that the user already has open. So if I already have my project open, it might be a good idea to use that instance because it is already loaded in that instance. When using a tools menu there is a couple useful property nodes for Application >> Menu Launch >> App, and VI.

Either erase it and see if it breaks things, or you can try to make a new blank class, having the same data type as yours, then copy the Val from the fresh one to your new one, replacing it. No idea what the line actually does.

Yeah that's a major red flag. The class file (and libraries in general) are just XML so I'd so open it in a text editor and see what it shows.

I've used some debugging things like what you described in the past, but they were invoked by the tools menu, spinning off a VI that just monitored data that was more global. I think your best bet would be as mentioned earlier, a probe which invokes a VI to be called which polls your data.

It took a decent amount of time to just read and understand what is going on here. Very interesting stuff.

Obviously I was referring to the online role-playing indie video game for Windows. http://silkgames.com/nestalgia/ ...

For me it was 7.1 but that doesn't mean I would ever attempt to start a new real project using it. Maybe its just the nostalgia. EDIT: Stupid spelling mistake.

My use was I had some tools that prepare code for getting ready to package it up using VIPM. This is the same tools I've used on things like my Variant Repository and Circular Buffer. I would run a VI that opened the code, removed compiled code, turned off debugging, automatic error handling, lock the VI (no password), and add some text to the VI Description. So for me I wrote the code to work in the oldest version of LabVIEW supported. So when I was packaging up code that worked in 2011 and newer it worked fine. When I had a package that needed to be 2013 and newer I tried running the same code, which is when I found this change. Good to know I'm not crazy. Also I guess its a good thing this is a private function. Finding bugs in private functions makes me feel like NI did the right thing by not making the function public. But I'm sure we have all the bugs worked out now so it can be public right....right? Related idea exchange. http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Open-VI-reference-without-refees/idi-p/2329706

You can still have it be self contained in the EXE, you just need to convince the application that it is a linked dependency, by adding a place that loads the VI into memory, but doesn't actually call it. Then load the VI from name, or from the path in the EXE if you know a way to get that. The 8.x era and newer had a flat EXE structure, so this was a common way until libraries and name spacing came about. But yeah you're right, the Preallocated clone existed in 8.2, probably introduced in...8.0?

Yeah that's a little extra work, but more or less what I was suggesting. If you have a VIT, and open a new reference to it, it will make a new instance that is in memory. So you don't need to mess with copying files or generating new file names. Just make a VIT (rename a .VI to .VIT) then pass that path to the Open VI Reference, and with the options left at 0 it should open a new reference. If you wanted the reference to the VIT file, and not a new instance you'd use 0x02 as the option on the open.

Wholly crap cakes. Why not LabVIEW 3? If this is a legacy program I understand. Otherwise the time taken to implement this in 8.2 would be better spent upgrading. Seriously in 2011 there was the addition of static VI references, and Start Asynchronous calls, along with the two reentrant options, which I'm not sure when the shared option was introduced. Oh and in newer versions LabVIEW's for loop has parallelism built in, but I'm not sure that would fit this design. That being said this type of thing has been done in 8.2 (and older). Back then it was common to make a VI template (.VIT) then open new references to it, set control values, and invoke run using VI server. There was added work to ensure that the VI was added to the built EXE, and that the path could be found, or at least the VI name but it could work. As much as I hate using VITs (because they have been deprecated more or less today) I think they would work well for you.

Attached is an update that will work. If you had done proper error handling then you would know that the path to the VI is not the same in an EXE as it was in source, and that by not referencing the VI in the main the compiler has no way of knowing that it needs to include it. The fix is to put in a static VI reference to the VI, get the VI name, and then it doesn't matter where on disk the VI is it will load it into memory and use it. WykresOnlineCAN.vi

I can understand why you would think that way, and users would probably generally want the function to work that way. But by the rules of LabVIEW, when you register for an event on the array, you are registering on the array control, not on the control within the array control, that is a different reference and it seems you've found how to get at that reference.

The first post is password protected for a reason and AQ mentions this. The private functions he used in 8.6 have not become public since then. If you have private methods enabled I believe he is using the Application >> UnattendedMode, setting it, then opening the VI refs, then clearing that.

Okay did NI change something, or am I crazy? I only have access to 2013 SP1 and 2014 SP1 at the moment but both of them don't appear to work as I thought this function used to. Attached is a VI saved in 2013 which should get the path to the Add File to Zip.vi in the vi.lib. It will then use this private function and try to read the VI Description. When it does it returns an error that the reference is no longer valid. So I ask again, am I crazy? Or did this undocumented function just demonstrate why it was undocumented? EDIT: Okay this might be because the VI is opened in a new application instance, and if it isn't being used it closes, which closes the VI references opened in that application instance. Because I noticed if I took the App Ref output and closed it manually later, then everything works as expected. Is this new? Open Without Refees.vi

Very funny Jim, I smiles throughout the video, but I laughed at "ship it".

You used 4D arrays. That alone should be worth some extra credit.

It sounds like you've done everything right as far as I can tell. Does the camera work on a non cRIO device? Can you just plug it into your PC and have it show up in MAX? In Windows you have to enable Jump Packets, is there something like that on cRIO? Even if that wasn't there I'd still expect the hardware to be detected. This sounds like a thing NI can probably help with more. Are you getting support from an applications engineer on this yet?

Okay for this to work the first thing you'll need to do is convince Windows that there is two mice. By default if you plug in two mice into Windows, they both will control the same cursor. I'm guessing to do what you want you'll need two cursors (but I'm not sure). If you look at the Initialize Mouse on the pallet you'll see that there is a constant on the block diagram which is the "DeviceIndex" and is set to 0. I'm guessing you can make a copy of that VI, where that constant is a control input, and you can choose which mouse to initialize. But as I mentioned before I suspect that this will only work once Windows has two cursors but you might get lucky and it might not need that.

Okay because I like you guys (and I like XNodes) I've made an XNode that takes an input array of size 1 or greater, and will output an array of that same type, of that same size, but the values of the elements will be the default for that data type. It uses the method posted earlier by jcarmody. Feel free to look at how it works by looking at the XNode Template VI. Source is saved in 2013. Initialize Array XNode.zip

Oh fiddle sticks. Well I guess this method still works for numeric types that don't support things like NaN and Inf. EDIT: By the way this would make a good XNode. Wire in an array of any size, or any data type, and it will return an array of the same size and data type, with the default value for that data type.

Oh I know an easier one to that (rube anyone?)

Or wait until one of the spammers post links to the movie here. (but seriously though don't post links to pirated content you will be banned like the spammers)