LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Benefits

Removes the need to use a separate Color Box Constant and Bundle By Name node when writing to VI server properties that take the LvFontTypeDef.ctl as an input.
More intuitive representation (a colour displayed as a visual colour rather than just a number).

Notes

The underlying data type of the Color Box is U32. Hopefully this means that this change would be "transparent" to the compiler. The change would affect only the visual appearance and would improve the human interaction with this typedef cluster.

View All (2)

The LabVIEW Icon Editor plays a central role in creating graphical icons for VIs.

Yet, it has some quirks that would be great to address, such as fixing a few issues affecting users on Linux.

Because the Icon Editor is written in LabVIEW, many LabVIEW users could actually help fix issues and suggest improvements more directly, if the Icon Editor source code were hosted on GitHub. This would allow people to submit issues and feature requests (even in the form of Pull Requests with the fixed/improved code).

By transitioning the Icon Editor to GitHub, NI could establish a process that allows for the incorporation of community improvements into the official LabVIEW releases. This would improve quality and allow for more and better feedback from the community.

Note that NI has historically shared the Icon Editor code with each new LabVIEW release (here in the NI’s LabVIEW discussion forums). However, there hasn’t ever been an effective mechanism for the community to contribute back their fixes and feature suggestions. So, hopefully this would only take incremental effort for exponential gains!

View All (1)

Problem

Maps auto-index just like an Array of Clusters, but the tunnels do not offer the same right-click options. It is not recognised as a cluster:

Right clicking an array of clusters auto-indexing tunnel

Right clicking a map auto-indexing tunnel

Hence it is not so easy to place an Unbundle node.

Solution

I would love LabVIEW to treat right-clicking on a Map's auto-Index tunnel in the same way as it does right-clicking on that of an Array of Clusters, so then it is easy to choose the appropriate Unbundle node.

View All (3)

View All (2)

LV2021 has a new "feature" called "Auto-Routing" (this is not Auto-Wiring, which can be deactivated in the options!). Auto-Routing moves wires around if you touch for example Sub-VIs.

Especially in compact VIs this function is a disaster right now. Sometimes for example wires will go "through" Sub-VIs so that an output leaves the Sub-VI at the wrong side resulting in a VI which is terrible to read:

1. Original Snippet of a VI:

2. Same snippet, I just moved the "Get Variant Attribute Function" by one pixel to the right:

First we thought this is a bug, but the support told us it is a feature. But please: Let us deactivate this "function" in the options. I have colleagues telling me they would stop using LabVIEW if this remains as it is right now.

There are several great ideas on this Idea Exchange that were marked as Completed because they were implemented in NXG.

Although arguments could probably have previously been made that this wasn't really "complete" for most requestors, it was reasonable given the idea that NXG would replace LabVIEW 202x.

Given the updated fate of NXG, can these posts all be reevaluated and marked as either New or In Development, as appropriate?

If the evaluation is too effort-intensive, can they all be marked as New again?

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.)

View All (2)

Taskbar of opened VI

Most of the time I have quite a lot VIs (Blockdiagrams and Frontpanels) opened. Therefore my Windows Taskbar is full of files and it is very annoying to quickly swap between them since they are not identified via their names, only as 'Frontpanel ...' or 'Blockdiagra...'.

Most classic programming IDEs keep track of opened files using a taskbar (see picture)

It would also be nice to sort the opened VIs between Block and Frontpanel.

Fixed examples are: Exclipse, Netbeans, Visual Studio Code

Dynamic taskbar (can be positioned anywhere on screen as overlay): Gimp

Set a target version when saving

I'd like the ability to set the target version of LabVIEW when I use the Save, Save All, etc commands.

A similar idea exists here: LabVIEW Compatibility Modes, but that idea focuses on retaining the existing version of a VI when it is opened, assuming no newer-LV-version-requiring changes are made.

I'd like to (additionally/instead) be able to choose from a dialog box/enum/etc which version my saves should target (older than the current version of LabVIEW I'm using).

Essentially, this is just the Save for Previous as a possible default save (with the default target being the current version). Since you can't Save for Previous on top of the code you have in memory, I think it would be nice to have this option.

View All (1)

Say I have a VI with an arithmetic function: add, subtract, negate, etc...

I would like the ability to programmatically change the output configuration of the function through scripting. Right now (as I understand) you can only read the datatype of the output terminal but not set it. I specifically want to be able to control the fixed-point configuration of the output of these functions through VI Scripting.

[admin edit]: I added an attachment to this post pertaining to the first comment on the thread (since comments cannot contain attachments).

View All (1)

I am not happy when I inherit legacy code where VIs have inconsistent alignment grid options, as shown in the image below. Inconsistent Alignment Grids.jpg

My team has coding standards we follow, and those standards include alignment grid options. It is labor-intensive to change alignment grid options on legacy VIs because you have to do it by hand, and clicks quickly add up. I wish I could automate such changes.

I’d like to see a few new properties to expose settings available in the editor, as shown below. Alignment Grid Property Nodes.jpg

These properties need to support both read and write.

View All (1)

Change the Path Type function output from a signed 16-bit integer to a text ring or enum to aid immediate readability of code and save having to look at the help file:

The Path Type function returns a signed 16-bit integer indicating the following 3 types of paths.

0: Absolute path

1: Relative path

2: <Not A Path>

Unhelpful context help.

Text ring would have the least impact on existing primatives: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Path-Type-Function-needs-another-return-for-an-empty-path/idc-p/2588549/highlight/true#M25086

Error Ring accepting Enum

View All (3)

NXG home edition

I just ran into a situation today where I had a case structure with approximately 64 frames in it, 48 of which I wanted to remove.

The method of right-click the selector, select "Remove Case" (This step is right beside the "Insert Case" which is frustrating), repeat 48 times while the mouse is wandering all over the screen between the case selector and the menu selection..... cue carpal tunnel problems.

I really wished I could just either use the "delete" and "insert" buttons to mimic the appropriate menu selections

-OR-

Be able to select multiple cases from the "Rearrange cases" window and select "Delete".

LabVIEW Idea Exchange

The "Color" field of LvFontTypeDef.ctl should be replaced with a Color Box

Move the LabVIEW Icon Editor to GitHub (and Facilitate Community Contributions)

Recognise Map Auto Index Tunnel as Cluster

The LabVIEW 2021 welcome screen should display the version

LV2021: Deactivate Wire Auto-Routing

Reevaluate Ideas marked as "Completed" if the reason is implemented in NXG

Allow calling a MATLAB script via path

Rearrange Cases should auto-select current case

Taskbar of opened VI

Set a target version when saving

Improve Item Selection for Enums and Rings with Large Lists

Give VI Scripting write access to modify function output configurations/datatypes

When Quick Drop inserts a division operator: wire up the numerator, and leave the denominator unwired.

Programmatic Control of Grid Alignment Properties

Path Type Function - Return text ring or enum instead of plain I16

Error Ring accepting Enum

Inline possible on 'Database Variant To Data' for malleable VIs

NXG home edition

Fix Timed Loop termination terminal

Easier handling of Case structures