LabVIEW Idea Exchange

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

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

As part of everyday class development, I often want to track down everywhere where certain class data is being used. Would be convenient if there was a shortcut for doing this...perhaps something like:

 

_carl_1-1678141878195.png

 

 

When using the Rearrange Cases window with a Type Specialization Structure, the case list only shows either Declined, Accepted or Ignored. This makes it difficult to know what cases are being reordered. Similar situations occur with a numeric case selector (just a list of numbers) and event cases (dynamic events with the duplicate default wire labels).

 

rearrange-subdiagram.png

This idea is to add the subdiagram label of a case next to each entry in the case list. This would add some context to each item, and make rearranging cases quicker and less error prone.

 

rearrange-subdiagram-labels.png

Alternately (or in addition to the above) would be the ability to preview the contents of the selected case / subdiagram, much like the preview when selecting a dynamic dispatch VI in a class hierarchy. This would be useful for cases with no subdiagram label, or in the case of the type specialization structure, allow visual comparisons of which case should be evaluated in which order.

 

rearrange-subdiagram-labels-preview.png

I'd would find useful to choose at edit time growing direction of an array.

It's used to be from left  to right and/or up to down, but others directions could be usefull (to the right, to the up).

Yes I can do it programmatically, but it's cumbersome and it useless calculus since it could directly done by the graphical engine of the FP.
A very simple example: it would allow for consistent display between a table and its corresponding intensity chart.
But also for any display that needs to be right-to-left (things like number) etc.
Capture d’écran 2026-02-21 104756.jpg

When typing a path in the Terminal (Linux, Windows or macOS) hitting the table key does an auto-complete, this is extremely useful.

 

I wish the Path control and - let's dream - the path constant would behave the same.

 

It's probably only applicable to absolut path values.

 

I've made a QControl that does that, it's a bit basic but it does help, I might post it GitHub if there is interest.

Since the call library function node (3) supports wild-cards it is not clear which DLL file is physically used during runtime. Nevertheless this information can be interesting and important in some cases. Currently there is no way to get this information (1). Therefore I suggest to show the DLL-Path-Output always (2). It shall return the entire path and name of the currently loaded DLL.

 

Andi_S_1-1744715630648.png

 

 

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

Please implicitly consider array index during index / replace elements in In Place Elements Structure if I am starting from Index 0

 

Present method:
image.png

 

Expected method:
image (1).png

 

[admin edit 2021-02-24]: placed images in-line with text and removed them as attachments

Currently, when you right-click -> "Make Type Def" on a control / constant in a library VI, the new unnamed type definition is created outside

the library.

Also, it has the default control icon: raphschru_0-1665514290538.png

instead of a library control icon:       raphschru_4-1665514883384.png

 

This leads to 3 additional tasks:

1. Drag and drop the control inside the library from the project explorer.

2. Edit the control icon to make it have the library control icon (with the horizontal slider glyph).

This is annoying because you need to copy it from another library control icon.

3. Go to the library properties and make "Apply Icon To VIs".

 

Bonus bug: If your new type contains a library-private subtype, the new control magically disappears from the project explorer when you click on it.

 

In comparison, the "Create SubVI" function works perfectly inside a library, i.e. it creates a VI inside the library and with the icon banner.

I think the "Make Type Def" function should behave the same to make library development more coherent and intuitive.

Currently the quickest way to open a typedef is right-click >> Open Type Def.

 

Holding down a modifier key (Ctrl, Alt, Shift, or a combination of these) while double-clicking on an existing typedef constant or terminal (Block Diagram) or control/indicator (Front Panel) would be quicker.

Combined.png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Notes

  • The gesture could open the private data definition (ctl file) of a class when double-clicking on an object constant, terminal, or control/indicator.
  • Opening the typedef for inspection/modification is one of the most common actions when working with typedef clusters and enums.

I often want to find any cube-dropped class constants for a particular class on block diagrams in my project.  But, to the best of my knowledge, there's no easy way to do this. It'd be great if there was an option to find these when right-clicking on a class in the project:

 

class finding option.jpg

Not every bundle is linked to a Typedef. It would be very useful to automatically inherit the names of previously named wires into bundles.

Showing the Current and Proposed behavior for name inheritance in the bundle functionShowing the Current and Proposed behavior for name inheritance in the bundle function

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.

The title says it all.

In 2021 there was excitement about improvements to LVCompare and LVMerge, however there is still no way to compare classes or libraries.

I'm ok with not merging. I know that is a minefield. But at least show me what methods were added, what library or class settings were changed, which VIs moved from private to public and for classes, diff the private data and maybe show changes to the class heirarchy?

I started a discussion here

 

Although the suggestion about using a template is quite nice, I would still like to be able to create a new VI (or sub-VI) from within a project.  I never use the default icon provided by NI.  -- N-E-V-E-R --   That's a personal choice. 

 

So since I never use that icon, the fact that creating a new VI which auto-generates an icon that is never used, renders that feature useless.  Let's see how many users of LabVIEW also find the default icon useless....  (Kudos would be a way to take a poll).

 

A nice feature would be to allow the developer to create her / her own default icon.  The default icon is probably somewhere in the ini file (I have not checked).  One of the Options could be to select if the user wants to use their own default, and if so, browse to the icon or have an editor create one.

 

In my case, when creating a new VI, it ends up with a icon like this:

 

 

 

I would be happy to have a default icon that looks like this:

 

 

 

The idea I am proposing is that developers should be able to have the icon of their choice as a default icon.

 

And may plenty of kudos adorn this thread..  🙂

 

Spoiler
 

 

Big clusters that go beyond the limit of the FP are annoying, especially to resize them automatically and reorder the controls.

 

Here are a couple of improvements that could be made:

  • "Reorder controls in cluster..."
    • Allow user to scroll while re-ordering the controls to have access to all elements instead of having to do it in multiple time.
    • Shortcuts like Escape and Enter should respectively cancel-exit and validate-exit the reordering phase
      These are pretty standard shortcuts and already widely used within the Labview environment
  • "Autosizing"
    • Autosize to "Compact". Where instead of aligning all element vertically or horizontally only, they would be in the "most compact" (to be defined) possible configuration to simplify the access to all info in the cluster.
      For instance compacted in a square way, sorted by class (Booleans/numerics/strings etc.)
      I understand that this one might be more complex, but it would be really helpful in my opinion
      VinnyAstro_3-1705680190345.png
    • Less important (to me): In Edit Mode, in case a cluster is autosized to "none" and some items are hidden outside for whatever reason, the developer should be notified somehow. For instance the same way than for strings 
      VinnyAstro_1-1705678727875.png
    • (In the same case than above, allowing scroll bars could be interesting in some situations.)

 

-Vincent.

It would be useful if a "Keep Text Only" (a.k.a. "Paste Values" or "Use Destination Style") option existed when pasting text into control and indicator labels, captions, or values.

 

Example

Screenshot 1: A GUI element (control or indicator) with a custom, non-default label and value (contents) font style.

1 (edited).png

 

 

 

 

 

 

Screenshot 2: The text "Hello World" was copied (Ctrl + C) from Notepad and pasted (Ctrl + V) in the middle of the label. The newly pasted text is inserted using the default font (Application Font, 15 pt, black). There is no option to paste using the destination font style. The developer now has to waste a few seconds reconfiguring the font. The same result is obtained whenever the text is copied from an external (non-LabVIEW) application, regardless of the application (Notepad, Microsoft Word, Excel).

2.png

 

 

 

 

 

 

 

 

Screenshot 3: The same situation occurs when pasting into a string indicator.

Combined 3 and 4.png

 

 

 

Screenshot 4: In Microsoft Word, it is possible to select the "Keep Text Only" option when pasting text. In the screenshot below, notice how "Hello World" text from the second row obeys the destination style when it is pasted into the first row. A similar functionality exists in Microsoft Excel and is named "Paste Values".

6 (edited).png

 

 

 

 

 

Notes

  • The current behaviour, where the text is pasted using the default font style, can be useful in many (maybe most) situations. I am not asking for the current behaviour to be removed. But it would be useful to have the option to select between the two behaviours.
  • When the text is copied from LabVIEW, the pasted text maintains its source formatting style. This can be useful, but again, it would be useful to be able to select "Keep Text Only" (a.k.a. "Paste Values" or "Use Destination Style").

Thanks!

Every now and then, I stumble upon the following error when trying to use the "Match Regular Expression" node in a inlined/malleable VI:

 

raphschru_0-1727975484834.png

 

If I understand correctly this discussion, this is because it is an XNode, which is currently (or definitively) not supported in inlined VIs.

But further in the discussion, it is said that an exception was added in the compiler to allow inlining the "Error Ring" XNode.

 

My idea is to consider adding the same exception for the "Match Regular Expression" XNode, or make any modification that would result in this node being inlinable.

 

Also, there is nothing in the generated code of the "Match Regular Expression" XNode that prevents inlining!

All it really does is using a CLFN to call function "MatchRegExpEfficient" from the LabVIEW library.

 

Regards,

Raphaël.

I would like to request that public VI properties be added for “Clear indicators when called” and “Auto handle menus at launch,” so these settings can be read and written programmatically.

See this github repository for a more complete proposal and an example implementation that gets us closer to achieving this in LabVIEW.

Some languages like Rust and Zig have a feature called Tagged Enums (or Sum Types) that allow you to create a data type that can be one of a few different types where there is a name associated with each type. In LabVIEW, however, Enums are limited to consecutive numeric integer values -- there's no way to associate a type with each named value.

 

The power of combining an Enum with a data type for each value is that we could potentially use a Case Structure as a switch statement with type assertion and data conversion built in! This would allow us to create robust, type-safe code that is easier to maintain and understand.

 

example_equipment_variant.png

See this github repository for a more complete proposal and an example implementation that gets us closer to achieving this in LabVIEW.