LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

It would be great if one could mark certain files as having an absolute path so that it is easier to move projects that use a common resource around in a multi developer/station environment.

A project might for example require a shared library or file that is installed by another application into c:\XXXX

Currently, all developers must place their project at the same relative folder depth to the shared resource to avoid linking issues. e.g If Developer A uses c:\Users\Dev A\Project\ then Developer B would need to use c:\Users\Dev B\Project\.. The project would complain about not finding the shared resource if Dev B was to use c:\Users\Dev B\Repos\Project instead for example.

Marking the shared files as having an absolute path would resolve this

For string controls and indicators please add a vertical alignment option. We have applications where we will programmatically change the font size, which requires a string control/indicator to be sized for the largest option. Since there isn't a vertical alignment option, the string is always aligned to the top and it can make the front panel layout look strange.

Other applications have long strings that may be a single line or may be a variable number of multiple lines, but we'd like to be able to center the text vertically. Again, this requires the control/indicator to be sized for the largest option, but all the text is always vertically aligned to the top of the front panel object.

View All (2)

It's always a pleasure to uncover shared memory problems when working with base vi.lib methods that *should* work as preallocated clones and have uninitialized shift registers and then having to establish a chain of vi references to safely call those methods in an application with distributed/parallel threads. It feels like extra work but does fix the problem. It's a major unknown gotcha unless you're already familiar with the vi you are calling.

My most recent hiccup: the NI PID library. I needed two closed loop controllers in actor framework, and was getting very strange timing, setpoint, process variable, and control output crossovers until I realized the stock .vi's had shared memory in the form of uninitialized shift registers (despite being in the context of a pre-allocated actor). Creating references of the vi's I needed and storing them in the actor at launch fixed the problem, but at that point the effort in writing my own PID .vi starts to be a favorable time tradeoff. At least I am able to peek under the hood of the PID library, other aspects of vi.lib... not so much.

Or maybe this is a teaching problem. I haven't come across ways of navigating this issue from official NI documentation, in fact the way I learned I needed to call the PID.vi by-reference was from the forum and rather matter-of-factly. There are a couple of great blogs that cover this issue in detail, so I don't feel alone in my ignorance. Maintaining State Information in LabVIEW Applications, Part 5 - LabVIEW Field Journal Archives | LabVIEW Field Journal Archives

Problem: Currently, the native nodes and VIs that can be used for error manipulation are located in the Dialog & User Interface palette. While manipulating errors can mean generating dialogues, and can influence the User Interface/User Experience, error manipulation is a broader and stand-alone topic.

Solution: Nodes and VIs that are relevant to error handling/error manipulation should be given their own subpalette inside the Programming palette. The new subpalette could be named "Error Handling", "Error Manipulation" or "Errors".

1 (annotated).png

2 (annotated).png

View All (3)

right-click -> Find In Project

I couldn't find this explicitly mentioned here, but it seems related to:

Block diagram references should be 16 pixels tall (currently 19 pixels) - NI Community

Same Height of Unbundle by Name / Terminal / Local Variable - NI Community

Although making changes like this could hurt legacy code, earlier implementation is preferable. Local variables are already the same size as bundles and property nodes, but constants are not. My suggestion is to increase the size of bundle/unbundle elements by one pixel and decrease the size of constants by two pixels by reducing their border thickness. Since numerics require a type indicator, a 1 px border wouldn't compromise recognition. Numeric constant type visualization - NI Community

You cannot currently install MAX as a standalone product- you need to install it along with something else. I need MAX on basically all computers I build my installers for, so I always go into the Additional Installers menu on the Application Builder, then pick (usually) "DAQmx with Configuration Support". Unfortunately, this also means I have to uncheck "Automatically select additional installers" so I can go find the "Configuration Support" item.

I almost always want to let the App Builder pick my additional installers for me, so I will check "Automatically select", then uncheck it, then go check the box for "...with Configuration Support" for one of the items that got automatically selected.

I'd like a box that lets me prefer the "With configuration support" version of whatever I'm building so I can make sure MAX gets installed. For my use, it doesn't seem to matter if I pick "DAQmx with config support", "VISA with config support", etc.

I'd ask to make MAX a standalone installer, but that would require me to uncheck the "automatic" box to add MAX to the list, which doesn't really help. I just want to say "Hey Appbuilder, figure out whatever you need, and ALSO install MAX."

Pro-grade mockup shown below:

View All (2)

It would be really nice if you were able to resize properties dialog boxes for controls, indicators, constants, and other nodes on a front panel or block diagram. Sometimes the information entered in a dialog is larger than the allotted space. Fortunately, in those situations, there is usually a tip strip that shows all of the information rather than just the visible portion of the information, such as shown in the enum properties dialog box picture below. To make all information visible, it would be great if properties dialog box windows were resizable and the contents of the tab control pages automatically scaled with the size of the dialog. It would also be nice if pages containing objects with columns (e.g. multi-column listboxes, etc.) allowed the columns to be resized as depicted in the picture below.

View All (1)

For anyone that has used CAD software, you know how much of a timesaver this feature is. It is very similar to quick drop but relies more on graphical selection than keyboard input (although, these shortcuts often allow text entry as well and have a configurable menu).

For example, pressing the "S" key in SolidWorks pops up a contextual, configurable menu at the current cursor position that allows you to rapidly click on common operations as well as customized shortcuts.

I have my own janky extension to quickdrop that makes a graphical menu present after pressing multiple buttons (ctrl+space, ctrl+q, then one of WASD or a mouse click on the popup .vi front panel), but it would be nice if I didn't have to go through multiple shortcut selections to hit my toolbar-of-target. Said another way, a more extensible quickdrop-like shortcut bar would be nice. Something like the right click and shortcut keypresses for Autodesk Fusion and Solidworks are the inspiration.

LabVIEW for ARM processors

Make Class Mutation History Optional

This topic keeps coming up randomly. A LabVIEW class keeps a mutation history so that it can load older versions of the class. But how often does this actually need to be done? I have never needed it. Many others I have talked with have never needed it. But it often causes problems as projects and histories get large. For reference: Slow Editor Performance with Large LabVIEW Projects Containing Many Classes. The history is also just added bloat to your files (lvclass and any built files that use the lvclass) for something most of us do not need and sometimes causes build errors.

My proposal is to add an option to the class properties to keep the mutation history. It can be enabled by default to keep the current behavior. But allowing me to uncheck this option and then never have to worry about clearing the history again would be well worth it.

View All (4)

Idea Part 1: The menu that appears when right-clicking an input of the Replace Array Subset node should contain Add Input and Remove Input options.

Idea Part 2: The QuickDrop Remove and Rewire tool (Ctrl + Space, Ctrl + Shift + R) should remove unwired inputs of the Replace Array Subset node.

2 (edited).png

This would be similar to the menus of several other well-loved nodes, such as the Build Array node.

Real-world example

The other day I wrote the following code:

Initially all the inputs of the Replace Array Subset node were wired. Then I realised I had made a mistake, and needed to remove the third-last pair of wires. I deleted the wires. So far so good.

I then selected the node and pressed Ctrl + Space, Ctrl + Shift + R to execute the QuickDrop Remove and Rewire tool, in the hope that it would eliminate the unwired input. It didn't. I then right-clicked the input, hoping to manually select Remove Input. That option didn't exist.

The only option I had was to manually disconnect the last four wires and reconnect them one input above, followed by removing the last input by dragging the bottom edge upwards.

Having to manually disconnect and reconnect wires was a little disconcerting. I wondered: what would have happened if I had made a mistake with say the second input, instead of the third-last input? A lot more manual wiring would have had to be redone.

Notes

This idea is deeply related to the following idea: Add "Add Element" and "Remove Element" to the Index Array context menu. However, I arrived at it independently during recent real-world work, as described above.

View All (3)

The Wire Multiple Objects Together QuickDrop tool (Ctrl + W) is extremely useful. However, at the moment it has the following limitation.

The other day I found myself writing code like the following.

1 (edited).png

Naturally I tried using the QuickDrop Ctrl + W tool. However, it produced the result seen below, which is not what I wanted.

2 (edited).png

The Ctrl + W tool wires each source wire to a compatible (coerceable) destination. In the example above it wires to I32 and DBL destinations indiscriminately.

The desired outcome would be achieved if the tool preferred wiring to destinations that match the source data type exactly, before considering other compatible (coercible) destinations. In the example above, the tool should prefer the DBL destinations. It should wire to the DBL destinations first, before considering I32 destinations.

Notes

The example above shows 10 wires being wired between the Index Array node and the Replace Array Subset node. The real-world VIs I was programming the other day required wiring multiple pairs of Index Array and Replace Array Subset nodes, some with as many as 30 wires between them. Wiring them manually was a tedious and time-consuming operation.
This idea is somewhat related to the following idea: Improvement to the QuickDrop Ctrl+W tool: Wire constant to multiple destinations

View All (3)

After working with text-based languages recently, I've become more aware of a very painful flaw in the LabVIEW IDE.

First of all, as software engineer, I like to perform experiments. Make a small change, test it. If it doesn't work, then just use Git to roll back the changes. I've been doing this for years, and with LabVIEW it has been fairly painful. Until recently I didn't realize there was a better way.

Why is it painful? Everytime I use Git to check out a different branch or roll things back, I am forced to close LabVIEW or at least close the project so that LabVIEW detects and loads the new code from disk instead of whatever it has in memory. I lived with that for years because I didn't know any better.

Enter text-based programming and IDEs: VSCode, PyCharm, probably any other modern IDE. I try an experiment, it doesn't work. I roll the changes back in Git and guess what? I don't have to open and close anything! The IDE just automatically detects the file has changed and loads the new file!

When is LabVIEW going to get with the times?

View All (1)

Similar ideas have already been posted but non of them totally hits what I'm missing.

As always - what is the current situation?:
- LabVIEW is installed under "C:\Program Files (x86)\..." - this is a folder where admin rights are usually required to modify it.

- in the named folder the standard VIs are included: vi.lib / user.lib / instr.lib

- my project lays somewhere else - e.g. "C:\myLVProjects\project1", "C:\myLVProjects\project2", ...

- my first project is LabVIEW32 bit, my second is LV64bit,
- one project needs to have the binary code separated from the VI, the other one not
- one projects needs some toolkits from the VI Package manager, the other one not or maybe even incompatible ones to the first project

- one project needs VIs from an additional search path, the other one too but with a different version

long story short:
There are many situations where the configurations of two or more projects conflict with each other. Therefore, switching between two projects can be quite effortful — from adjusting configurations to (de)installing toolkits.

What I like to propose is the following:
Having a new option in the LabVIEW start screen "Create a new development environment".
The only the user has to do is to select a folder on a drive with enough free space.
LabVIEW shall now setup an entire code- and configuration environment. Means it copies vi.lib, user.lib, instruments.lib to this folder. It create a LabVIEW.ini and a link to the exe using this INI. It creates a folder for the compiled object code cache and so on. Installing add-ons from VI package manager shall also be stored in this new folder structure.
And of course, there shall be a place where I can manually add some libraries, my project files and finally also my build results.
If LabVIEW is now started from the named link it only uses the VIs from the environment folder as long relative paths are used (which shall be default).

Again in short: I expect an encapsulated environment that contains everything that is needed to develop one project entirely independent from a second and third project.

View All (5)

LabVIEW Idea Exchange

Add support for Absolute Paths to LabVIEW Projects

The properties page of "boolean array to number" must include the "sign extension mode" setting.

Add vertical alignment property for string controls

Allow file renaming to record changes to capitalization only in Windows

Eliminate uninitialized shift registers from vi.lib

Error functions should be located in a dedicated palette named “Error Handling” (or similar)

right-click -> Find In Project

Match Property Node height to constants

Checkbox to let the App Builder prefer the "x with Configuration Support" to auto-install MAX

Be Able to Resize Properties Dialog Boxes and Certain Contents of Specific Pages

Graphical context menu at mouse pointer, super-duper quick drop

Abortable recompile when closing project

LabVIEW for ARM processors

Make Class Mutation History Optional

Add "Scale Legend Change" as an event for graphs

Block diagram references should be 16 pixels tall (currently 19 pixels)

The Replace Array Subset node right-click menu should contain "Add Element" and "Remove Element" options

Improvement to QuickDrop Ctrl+W tool: Prefer destinations that match source data type exactly

Allow changing branches in Source Code Control without having to close project or exit LabVIEW

Support "Development Environments" / "Development Sand Boxes"