LabVIEW Idea Exchange

With the increasing size of the LabVIEW ecosystem, there is a growing number of third party tools written in LabVIEW that are versioned independently from LabVIEW's version number.  For example, I could create an API that has versions 1.0, 2.0, and 3.0, and all three versions could be compatible with LabVIEW 2009 or later.  Tools like VI Package Manager make it easy for content creators to publish multiple versions of an API, and for users to upgrade and downgrade between those versions.  However, this ease of use disappears if significant changes have been made to the VIs in an API, such as:

• Changing VI connector panes
• Renaming or moving VIs on disk
• Adding VIs to a library

If any of the above changes are made to VIs in an API between versions, it can become impossible to migrate code between the two versions without a lot of manual searching, replacing, and relinking.

LabVIEW should provide a mechanism to define mappings between old and new versions of third party toolkit VIs.  Consider the case where I make the following changes to a VI from my toolkit:

	Version 1.0	Version 2.0
VI Path	<userlib>\mytoolkit\CompRes.vi	<vilib>\mytoolkit\Compute Result.vi
Owning Library	none	Mytoolkit.lvlib
Connector Pane

I should be able to create a mapping file included with version 2.0 of the toolkit that describes the changes made between versions 1.0 and 2.0 of the VI.  This way someone could write an application that calls version 1.0 of the VI, then upgrade their toolkit to version 2.0, and the application source code would be able to find, load, and relink version 2.0 of the VI without any hassle.

Hi,

It would be awesome if there was an option in project window to set if the method is contained within a .lvclass file or ouside of the .lvclass next to it in the folder.

Now it's like this:

It's hard to use a class like that in a plugin architecture with VIs on the outside. Lets put everything together inside like a LabVIEW LLB!

How it should be:

Don't get me started on Packed Project Libraries We just need LLB functionality, for the class to behave like a folder and we are happy

Piotr

We were thrilled to see that NI developed an OPC UA API. We develop software for both VxWorks and Windows, so having OPC UA available on RT is great. But having to shell out for the entire DSC suite, run-time licenses and all, just to be able to use the same API on Windows is unreasonably costly and forces us to use a different API on Windows. If we could buy the API as an isolated component at a more reasonable price (and with easier licensing) we would jump for it immediately.

A generalized version of the idea:

The DSC can still function as a nice bundle, where the price for the bundle is lower than the total for each individual item, but when NI makes such packages please make it possible to pick-and choose amongst those components as well, so that in cases where you actually have a need for just one of them, you can get it at a price that is reasonable for that individual component.

The concept of fluent interfaces using method chaining applied to a LabVIEW block diagram would be awesome!

When calling .NET libraries from LabVIEW, block diagrams explode horizontally - the aspect ratio of the diagram can easily push 5:1 or worse (it's 10:1 in the example below). Some Method Chaining syntactical sugar would yield a more space-efficient-and-readable 4:3 to 16:9 or so.

Property Chaining is already well-established in LabVIEW - let's get us some Method Chaining!

See the first comment for footnotes...

The State Diagram Editor was a very cool tool and lots of LabVIEW users (not only beginners, far from!) are missing it!

And no, the state chart module is not a replacement for the State Diagram Editor!

Discussion here.

Image borowed from Ben

If NI were to make the following modification to the Word_Save_Document vi, we would be able to generate PDF documents directly out of the Report Generation Toolkit. This may only be applicable to later versions of Word.

What is required is to handle the PDF file extension and set the appropriate wdSaveFormat value for the SaveAs Method. It would also be nice to be able control the show PDF after generation option, but just being able to save as PDF would be very useful.

I very much like being able to export a labview.vi to a .dll or .net interop library .dll. Our higher level automation is in C# and having access to labview.vi via .net .dll is great. However, the current build capability only allows a single prototype/method to be created. Consequently, I have to provide every input/output when invoking this single method. This can work but it's just inconvenient and not as obvious as being able to create multiple methods smaller things, e.g.

write setup values

write DAQ sample rates

start storing samples

stop storing samples

stop DAQs

write summary info

When I create a C# class, I can create any number of methods or properties to manipulate class data members. Exported labview.vi files should enable this too. NI AE said I could create parent.vi files (setup.vi, write_DAQ.vi, etc) that all include the actual vi of interest. These various vis could be added to the exported .vi list. And, this would indeed be a work around. But, this is a hack to get around this problem and the AE agreed. Instead, I would like to be able to define multiple methods/prototypes on a single exported .vi.

Currently, any VIs including .NET code are shown as broken in Labview for OSX.

This is particularly annoying for people working in a cross-platform environment, specially considering that the Mono framework covers a lot of Microsoft's .NET implementation with the added bonus that it works in Linux, Windows and OSX.

Please allow users to choose which .NET implementation to use.

It would be great if LabVIEW supported the Python language, including any of its various packages such as numpy. Such computations would be much more transparent and easier to support than calling code in DLLs. They would also be much more open and flexible than the existing built-in computational solutions in LabVIEW, e.g., expression/formula nodes. Currently, I have to call Python scripts via System Exec.vi, which complicates data exchange. (NOTE: I am using an older version of LabVIEW: 2009 SP1.)

When you get a data changed event from an array, it would be nice if that event included an array of what items in the array actually changed.  This makes it easier for the user to determine what changed and how to deal with it.

Quick Drop plugin VIs can currently be assigned to Ctrl-Key shortcuts.  This is a great way to quickly invoke the plugins that I use most.  However, it effectively limits the number of available plugins to 26, and it makes it fairly difficult to remember which Ctrl keys correspond to which plugins when there are a lot of custom plugins to choose from.  I would like the option to invoke Quick Drop plugins with multicharacter shortcut strings, the same way I can drop common panel and diagram objects with shortcut strings.  One possible way to do this could be to allow plugins to be included with the other shortcut objects in the Front Panel or Block Diagram shortcuts:

I think it would be nice if LabVIEW was smart enough to know that when I drop a For Loop around scalar inputs it doesn't auto-index output tunnels - but rather uses Shift Registers - for matching inputs and outputs.

The common use case for this is with the Error input/output - it annoys me how it becomes an Array output.

As it is already wired, inline and not broken, dropping a For Loop around it should not break my code! 

Reference or Class inputs are other use case too - I want to pass the same thing around not create an Array. 

Shift registers are better than non-auto-indexed tunnels (other option) as they protect the inputs on zero iterations.

This would remove one step required for most use cases, speeding up my development experience.

Now that scripting is "legal" we need to be able to do more with it, when it comes to the event structure scripting is weak.

Here are a couple of discussions where people wish for more scripting functions around the event structure :

- Triggering an event on a picture created with LV Scripting

- Remove Frame Not Implemented

- How do I get the cases in an event structure

- Event Structure Selector Labels

We need to be able to add and edit event!

Currently in LabVIEW you can have a top-level palette (Programming, Measurement I/O, etc) automatically populate based on .mnu files existing in the folder structure at <LabVIEW>\menus\Categories\.  However you cannot do this with the sub-palettes such as Arrays, File I/O etc.

I propose to allow auto-populating palettes for all LabVIEW palettes so developers can place their own palette within the appropriate LabVIEW palette for their functions.  One example is OpenG and MGI each have a palette of Array functions.  They are currently placed in a top-level OpenG\Array or MGI\Array location.  If we could sync these folders, we could place each of the array palettes under the Programming\Array palettes:

Simply by dropping their corresponding mnu files here:

Thoughts?  Discussion on LAVA that spawned this idea is here.

The detailed help link in the LabVIEW Context Help window is a great way to add extra documentation to your LabVIEW code.  However it currently only supports .hlp, .chm, .htm, and .html files types.  This should support many more documentation types such as pdf, txt, doc, .xls, png, .etc, etc.

When creating an installer for a built LabVIEW application, it is very difficult (see here) to include an additional 3rd party installer (such as a device driver or application that your built application depends upon).  What I'd like to see is a solution that treats 3rd party installers as first class citizens.  I'm imagining a new "Additional 3rd Party Installers" page of the Installer build specification properties dialog.

This page might look something like the one in the screenshot below, allowing users to add a folder that contains the 3rd party installer files and define a command that is run inside that folder during the install process.

When LabVIEW builds the installer, it would suck the additional installer folders into the main installer and, after installing your app files and the additional NI installers, it would sequencially extract your additional 3rd party installers into a temp folder and then execute the command line to run.  This is a pretty simple scheme that would really simplify the process for end users.

I'm sure I didn't address every issue of this use case, so please, everyone, feel free to add your own ideas.  I'd love to hear your comments.

Is LabVIEW available for Android based systems and other touch interface systems.If not how about using LabVIEW for mobile measurements using these systems.

I would like a control/indicator which supports HTML formatting for display and documentation.  There have been a couple of previous similar requests, here and here, but nothing specific to HTML (although jlocanis has been consistent in his comments on these previous requests asking for HTML formatting).

I would envision a control where you enter HTML and can change the display from the HTML to the rendered text easily, similar to the multiple modes available on current text controls.

Why HTML and not just more formatting options?

1. Why reinvent the wheel.  HTML has been around for decades and works well.
2. You can mix fonts, localizations, superscript/subscript, symbols, etc. within HTML, allowing much more flexibility when documenting front panels.
3. HTML is platform agnostic

As has been said in other requests, extending HTML support to captions, labels, etc. would also be nice, but secondary.