LabVIEW Idea Exchange

Community Browser
Top Authors
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

I wish LabVIEW had Official Container (Docker) Images.

 

With more and more users trying to use the docker in Continuous Integration, it would be 

interesting supporting a NI Official Image on Docker Hub (or any other place). Containers provide an easy way of creating reproducible tests and builds.

 

The build of LabVIEW docker images has been feasible since NI Package Manager command line was launched, and for NI wouldn't be a new thing.

 

The advantage is that the images (Windows, Linux or Mac OS) could be optimized by NI team only for working for LabVIEW, shrinking size and removing unused files.

 

Anyone else would support this idea or has anything to complement?

The idea is to decouple the icon editor from LabVIEW so users can create their own. The intention is to make it easier for people to distribute their own icon editors by only having to place code on disk and modifying an ini token.

 

This would mean modifying lv_icon.vi so that it contains nothing but a launcher that would load the new icon editor from a path specified on a LabVIEW INI token.

 

There will be a default plugin that would hold the current icon editor, the path to the default icon editor would be a part of the LabVIEW ini file on LabVIEW install.

 

I created a working prototype that does that here.

 

I want to make sure this idea gets traction before going further with this.

There are already a couple ideas to retain wire values on a hierarchy (here and here). This is a request to disable (or toggle) the 'retain wire values' option on all VIs of a hierarchy in the same vein as 'disable breakpoints on hierarchy'. This request was spurred by an investigation into VI performance on resizing a very large 2D array of strings, wherein several memory allocation strategies and lookup strategies (arrays, maps, variants) had been exhausted, only to discover that a subVI whose (front panel and diagram had been closed) was set to retain wire values. Merely toggling the retain wire value setting off on this particular subVI improved performance by approximately one order of magnitude for this particular project.

 

Investigating and accurately measuring run-time LabVIEW performance can be challenging with so many debugging tools available, the impacts of which are not immediately obvious. For this reason, I would like to see a menu option that recurses on VI hierarchy and toggles the 'retain wire values' option, in the same vein as the option which removes all breakpoints from VI hierarchy. The option would be very helpful with run-time performance investigation or optimization.

Spurred by Darren's latest nugget, I think it would be an excellent addition to the feature to be able to retain wire values for all subVIs of a particular VI as well as the VI itself. Several times, I have found myself having to run a VI a couple times to get to the point where I can satisfactorily examine the data flow. There is a JKI RCF plugin by Vishal posted here which implemented this, but native functionality would be much preferred. 🙂

 

I'm not sure how best it could be implemented in UI so as not to disturb those who don't want this, and I can forsee a hairy situation arising if a particular subVI is called from a different hierachy later. Ideally, the subVI would retain values for the last execution in the retained hierachy, but obviously that's incorrect in the grand scheme of things. I'd love to hear other ideas on how to handle that scenario.