LabVIEW Idea Exchange

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

This idea has come up repeatedly over the years: a new VI created in a library* should default to private scope. The point of private scope is to limit the number of callers of a subroutine so you can freely refactor the subroutine and know, without question, that the only callers that you can be affecting are the ones inside the library. This allows you to make API breaking changes freely because you can know you are updating all the callers. Note that if we did this, it would almost certainly have a Tools>>Options setting to change it, but the idea is to make "new VIs start in private scope" be the shipping default.

 

Each of the other scopes is more permissive in some way, with public being all the way open. For APIs intended for reuse and long-term stability, use of those other scopes ought to be a conscious decision.

 

The vast majority of VIs within most libraries should be private. There are some weird exceptions**, but most libraries have a few routines intended for the world to call and a bunch of subVIs that support the public ones. But going and setting the access scope to private is a lot of work, and many developers never think about it. For small shops, this isn't usually a big deal, but the larger the dev team, the greater the danger of highly interlocked libraries caused by someone reaching for some deep subroutine that just seems so useful, instead of doing the right thing and refactoring that VI out into its own shared library. 

 

I've seen some of our customers get really badly bitten by this, but it is an issue that takes years to build up, and then requires expensive refactoring projects to fix (or cloned code, which is sometimes worse in the long run).

 

C++ and C# default everything to private unless you declare public; I think that's true in most text languages.

 

But LV is a programming language for non-programmers, and not everyone needs to understand access scope, so creating new VIs as private by default would push yet another concept into the "you must learn this" category instead of "learn this when you hit a scale where it is useful" category.

 

In the end, I think access scope is a simple enough concept, one that most people using libraries get familiar with pretty quickly, and switching something to public is easy enough to do. Therefore, I think switching the default would do more good than harm. So that's what I'm proposing here.

 

* includes plain .lvlib libraries, XControls, LabVIEW classes, state charts, and any other type of library NI may introduce.

** such as the NI Analysis library, which is hundreds of VIs packaged together, mainly for licensing reasons, less because they have shared functionality.

Currently enums can not be in a cluster that you want convert to JSON. It would be great, if this could be added.

 

Either the enum value could be converted to its internal representation (e.g. u16) or the value could be saved as a string (make it easier to read the JSON and parse it outside LabVIEW).

 

The unflatten should be able to handle the u16 easily to convert back to enum or take the string and search through the enum of the datatype that one has to connect to the vi. If there is no match the VI can issue an error.

 

When reviewing old projects or VIs, the "VI changed" title bar star is always only a few mouse clicks away. And beware of accidentally opening an old project with a newer LabVIEW version!

 

You all know the "vi has unsaved changes" dialogs that follow when just wanting to close the windows, and who has not at least a dozen times saved an old VI in one of these situations just out of a misplaced click or the habit to save your code whenever you you are prompted to...

 

 

This is why I propose a new file menu entry: open (locked)... or open (read-only)... or an "open options" control in the file dialog.

 

Its functionality would be to open the selected file or project in a similar way like the locked VIs: you can look at them, browse through case or event structures, but cannot change a thing...

 

Even better would be the option to allow changes (e. g. move/delete some portions before selecting the rest for copy&paste), but to prevent re-saving the file under the same name. For this case, trying <CTRL-S> or closing the file would open a dialog stating that the VI was opened as "read-only" and that you may either discard the changes or save the file under a new name.

 

Of course, this "read-only" flag would be inherited to all subVIs, typedefs etcetera that would be opened from the original project or VI.

 

And to make my whishlist complete, a color coding of the VI window / project frames would signalize the read-only state of the code:

 

 

By the way: Wouldn't it be nice if VIs in vi.lib featured this opening mode by default?

 

Best regards,

Sebastian

 

I'm looking at a clone. I don't see why I would have to ctrl-M to get an editable version to do such things as:

 

- get the contextual menu up on the VI's icon to 'find all instances'

 

- get help on a VI that's on the clone's block diagram

 

- open or find all instances of a typedef via its contextual menu (the typedef being on the clone's front panel or back panel)

I recently found out that LabVIEW uses the Wichmann-Hill (1984) random number generator.

http://digital.ni.com/public.nsf/allkb/9D0878A2A596A3DE86256C29007A6B4A

 

...which in some fields is completely unacceptable for not being random enough (cycle length of 6.9536e12?)

A much better (and arguably a much more currently standard one) would be Mersenne Twister (cycle length of 2e199371).

http://www.mathworks.com/help/matlab/ref/randstream.list.html

Hey,

 

how about a "Delete all But this" (similar to Notepad ++) for cases in an case structure. This would save the case-structure and the code inside for the selected case.

I know, that I could delete the structure, keep the active case and get a new case structure around that piece of code...but that's not comfortable.

AllBut.png

Regards,

CMW..

Hello,

 

In many of my applications i had to run dynamic assynchronous VIs using a VI path.

 

When the VI you want to launch has some problems (VI broken, missing ressources, ... ) you get the generic error 1003. (The VI you want to launch may be broken ... ? )

 

This error can be easily solved when you are using LabVIEW IDE. Smiley Happy

 

But sometimes, this error can occured in an executable you have deployed to your final user computer.

And then, the error 1003 (The VI you try to call may be broken ... ) is a little bit poor in order to analyse the problem. Smiley Frustrated

This error occurs, for example, when the dynamic VI tryes to access missing DLL's.

 

It would be nice, if the error 1003 message, could be filled out with and additionnal "error description", giving more informations about the error source.

For example, an error list, like the error list in the LabVIEW IDE. (Broken arrow error list !)

 

Thanks a lot.

 

Manu.

This one is pretty simple and straightforward but very needed.  "Match Regular Expression" function is an advanced version of "Match Pattern" function.  When I start with Match Pattern and then decide I need more, my instinct is to Quick Drop > Replace or Right Click > Replace it with Match Regular Expression.  Unfortunately, the inputs get all wrangled up and don't connect to the right places and I get something like this:

 

Match pattern replace.png

 

 

The longer you use LabVIEW the more accepting you become with the way it is and I don't think I could have come up with this one my own.  A new LabVIEW user suggested this idea to me.

 

When the VI is in edit mode show a glyph over the controls and indicators that assigned to a terminal on the connector pane.

 

 

The Desktop Execution Trace Toolkit (DETT) can trace enqueue/dequeue operations, so I would think this is feasible:

 

Add a mechanism to like the Profile>Performance & Memory view to display all active queues in memory by name (for "unnamed" ones, use whatever unique refnum/identifier is available) as well as the max size and current # of items in queue. You could use the same "Snapshot" functionality as the Profiler tool.

 

A particular use case:

We were tracking a memory leak in a large application that resulted from an unbounded queue whose consumer was disabled. The standard DETT and Profile tools weren't showing where the excess memory consumption was coming from, since queue data does not "belong" to a single VI. Granted, you can see the individual enqueue/dequeue operations in DETT, and even highlight pairs, but that's a little cumbersome in a large application.

With Application Builder installers there is no way to flag a file as a 'shared' component in the build specification.  This feature is used in MSI installation when files are shared or common among multiple product installers; for example, the files located in \National Instruments\Shared are common dependencies for NI products or in LabVIEW-built EXEs this could be a shared dependency between two applications, like a DLL.  Currently, if two product installers built in Application Builder install the same file, when either of these products is later removed the shared dependency goes with it and the second product is broken!

 

Some good news is you can use MSI editors like InstallShield to edit the MSI after creating it with Application Builder in order to enable a tag/setting for your shared files:


InstallShield.png

 

There are also open source MSI editors available, like Inst Edit, with similar options for tagging files as shared components.

 

What can be done in Application Builder?

Could an option be added to 'Source File Settings' to tag files as 'Shared' so a third-party MSI editor is no longer necessary?

AppBuilder.png

I would like to include arguments for any/all shortcuts from the installer. Currently you can build a labview installer to put shortcuts on desktop and to the "Program Files" menu. But there is no option to include arguments. See attached image of how it would look in labview.

 

InstallerShortcutArguments.png

 

This would allow for the installer application to include file path arguments into any executable. Example: You want to include a tftp server application for the installer and embed the tftp path in the shortcut.

 

It could also be usefull to run the same labview app with many startup arguments. Like if you have a debug mode and normal mode. If you want to include both options on the desktop you could use a -debug as the argument. And include it in the shortcut from the installer. Both shortcuts would point to <application> but one would also say "<application> -debug"

 

Thanks.

 

-Corey

There is a method how to call a .exe with Parameters over the  ( http://digital.ni.com/public.nsf/allkb/17C3AD70493CE0208625666A00763364?OpenDocument)

But there seems to be no Way to give a Value to Return to the cmd as ReturnValue.

In C this would be expressed instead of

void main(void)

as 

int main (char *Args[])

{

return = x; // returns X as return value back to cmd

}

or similar.

 

The only way to do this now is to write a C DLL wrapper around the Exe and call this one to get a custom Return value. This is not very comfortable when you choose LabVIEW in order not to have to write in C.

Instead this should be included in the Build Specs just like with the Arguments. The Datatype and Data to be returned should be specified via Property nodes, and the Value should be passed back up to the CMD when finished.

BuildSpec.png

This is handy when using Batch scripts.

The updated to IEEE 754 adds a half-float and a platform independent quad float. We have a project where a data source will be giving us values in half floats (16-bit). It would also be nice to support quad floats (128-bit) since the current EXT datatype is platform dependent.

The ability to batch-compare VIs with the Compare VI Hierarchy function is great, however for some reason it will just list all the VIs in the hierarchies with an icon next to it indicating which ones are different, same etc. so you have to browse trhough the whole list with a sharp eye to figure out which ones were different. Very impractical.

 

Please add a filter to the results list . This should allow us to only see the VIs which were in a given category - with "Different" as the default filter.

 

filtercompareresults.png

Auto suggestion on placing front panel objects

 

When we place control or indicators in front panel, suggestion as shown below will make easier to arrange front panel objects neatly

 

22869i0D77F2C11C59F25A

 

__________________________________________________________________________________________________________________________

 

22871i1ADA9BAB64279597

 

 

Sridhar

There is currently in the VI File Menu the options to Close or Close All.

 

I think it would be a useful addition to also have a Close other Vi's option. This would leave the VI you are in open and close all the other VI's; very similar to the Firefox Tab option Close Other Tabs

 

I very often have a main top level VI open and over time when tracing through some code will end up with a lot of sub-vi's from this top level open. It would be good to be able to go back to my top level and then close all the other VI's to clean everything up before I start looking at something else. However at present I have to close the top level one as well and then open it again

 

cheers

 

Dannyt

I use a *lot* of OpenG and Internal reuse VIs (they can make up to ~95% of the number of VIs in a project), and, as they're all considered validated and released, I consider them the same way as anything in vilib.  To that end, I don't want to see them in my project VI Heirachy, so I'd like to see a method to selectively filter all items from user.lib (that's where VIPM puts all my reuse stuff, as well as OpenG stuff).

 

 

AddAButtonToFilterReuseComponents.gif

When using the LabVIEW Internet Toolkit FTP library to transfer large files, there is no way to determine the progress.

 

I propose a notifier be added to the FTP Registry object data. This notifier would be updated by the low level TCP Read Stream and TCP Write Stream vis and monitored by a UI to display progress of the transfer.

 

See this NI Forum post...

 

FTP transfer progress bar

http://forums.ni.com/ni/board/message?board.id=170&message.id=470946 

 

 

 

 

When producing a 3D plot with an array containing NaN values, the plot should not interpret these as zero. Rather, these points should be disregarded so that the black lines do not appear. Given the way Labview handles arrays, there is no way to remove these elements given the way that the data is generated and as such it must be left up to the plotting algorithm.

 

3d plot NaN.PNG