From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW Idea Exchange

Post an idea

View All (3)

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.

View All (8)

There are many VIs located beneath the "<LabVIEW>\resource" folder that need to be called as subVIs of LabVIEW add-ons (e.g. project providers need to call provider API VIs located there). However, because the resource folder is not a Symbolic Path this introduces many challenges for LabVIEW add-on developers. LabVIEW add-ons that link to VIs beneath the resource folder cannot be moved to a new location (for example as part of a source distribution build step), otherwise they will not be able to find these resource subVIs (since they link via a relative path between the caller and subVI, rather than a relative path between the resource folder and the subVI). Note that NI doesn't really feel this "pain" since most of the add-ons NI develops are developed "in place" beneath LabVIEW and ship with LabVIEW -- they don't get "built" and they don't get "installed". However, for 3rd party add-on developers, it's critical that the resource folder be a symbolic path.

Note: This would make building packages of project provider plug-ins possible with VIPM.

View All (4)

View All (2)

[Cross-posted here on the JKI blog]

One LabVIEW feature that (if it existed) would make a big difference for VIPM users is the ability to refresh the menus (e.g., the File, Tools, and Help menus) programmatically after installing packages that add menu-launch VIs. Maybe we could do this if LabVIEW added a new VI server method called Application:Refresh Menus.

Note: this would be similar to how we can refresh the palette menus programmatically by invoking theApplication:Refresh Palettes method (shown below).

I bring this up, because one feature that I’d love to see added to VIPM (some day) is an easier way to build menu-launch tools into VI Packages, and I’m sure more people would be asking us why their add-on doesn’t show up in LabVIEW after it’s installed.

Hopefully, we can help NI get this feature onto the LabVIEW roadmap by convincing them that it’s worthwhile.

Having a continuous integration system is an essential component of software development:

Continuous Integration Process

This system requires automating the building process.

The LabVIEW development environment unfortunately does not have built-in tools to achieve this easily.

But the community has supplied a few sollutions to achieve this: CLI Tool

On of the biggest hurdles that yet remain, is the fact that the application builder is inherently tied to the development environment.

This requires a valid license for the environment and all toolkits / technologies used in the source code of the product you intend to build.

My proposal would be to have a special "CI" license in which all required modules and toolkits are activated, and that would allow the development environment to launch in some sort of protected mode that prevents users from actively developping code (while still allowing scripting functions), for the sole purpose of building applications.

View All (3)

One practice which is increasingly debated in the community is the packaging of code for distribution and collaboration, and which tools to use.

I suggest that NI should define and maintain an open standard for distributing packages of LabVIEW artefacts (.vi, .lvclass etc).

And include a frontend to this in LabVIEW. This package manager should handle dependencies between packages and across LabVIEW versions and targets. The typical use cases would be:

The distribution (online or shipped with labview) of:

NI examples
NI drivers
NI toolkits

The distribution of third party species of the above

There should also be an API so that applications can use this mechanism to be modular and extensible.

Cheers,

/MArcus

Idea:

Create a free, stripped down edition of LabVIEW for general purpose programming (GPP). Let's call this hypothetical edition "LabVIEW Lite". By GPP, I mean programming tasks that have nothing to do with data acquisition, test, or measurement- tasks such as creating generic PC, mobile, and web applications. Former text-based programmers would flock en mass to LabVIEW Lite for GPP use cases if a free, stripped down IDE were available. Imagine the recent popularity of the Eclipse IDE and Java, only with LabVIEW Lite and G!

Rationale:

LabVIEW Lite would exponentially promote the paradigm of graphical system design.
Few (if any) structural dataflow languages are available for GPP.
Structured dataflow languages are insanely cool! Inherent parallelism, increased productivity, and hierarchical system design are only a couple of reasons. These are things other GPP programming languages can't offer.
16, 32, 64, ... core consumer devices are coming! LabVIEW is poised to exploit parallelism in a way that is hopelessly messy with text-based languages.
GPP use cases of LabVIEW Lite would spark user ideas for many non-GPP use cases, for which NI would receive full LabVIEW and NI hardware sales.

Implementation:

No measurement/test/data acquisition VIs or tools.
No FPGA tools.
Application (exe, dll) builder for stripped down applications.
The LabVIEW IDE we all know and love.
Primitive types, clusters, structures, loops, file i/o, etc. provided.

I think it's a shame that programmers today aren't using G! What do you think?

View All (4)

LabVIEW currently allows users to execute a MATLAB script inside the "MATLAB Script" structure, which lets you add inputs/outputs to the edge, set datatypes, and then type your MATLAB code in the central box.

If you already have a MATLAB script, you can use the right-click menu to "Import" (and conversely, you can test a script in LabVIEW and then Export it, if you wanted).

However, you cannot link to a script by path. Importing simply copy-pastes the content into the Script node. This behaviour, whilst probably useful in some cases (avoid future changes to the .m file breaking your nicely tested LabVIEW code) is different to most other nodes I can think of (Call Library Function Node, Python Node, .NET methods, ...).

Please add an option to pass a path to a "myFunction.m" file to the MATLAB execution system rather than copying the contents of a .m file into the structure's box.

(As a workaround, I believe this could be accomplished by running the MATLAB interpreter via command line and using the System Exec node, but that would require various path -> command line string parsing operations, and perhaps complicate cleanup of VIs using MATLAB.)

This idea is about a new LabVIEW feature, the Packed Project Library.

To statically use a packed library as a dependency, you need to add the library to the LabVIEW project. After that's done, all the callers link to the packed library. If you're strictly a library user, then whenever you need a library update you simply ask the developer for one.

But what happens if you're a packed library user and developer of the same library. You can't use a packed library as a static dependency until you build it and replace the lvlib with the lvlibp...but you can't develop the packed library after it's been built and replaced in the project.

If you're a user and developer, it makes sense (to me) to maintain two separate projects. One manages the packed library resource, one manages the application.

What if there were a way to revert the packed library to the LabVIEW library from the same project? You could use the spiral development model and simply switch between the two types of libraries during development. You could also (and this IMHO is the most important part) incrementally deploy and test the project. If you're strictly a packed library developer, hopefully you're incrementally testing anyway.

My final pain point with the packed library is with respect to upgrading the application. Similar to above, if you're strictly a user, you pray the developer is still in business and ask nicely for an upgrade. If you're a user and developer, and you didn't maintain two projects, you might think to replace each static packed library subVI in the application with the original source and then rebuild the lvlibp. Or you might think to create a new project that includes the lvlib and rebuild the lvlibp yourself. I haven't tried it, but I hope that you can replace the original lvlibp with the lvlibp from a new project (not the one that created the original lvlibp).

This leads me to a best-practice for lvlibp: always use them as dynamic dependencies. That way, you can maintain and develop the packed library in the same project that uses the packed library. You'll simply reference the resources differently.

Even if you don't kudo this idea, I'm very interested to hear your feedback and experiences with the lvlibp.

Thanks!

Steve

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.

What do you need our team of experts to assist you with?

Request a quote Find the right product Place an order Get support on a product

How can we help?

Please enter your information below and we'll be intouch soon.

This field is required

Preferred communication method

Email Phone call

What do you need our team of experts to assist you with?

Request a quote Find the right product Place an order Get support on a product

LabVIEW Idea Exchange

Bring back the State Diagram Editor

When a For Loop is Dropped Around a Node, Use Shift Registers Instead of Auto-Indexed Tunnels for Matching Scalar Inputs/Outputs

Make the LabVIEW "resource" folder a symbolic path

Traits - A better(?) alternative to Interfaces, Mixins, etc.

integrated JSON-Parser

Refresh LabVIEW Menus Programmatically (without restarting LabVIEW) after installing an add-on

Dedicated License for using LabVIEW in Continuous Integration Systems

Add a Package Manager to LabVIEW

Free, General Programming LabVIEW Edition

Allow calling a MATLAB script via path

Add a Control.OwningPane property

Need a Way to Reverse-Replace Packed Project Library with LabVIEW Library

Icon Editor API

OPC UA API as a stand-alone add-on