LabVIEW Idea Exchange

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

It would be good if, after adding a custom image to the states (TRUE, FALSE, transitions etc.) or text of of a Boolean control using the Control Editor if there was an option to revert to the standard image rather than having to replace it by overwriting with a second image.

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:

1.png

 

 

 

 

 

 

 

 

 

 

 

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

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

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. 

 

Ryan_Wright__2-1731433895037.png

When adding a file via the project tree to a .lvlib or .lvclass, it is highly likely that the file is located in the same folder as the corresponding .lvclass. For .lvlib, the file is either in the same folder or one level deeper.

When using the right-click menu Add File... on a .lvclass or .lvlib, the Select File to Open dialog should automatically navigate to the folder containing the .lvclass or .lvlib.

Currently, it navigates to the previously used folder instead.

 

Quiztus2_0-1746633483616.png

This should immediately navigate to the folder containing Cell.lvclass.

Quiztus2_2-1746633711942.png

 

 

 

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

Problem: Many native VIs use the Non-reentrant execution reentrancy setting.

 

Solution: The vast majority of native VIs should use the Preallocated clone reentrancy setting.

  • The native VIs that need to use Non-reentrant or Shared clone are few and far between - they should be identified on a case-by-case basis. Their Context Help and/or Detailed Help should explain why they need to be set to Non-reentrant or Shared clone.

The following is a selection of vi.lib VIs that should use Preallocated clone. This selection is meant to serve as a starting point and is not comprehensive.

 

1.png

2.png

3.png

 

Notes:

  • This idea is related to: The reentrancy of new VIs should be "Preallocated clone" . They both argue in favour of using the Preallocated clone setting more.
  • A significant number of native VIs are already configured to use Preallocated clone, which is great.
  • There are curious cases where closely related VIs are set to different reentrancy settings. For example, Color to RGB.vi is rightly using Preallocated clone, while RGB to Color.vi is Non-reentrant. Similarly, Trim Whitespace.vi is rightly Preallocated clone, while Normalize End Of Line.vi - which lives next to it on the String palette - is Non-reentrant.
    • This suggest that the reentrancy setting of some native VIs was chosen haphazardly. This needs to be rectified.
  • The fact that so many native VIs are non-reentrant partly defeats LabVIEW's remarkable ability to create parallel code easily. Loops that are supposed to be parallel and independent are in fact dependent on each other when they use multiple instances of these non-reentrant native VIs. When an application uses multiple instances of these native VIs it is as if there are "hidden semaphores" that are added between the various call locations that call these native VIs. This leads to less performant applications (more CPU cycles, longer execution time, larger EXE compiled code size).

The connector pane is a very useful feature for defining what the parameters for the VI are, therefore how it interacts with its environment.

On the other hand, the development experience did not age well. The 32x32 icon that is divided into smaller areas based on the pattern selected for the VI feel small on today's screens. On top of that most of the functionality is hidden behind the context menu.

This feels like a lacking experience for a crucial feature, but we grow accustomed to it, there we do not complain. But that doesn't mean things cannot be improved.

I would personally prefer a new window being opened when I want to edit the connector pane. The pane itself could be represented with 5x magnification (or even better, user selectable): 160x160 pixels.

On the pane, we could have a dedicated drop down that facilitates the selection of the pattern.

On each connector we could have a border representing its current state: Dynamic dispatch/Required/Recommended/Optional.

Cycling trough these states would be available on left click, for example, and reversing the direction with a shortcut, like ALT + left click.

Connecting the front panel terminals to the connector pane could be done by dragging and dropping to the desired place. To make sure that mistakes do not happen, the drag operations shall not move the front panel controls on the panel itself.

To make the workflow as smooth as possible buttons could be added to Apply the new connector pane, Apply and reorganize the front panel, Reorganize the front panel or Cancel the whole operation.

To make sure that we don't lose existing functionality the CTRL + left click shortcut shall keep the swap terminals functionality (a.k.a.: switcheroo).

Removing controls from the connector pane could be done by the right click, or left click for selecting the terminal and then using the Delete button on the keyboard.

Other operations inside the context menu, like the rotate by 90 degrees, add terminal, remove terminal, etc. could be made available via the menu of the window. I personally use these less, but if there is need for them, then we can discuss how they shall be presented on the window.

 

Since this idea was formulating over a long period of time in my head, but by no means lot of tought put into it, I'm very open to discuss the details. And, by no means the only or best solution to improve the Connector Pane UX.

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.

A number of people, myself included, have found it necessary to parse ISO-8601 time strings into time values. The ISO standard has a lot of options, so a complete solution is pretty time-consuming. It would be nice if the string parsing functions in LabVIEW included a format specifier that allowed parsing of ISO-8601 time strings directly.

This is an idea I've been working on for a while. It's time to let others start evaluating it. 🙂

000.png

001.png

 ^ I included the above for Dmitry Sagatelyan and similar folks who have asked me for these things over the years so they know the mindset to use when evaluating the idea. But it's written up below for LabVIEW users who only know LabVIEW as it stands today (Q3 2024).

002.png

003.png

004.png

005.png

006.png

007.png

 

Feedback and questions welcome. 

Control and indicator references are currently 19 pixels tall. They should be 16 pixels tall. References would then align better with other items which are already 16 pixels tall, such as the Bundle By Name and Unbundle By Name nodes.

 

1 (edited).png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

This idea is inspired by this idea and this idea.

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?

PPLs are a powerful tool in LabVIEW, and when working on larger plug-in based applications, they're almost essential.

 

As a developer, I do my best to not reinvent the wheel. This means building modular libraries for common functionality. Sometimes this includes base classes and interfaces, sometimes this includes functional globals. If I'm calling either of these from a PPL, it's necessary to first put this common code in a PPL too -- otherwise there will be class conflicts or conflicting instances of functional globals.

 

I would love to be able to distribute this common code as a VIPM package to vi.lib so that it's reusable across multiple projects -- however that's simply not possible now. While yes, you can technically put a PPL in vi.lib, you're guaranteed to be met with failure as soon as you build an application that relies on PPLs calling the vi.lib PPLs.

 

There are workarounds to all of this of course, but they all come with compromises, typically maintainability -- such as including a copy of all of your PPLs (and in my case, a library of public VIMs that sits next to each PPL) with every project, while not having access to the common functionality outside of any of these projects.

 

The solution could be as "simple" as this:

  • When PPLs are compiled, they currently expect each dependency to be at an exact relative path.
    • Why not support loading from one of a number of paths similar to, say, how .NET finds DLLs?
      • Search order could be something like: exact relative path, current folder, common LabVIEW folders, and custom (where custom could be defined in build specs)
    • When building a PPL/application that relies on PPLs, if you don't exclude dependencies, this would now allow all of those dependencies to actually find each other.

If we type up a list in a text label we can now (since LabVIEW 2023) right-click on it, select quick change and convert it to a number of different objects (array, enum, boolean etc)...Once you have done however, right-clicking on the result does not offer the quick change option anymore.

 

It would be nice and feel more consistent if the same option was available when right-clicking on the supported objects as well; allowing us to convert those to any of the other options and/or even back to the original list (which would allow you to then edit that list efficiently and then reconvert it). Basically an label/object to object/label quick change, instead of just label to object.

PS. I know there are various quick drop plugins that do parts of this, but this would extend the now in-built function to cover those and more scenarios...

Many times data is generated or transformed using a function or vi with a single output. In those cases the wire name is the one given by the function or VI terminal, but it would far more descriptive if the wire could have a proper name according to is usage in the block diagram. You can attach labels to wires but these are not propagated particularly when used in places like "bundle" or in structures (for, while, etc.). In large diagrams thus it can be difficult sometimes to now what a wire is for.

 

This idea proposes to enable the override of the default name of the wire connected to output terminal to that of the label of the function, in case the label is not empty, for single output function or VI. In a similar fashion to the propagation of labels of constants. This could be automatic (not empty label) or deliberate (for instance, using a tick box in the properties page)

 

This is different from idea Allow-Wire-Labels-to-Dictate-Name-Inheritance-in-Bundles in that it follows the current LabView behavior of the wire name being dependent on labels on constants, and avoids possible conflicts.

 

LabView_idea.png

Hi all,

image processing is not anymore the "tough stuff"/"niche" of the past. Videos are everywhere now, maybe even more than sounds. So functions that handle video should be included in the cross-platform standard labview, at least for the essential functions (reading/writing files with a minimal set of codecs, acquisition of frames through ip or usb for common protocols, conversion between image format for display and processable data). This would attract a lot of young users. It would also jumpstart future developments of labview in the direction of AI.

Thx

VI Analyzer is great tool but can only perform static analysis on VI (as far as I know). It could be nice to run some tests on libraries / classes or even projects files as well to enforce good practices. 

I have a habit of putting an enum with a digital display visible in each of my case structure frames controlled via enum.

 

It has become second nature already. Today I stopped and wondered why we can't simply include a digital representation as an "[X]" appended in the visible selector.

 

So here I am asking for it.

 

Intaris_0-1728572984028.png

 

The asterisk (*) that LabVIEW automatically places in the title bar when a file is modified should be placed first not last so that it can be seen when the window is too narrow to display the whole string, e.g. where other programs like Notepad.exe put it when then text truncation is indicated by an ellipsis (...). Some titles can be much longer when they include lvlib and lvclass contexts.

 

ast.jpg