hooovahh

If I understand what you want, you are doing it the hard way. Attached is a VI that reads and writes clusters to INI files. I just write the whole Main cluster and read the whole Main cluster using OpenG. Write Read Cluster.vi

That's what I'm thinking. I realize the condition can be a string. But if the value currently is "TRUE", then I can guess with much certainty that the opposite is "FALSE". Same with 0 and 1, and other capitalization of True and False. Personally I haven't made any conditionals that aren't effectively boolean. I generally used them for things like when a system is designed to not have a piece of hardware. So I would have DMM==FALSE and then the code knows not to talk to the DMM and to not show DMM manual controls.

Very neat thanks for sharing. I wasn't sure that this would work as a pre-build, because I know that setting the version of the build in a Pre-build VI doesn't work. The version appears to be read when the build start (before pre-build) and then changing it in a pre-build VI just changes the version which will be used in the next build which isn't useful. Good to know the conditionals don't work this way. One thing I've wanted to do for a while now, but haven't had the ambition for, is to allow conditional items in a project to be toggled using a right click menu in the Project. Imagine if I could right click my project in the project window, and in it is a sub item like Conditional Symbols >> and then under the Conditional Symbols is all of the conditional symbols that are True or False (or TRUE or FALSE, or 0 or 1) and the items are checked or not checked based on the current value and clicking the item will toggle it. The good news is NI has provisions to augment the project explorer window, and this is theoretically possible using this. https://lavag.org/topic/18545-i-have-taken-the-first-step-towards-unofficially-opening-up-the-project-provider-framework/ The bad news is lack of documentation makes it difficult. I tried by taking an existing plugin and modifying it and I didn't get very far. Even so I think this could be a good tool for quickly turning settings on and off with a simple right click.

Attatched is some suggestions. We stop the DAQ task at the end, we stop on error, and we improve the reading by leaving it as an array of waveforms instead of dynamic data types. This allows is to write both channels with one TDMS write improving fragmentation. There are many ways to do this but I decided to keep track of the amount of time that has been logged, by multiplying the number of samples, by the amount of time that separates the samples. Then add those up and if the time is greater than 2 minutes stop. I'd still suggest using an event structure, and some how disable the user from stopping saving, once a save has started. Potentially a user could turn on the save, save for a few seconds then turn it off, and start it again. Now the log data will not be continuous.

Wow that does sound strange. I'd suggest enabling debugging on the built EXE, and then you can probe around. Using something like the simple sexy timing probe you should be able to see what steps in your process are slower than in the IDE. The unfortunate thing is it sounds like all processes are just generally slower. I could also suggest trying to see how it performs with only one worker loop (compared to source) but it sounds like the problem gets worst with more loops so this might not tell you much. Maybe you could do the divide and conquer method and start disabling, parts of the code and see when it starts to respond like the source. Very time consuming, but effective for isolating the problem.

I'd talk your local NI sales rep. Something that specific, and old might be hard to find on NI's FTP site. ftp://ftp.ni.com/

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.