hooovahh

I haven't seen this error but I have seen "Not enough memory to complete this operation". This error happened on a corrupted VI. I kept deleting things until the only thing open was this single VI with a blank block diagram but I still got the error. After playing around with it enough the error went away and I was able to compile. Copying the contents of the VI to a new one fixed it as well. Not sure if these are related.

What's in a name? Turns out alot. I have an Messenging like framework (it was made before Messenging was released), and it took me a long time to come up with a good name. I do think Messenging isn't a good fit, for a few reasons, but it does reflect what the software does which is better than some names. I'd say it should be changed, but I have no suggestions.

Are you referring to the Index Array under the VArray palette? I'd recommend using a Variant to Data converting the variant, into an array of variants, then you can use the native array functions to index the values out of the array.

QuickDrop is stored in the LabVIEW.INI but I tend to just blow these away periodically because I'll be developing plugins that then get in a limbo state. If these keys are in the INI it just reads the VI Description of the plugin VIs and sets their shortcut to what is in the description. Also as for synchronizing settings glyphs etc. We have large reuse library, and one package is for glyphs, and another is for "Templates" which has morphed into containing other settings too. During the package install it has a Post-Install VI that sets INI settings to how they should be. It also installs a few quick drop commands, and sets up the shortcuts for right handed developers. Generally we install the reuse library on a fresh machine from a base version, which includes all these packages.

Very neat, I think I may have met you guys at NI Week. Does this require or use the NI C code generator toolkit?

I had a white board that I would write bullet points on before leaving work. Even 18 hours later these would some times not make sense, but most of the time it was just enough of a reminder to jog my memory.

Yes OpenG also has their versions of getting data type of a variant. It bugged because in version 2011 the OpenG version was about 10 times faster than the NI version from the lvlib, but in 2012 and newer the NI version was about 10 times faster than the OpenG. At one point I had some goofy code that would know the version and pick the right one, but I convinced myself it wasn't worth it and to just go with the native (NI) solution whenever possible.

I agree with bookmarking, but to be honest I do this. The most common way for me to break a VI will be to double click white space on the BD to start a wire, then double click some other spot to end the wire. I've talked to some developers who didn't know you could do this, but then again how often do you want to start or stop a wire that isn't connected to anything.

There is an FTP palette in at least 2013 under Data Communication >> Protocols. There is also other FTP options like the internet toolkit, the real-time toolkit I think has FTP, and even command line options. All of these except the last should have examples in the Help >> Example finder.

Conditional indexing on For and While loops was added in LabVIEW 2012, which should be an issue because you are using...LabVIEW 2015...

I think I've mentioned this before, but our entire reuse from 2011 (and it is quite big) and all Windows based projects from 2011 to 2013 have has separate compiled code on every VI. Haven't seen an issue that was traced to this feature. We haven't used 2014 on any real projects yet.

I don't know where I fit in the spectrum of average LabVIEW users, but I would not be able to make the same application that I do today in 2013, in 6.1, without many extra weeks put into custom code for UI design, and work arounds and even then it wouldn't work as well. Drag and drop, events, property/invoke nodes that were added, VI server control, subpanels, user events, I mean have you ever tried to make a multicolumn listbox in 6.1 and have it be interactive? Sorting based on column clicking? Because I did once, and gave up when I was doing it with VB code and .Net to make tables. Not every version delivers a home run in terms of features, but many good tools come in 3 years, let alone 12. But I do understand the pain of upgrades, which is why I mentioned we don't upgrade unless we see a need. That being said since 2009 NI has done much better at maintaining version compatibility and feature set. I'd bet a large majority of 2009 projects could be opened in 2014 and work as is. There are probably a few tools that have been deprecated but I don't know what they would be. Also please don't think I'm attacking you. I simply think 6.x is too far. I'd say the majority of my code could be done in 2010 or 2009 without much trouble.

Thanks for the info, but this issue is not related to this package. No where in the spec file does "<Path>" appear or any "\" in respect to a path.

Put me down as another who has issues with this. So I make a VIPC with all the OpenG, internal, and some other packages for easy install for other developers. I started getting complaints that they couldn't install the VIPC with VIPM 2014. So when I got some time I installed each package one at a time until I found one that wouldn't install and the CCT was the culprit. It was a little weirder than that too. If a user double clicked the VIPC file that contained the CCT in 2014, then the Tools Network dialog would show up. Instead of the dialog asking about installing the VIPC. The same thing happened if I double clicked the 3.2.1-46.ogp file. The only way I could attempt to install it was to go to File >> Open Package File(s) and select the file. At this point I got the error saying there was a conflict. So I extracted the package, edited the spec file to not have any conflicts, then re-zipped it into a 3.2.2-46, and then I was able to install it by going to File >> Open again, but not if I double clicked the file. I don't mind attaching my version but I feel it would confuse people. Looking at the repository it looks like a version 3.2.2 was planned but never built. At the time of all of this confusion the developer had no packages previously installed.

Running applications from source is a bad idea in almost all cases. I highly suggest building EXEs. That being said it is more work to make an EXE. Especially if for some reason the builder craps out and you need to start over again. Locking down an application is critical if you are taking any kind of measurement so you know a developer wasn't fudging the numbers, or adding filtering and averaging to make it pass. I'm lucky enough that my company currently has a renewable license scheme, so I don't have to deal with your specific problem. LabVIEW 2011 is the oldest I currently go back to, but all active programs are developed in 2013 SP1. We generally wait until the SP1 release before using it on any programs. We don't usually upgrade a project to a newer version of LabVIEW, unless we see a need for it. It has added risk associated with upgrading, which is why we have some older programs running 2011. Having all versions you need is important because saving as 2011 in 2014 means you can now only open it in 2014, which could be a problem if all of your developers don't have the appropriate versions. 2011 is basically the oldest I'd want to go back to. 2010 didn't have static VI references, and a bunch of the other application control functions used often today. Here are some of the major benefits I see from going from 2011 to 2014. Conditional auto-indexing, and concatenating loop options. Icon Editor API for code generation. In 2011 there was some kind of API but starting in 2012 it had more exposed. Code complexity metrix using VI server New scripting functions, some with events Bookmark Manager, for keeping track of todo's or other tags in source Improvements in QuickDrop. Especially the auto-wire, which could be done in earlier versions. Clear specific error (OpenG has a function like this) More control over events with the events palette Event structure now has a trace window for debug Events can be lossy Much improved shipped examples Improved versions of the Actor Framework Mouse scroll event And what might be a big selling point, is the fact that the Professional and Full LabVIEW 2014 now includes PID Fuzzy Logic Toolkit, and Professional also includes Database Connectivity, Desktop Execution, Report Generation, Unit Test Framework, and the VI Analyzer Toolkit. EDIT: Oh and lots of FPGA and RT updates

Classic Shell to the rescue. I have Windows 8.1 boot to the desktop, with DisplayFusion and Classic Shell. It is like Windows 7 but better. I seriously have never seen the metro interface since installing these.

The blue-ish or green property or invoke nodes indicate scripting. Saying "Scripting" is not available in the run-time engine is an absolute that is a little fuzzy at times. Some functions are indeed only available at run-time. Like the Save Instrument invoke node. From a build EXE you don't have the ability to save a VI, so this function won't work in the run-time engine. To know if your function specifically is supported in the run-time you can open the context help, and over over the function. It will say if it is supported in the run-time engine and real-time. If this function works in the run-time engine, then you should have no worries using it. If you would like to enable scripting, so these functions can be used, other than copying the one you have, you can enable it by going to Tools >> Options. Then under VI Server check the box that is Show VI Scripting functions. Now your property and invoke nodes will have a lot more functions.

It's worth a read for sure, glad it was un-deleted. I still struggle to know when TestStand should be used, simply because for me the barrier to entry is higher. Oh you want to bring in another test tool? So developers that know some LabVIEW but have no TestStand experience will only be useful for developing pieces. And there is a development license cost, and run-time license cost? That on top of the fact that we have many already made tools for doing limits, test selection, reporting, manual control, etc. Don't get me wrong, I know TestStand's power, and in most testing applications, if all things were equal I would use TestStand, but unfortunately all things aren't equal, and being able to justify it to myself, and to management is difficult.

Awesome chain of discussion guys. Sorry OP if this is derailing the conversation but I think it still is relevant to the original question. Making and using polymorphic VIs is a major pain point for several reasons. And from a reuse stand point there isn't many other options. Replacing polymorphics with XNodes (if every officially supported) I think would help because you replace the 40+ instances with a custom scripted VI. No idea if it scales well. Jack you mentioned replacing polymorphic VIs with their instance. In my mind this is something that could be done quite easily with scripting for a while project. This could be a VI that is ran periodically, possibly as part of the Pre-Build VI that could help clean up the project. Did you ever make this scripting VI? Could you see sharing it if you ever did?

If that is the case I'd hope that there are some command line tools for imaging a disk, and I'd recommend just calling them. EDIT: Here is one such tool that I've never used. http://uranus.chrysocome.net/linux/rawwrite/

This is nice but I have a few questions. So I noticed there isn't any documentation when the Context help is open. In the past I've used the GetHelp Ability and read the VI description from a template. I would prefer that if a selection was chosen that was not in the range of items, that it would use the default data type for that data. So an empty string, or an empty array. This is more standard with the way NI does things too, like when indexing an array with a -1. I'd also like a more recognizable icon, but at the moment I don't know what I would want it to look like. Maybe it could resemble the Select primitive some how with a question mark, and lines that merge to the output terminal. Should all inputs be required? The Select input terminal is a U32, which is then converted to a I32. Could this input just be an I32? I realize this means you would allow negative numbers but again I'd prefer this, and to have the output be default if this is the case. Also what is the Select Mode options supposed to do?

Either this is very easy, or you aren't giving us enough information. You can write file using the File I/O palette. You can also use some of the image tools to save files in various file formats. If the SD card is mounted as a drive in Windows any of these tools can be used to write to this location.

Oh it took me a bit but I figured it out. So in your Sender.vi, in your second for loop you are waiting on the notifier. You are waiting on them one at a time. And you know that the first one will not reply until one second, because the receiver has a wait 1000ms after getting the event, before setting the next one. So you wait for one second before ever looking at the second notifier. But the second user event (and all of them) have already been generated at this point. What this means, is you maybe waiting on the first notifier before moving on, but all the other notifiers are already being set. It is a sorta race condition, where the race is because you set notifiers 1s after getting the user event, but you only wait on notifiers one at a time. Maybe a dead lock would be a better name for this. A easy solution would be to turn on for loop parallelism in the second for loop, and wire the size of the notifier array to the P terminal. This way all notifiers will be waiting at the same time.

Not trying to change the subject, but I avoid LLBs at all costs. Every time I find one the first thing I do is extract the VIs from it. I feel that way because it seems like a zip or an archive, where to use it with the normal tools, I need to extract it anyway. I also know there were odd bugs a while ago where the LLB would get corrupted and ruin all the VIs in it. I know that is petty especially since it probably has been fixed long ago, but it still lingers as a thing to avoid in my mind.

Yeah this "feature" kinda sucks at time. And I'm a little disappointed that no other posts have been tagged with "things about labview that suck" but whatever. If it makes you feel any better, in the build environment generally these unused dependencies are removed. In the build specifications under Advanced there is a checkbox for removing unused items. Then at least they won't exist in your EXE, taking precious loading time. As for the development environment, yeah modulating code helps. But doing so usually means more VIs in general, which means more dependencies on disk. I don't find it that bothersome, but if you have 100s of libraries and classes I would be pulling my hair out trying to find a better solution.