LabVIEW Idea Exchange

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

Recently LabVIEW has added the following feature: When creating a new wire, double-clicking creates a terminal. This can be an indicator or a control, depending on what was selected. If the wire was started from a data sink (a structure tunnel or a subVI or node input terminal), holding down the Ctrl key while double-clicking creates a constant. This is very useful and saves time. Kudos!

 

When working with cluster wires, it would be useful if an Unbundle By Name node could be created by:

1. Start creating a new cluster wire or wire branch

2. Hold down a modifier key (Ctrl, Alt, Shift, or a combination thereof) and double-click

 

Step 1: Start creating a cluster wire

1 (edited).png

 

 

 

 

 

 

 

 

 

 

 

Step 2 - current behaviour: double-clicking creates a terminal. This is useful. Holding modifier keys down (Ctrl, Alt, Shift) does not alter the behaviour.

2 (edited).png

 

 

 

 

 

 

 

 

 

 

 

Step 2 - desired behaviour: Holding modifier key + double-click creates Unbundle By Name node

3 (edited).png

 

 

 

 

 

 

 

 

 

 

 

Notes

  • Creating UBN nodes is a common, repetitive action when working with clusters. This gesture would save time.
  • The screenshots above show a cluster wire being created starting from a control terminal. The gesture should, of course, work regardless of which object the wire branch was started from (e.g. tunnel, subVI output terminal, etc).
  • Perhaps the idea can be expanded to creating Bundle By Name nodes. Perhaps one modifier key (e.g. Ctrl) would create a UBN node, while another key (e.g. Alt) would create a BBN node.

Problem: There are currently two ways of moving or transferring a VI or CTL from one lvlib or lvclass to another (or from having no owner to having an owner).

Method 1: Drag-and-Drop. Select the VI or CTL, drag to desired lvlib or lvclass, drop in desired location.

  • This works well in small to medium projects, and will probably remain the quickest and most common way of moving a item from one owner to another.
  • This does not work well in large projects, which can have dozens or hundreds of classes and libraries, sometimes deeply nested within complex virtual folder structures (for good reason). In this situation dragging the item can take a long time, especially when the destination lvlib or lvclass is "off the screen" and slowly scrolling through the project becomes necessary. This is done by hovering the mouse in just the right region in the top or bottom of the Project Explorer. This can be tedious and wastes time.

Method 2: Remove and Re-add. Select the VI or CTL, remove it from its current owner by right-click >> "Remove from Library" or by pressing Delete key, select destination lvlib or lvclass, right-click >> Add >> File... , then select the file on disk (this last step can take time in large projects with large folder structures).

  • This can be quicker than method 1 in large projects.
  • This method is technically a workaround. It does not directly transfer ownership of the item.

Note: Both methods usually now also require moving the file on disk to the new owner's folder location. This can be done using the Project Explorer Files view, but is an additional step that takes time. It's also possible to simply forget to move the file on disk (best practice is not encouraged). 

 

Solution:

  • Right-click the VI or CTL, select Move to... option
  • A window appears. This window may use a Combo Box or a Listbox to display a list of all the lvlibs and lvclasses available in the project.
  • The user selects the desired destination owner and presses OK.
  • The item is moved to the destination library.

1 (edited).png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Nice-to-haves

  • The Move to... window may contain buttons or other mechanisms (e.g. clickable datagrid headers) that enable the user to sort the libraries and classes in the project by name in alphabetical or inverse alphabetical order, and to filter: display only lvlibs, display only classes.
  • When the selected VI or CTL is initially part of a lvlib or lvclass, that owner will be omitted from the list displayed in the Move to... window.
  • The Move to... window could contain a tickbox named "Also move on disk to new owner's folder?" or similar. When this is ticked, the item is also moved on disk to the folder of the new owner. This would remove the need to use the Files view to move the item on disk (would save time) and would help encourage a best practice (member items should be located in the same folder as their owner).
  • The Move to... option should be available when multiple items are selected. The items may initially be owned by the same owner, or may be owned by different initial owners.

This idea is inspired by the "Project Explorer "Move to Owner Folder" option in Files view" idea.

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.

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!

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.

In a recent version of LabVIEW the height of Unbundle By Name and Bundle By Name elements, Local Variables and Global Variables was standardised to 16 pixels. This was a welcome improvement. (I'm fairly sure that the improvement was suggested by a LabVIEW Idea. I would have liked to link to that idea here but unfortunately I can't find it right now.)

 

The size of Boolean constants is currently 16 pixels (width) x 14 pixels (height). This should be standardised to 16 pixels x 16 pixels. A vertical stack of Boolean constants would better align with a stack of local variables, global variables, or UBN/BBN elements. They would also align better with the default sized LabVIEW grid (16 x 16 grid).

1 (annotated).png

 

 

 

 

 

 

 

 

Thanks!

At present, build paths in build specs are stored as absolute paths, unless the path happens to be in the same folder as the project. Relative paths that are a level or more up from the project folder are not supported. Modifying the XML directly does not support relative paths either.

 

_carl_0-1711030809967.png

 

When working on multi-developer projects, where source control root folders may be different, this can be a serious annoyance.  One of the better workarounds at the moment is to build to a non-desired relative path (within the project folder) and then to run a post-build action to move the generated files to the desired location.

 

But it shouldn't have to be this way -- relative paths should just work.  (They are supported elsewhere in projects, such as with dependencies.)

 

(Note: this is the follow-up to a post on the LabVIEW forum about the same issue.)

Suppose that in the scenario seen below we would like to merge the error out terminal of VI 2.vi back into the main error wire. This is, of course, a common programming pattern.

1.png

 

 

 

 

 

 

 

 

 

Currently we would need to insert a Merge Errors node into the existing wire (Pressing Ctrl + Space, typing "erg", then Ctrl + I is probably the quickest way to do this), then wire the error wire as desired. Currently creating a wire from the error out terminal and ending that wire onto the existing error wire results in broken wires, as seen below.

2.png

 

 

 

 

 

 

 

 

 

It would be useful to have an option that specifies that a Merge Errors node would automatically be inserted in this case. That option could be named something like "Automatically insert the Merge Errors node when suitable", and could be located in the Tools >> Options... menu alongside options such as "Place structures with Auto Grow enabled" or "Auto-insert Feedback Node in cycles".

 

When the "Automatically insert the Merge Errors node when suitable" option is ticked, a Merge Errors node would automatically be inserted in the scenario described earlier, as seen below. This would save the few seconds required to execute the Ctrl + Space, "erg", Ctrl + I sequence.

3.png

 

 

 

 

 

 

 

 

 

 

Notes

  • I would be happy if the default value of the "Automatically insert the Merge Errors node when suitable" option would be unticked, which would maintain the current default behaviour.
  • Even if the option would be ticked (enabled) by default, I think it would still make sense from a usability point of view. I suspect that the number of times people intentionally use this feature would be greater than the number of times that people wire error wires together by mistake and would wish for the wires to be broken.

Thanks!

Suppose a front panel contains the three elements seen below, with the first one being selected.

1 (edited).png

 

 

 

 

 

 

 

 

 

 

 

 

In the situation above currently pressing Tab does nothing. It would be useful if, instead, pressing Tab would cycle the element selection to the next element in the tabbing order, as seen below.

2 (edited).png

 

 

 

 

 

 

 

 

 

 

 

 

If Tab was pressed again, it would cycle to the next element in the tabbing order, as seen below. And so on.

3 (edited).png

 

 

 

 

 

 

 

 

 

 

 

 

Notes

  • This idea would speed up development by enabling us to cycle through element selection without using the mouse.
  • When used in conjunction with the F2 idea, this would enable us to use Tab + F2 combinations to quickly cycle through elements and rename their labels and/or captions.
  • This idea could be extended to terminals on the block diagram. Suppose a terminal is selected on the block diagram, pressing tab would navigate to another terminal on the block diagram.
  • I'm aware that currently it is possible to use Tab or Shift+Tab to cycle between elements forwards or backwards when the VI is in Run Mode (Ctrl + M). While that is useful, this idea asks for more.

Thanks!

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!

The Project Explorer Files view already contains the useful "Move on Disk..." option. It would be useful if, when a VI or CTL is owned by a lvclass or lvlib, an option named "Move to Owner Folder" (or similar) existed. This option would move the selected file to the folder that contains the lvclass or lvlib that owns that file. This action would be equivalent to using the "Move on Disk..." option, but would save the user from navigating the (potentially large) folder structure to find the right folder. In short, it would save a few seconds and would help ensure consistency. It would also encourage the best practice of storing owned VIs and CTLs in the same folder as their owner lvlib or lvclass (actions that are easy to do are performed more often).

 

For example

Screenshot 1: A project that contains two libraries

1.png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Screenshot 2: In the Items view, the mouse was used to drag C.vi from Library 1.lvlib to Library 2.lvlib

2 (edited).png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Screenshot 3: Typically, I would now press Ctrl + E to switch to the Files view, right-click the file, and select "Move on Disk...".

3 (edited).png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Notes

  • It would be great if the "Move to Owner Folder" menu item was also available when multiple items that are owned by the same owner are selected.
  • A related idea: It would be useful if, when using the Items view to move an item from an owner to another, LabVIEW would pop up a dialogue message similar to the following "Would you also like to move the file on disk to folder <insert here the folder path of the new owner>?". The dialogue would contain Yes and No buttons. This would save the user from having to switch to the Files view altogether.

Thanks!

There! I said it 😎.

 

The problem

 

Here's a simple vim that replaces ',' with '.' in a string (half the world uses ',' as decimal separator):

wiebeCARYA_0-1710762498195.png

To support 1D arrays we have to (ouch) duplicate the code:

wiebeCARYA_1-1710762534293.png

To support 2D arrays, we need yet another duplicate:

wiebeCARYA_2-1710762568649.png

So, to support scalars, 1D arrays and 2D arrays, we get:

wiebeCARYA_3-1710762615934.png

I don't advocate nD (n>2) arrays, but duplicate code is undesirable. And this is just a trivial example.

 

You typically run into the lack of malleable recursion when you do serialization (to\from string, (un)flattening, to\from variant) very quickly.

 

Recursive malleable VIs

 

If we could call the vim in the .vim, we wouldn't have any duplication:

wiebeCARYA_4-1710762720925.png

 

So what's stopping recursive malleable VIs?

 

Well, there's a 'minor' issue of infinite recursion.

 

There are 2 relatively simple ways to deal with this.

 

1) Limit the nesting level and break caller if it's reached.

 

We don't need 9D arrays, and certainly not 256D arrays.

 

2) Check if the .vim prototype has been used before and break caller if it is.

 

Let's say the .vim "V" is called with a string 'A'. V" turns 'A' into an array, that in a for loop call 'V' again.

 

That would be a use case for normal VI recursion (calls, managed at runtime), but it shouldn't be possible with malleable recursion (inlined code).

 

 

Spoiler

At least not at first. The compiler could inline each prototype and when called repetitively, use normal recursion. But that would be next level, and maybe not even desirable.

wiebeCARYA_6-1710763869721.png

The scalar string input is simply not a stable input for this malleable VI. It will always result in infinite recursive compiled code. So, this should break the caller.

 

Of course, it should be perfectly legal to have a disabled type specialization case that calls the same prototype. As long as it's not actually compiled, that's perfectly valid:

wiebeCARYA_8-1710764136302.png

When a subarray is created, the data is copied from the origin-array.

 

The LabVIEW Compiler does not recognise if the subarray data is then only read.

It would be a major improvement for memory and even CPU usage if the compiler recognised that some part of the array is only read and pass only a reference to that part of the array in the memory.

 

When in the front panel, most LabVIEW data types that wrap other data (such as arrays, DVRs, maps, sets, user events, etc.) allow you to directly view and modify the wrapped data.  For some of these data types it is not the default behavior, but it is available if to right-click on the control and select "Show Control...".

 

For illustrative purposes:

_carl_0-1709850594929.png

In all but one of the cases above, I can see that the underlying data type is a boolean, and I can swap this out easily for any other data of my choosing, such as a typedef.

 

The one exception: event registration refnums.  There is no "Show Control" option, and from the front panel it is impossible to update this underlying data type. Instead, you have to create a new event registration refnum in the block diagram. I do find that this makes it difficult to work with, maintain, and debug event registration refnums when maintained in class data.

 

The request: treat event registration refnums like any other data container type, and expose a "Show Control" option that makes the underlying data type accessible in front panels.

As the number of classes in a project increases it gets harder and  harder to figure out which methods in a class are overridden because you need to scroll up and down to compare the methods listed under each class. A distinctive glyph or icon in the project explorer window would be very helpful. I understand that there are workarounds like creating an override virtual folder and moving the overridden vis inside it or right clicking the class and opening the "VI for Override" window and checking if the vi is listed. However, a distinctive icon would drastically increase code readability.

reza0146_0-1709836120851.png

 

When refactoring code, I often find myself in a situation where I've broken dependencies. Maybe it's a name change, or a library path change. This is precisely when I'm most in need of the ability to just replace the missing file (be it a VI, control, class, or PPL).  Yet this is when LabVIEW decides that nope, it can't be that easy:

 

_carl_1-1709776637528.png

 

Instead you have to track down every instance and manually swap them out.

 

The request: allow us to replace missing files using the "Replace with..." option.

 

Many of us using graphical programming for scientific applications, where we dealing with numbers, measurements, etc.

How often we grab to Windows Calculator to compute simple equations?

What about ability to enter something like 3,75*2,8 into any constant or control (in principle everywhere where we can put numbers) and then get computation result in this place:

Screenshot 2024-03-06 09.16.22.png

In the past I've worked in desktop publishing industry and using the software called "Macromedia Freehand MX", and that was really "killer feature", which saves huge amount of time.

 

This is how it works:

resize.gif

Or for example, 5 rotated copies:

rotate.gif

Even in Color mixer simple computations are allowed:

mixer.gif

Everywhere where I can put some numbers, in any dialog:

guides.gif

So, my suggestion to have the same in every numeric control or constant.

 

This is what I mean:

numeric1.gif

So, it should be allowed to enter here something like "3*5" or "42+3*5" 

As MVP suggested to have the only (at least) base operations *, /, +, -, also combined as shown above, but may be "advanced" support (like fully offered by Formula String) is also not so bad, why not:

numeric2.gif

Anyway it should work everywhere, including constants on the Block Diagrams:

numeric3.gif

Also, for example, on Resize Objects Dialog:

Screenshot 2024-03-06 11.20.04.png

Or even in the Settings (in general everywhere for any numeric field across whole LabVIEW):

options.png

 

And also in Run-Time, of course, not only in Development Environment.

 

If you think that "always enabled" feature will be annoying, then I can suggest to make this optionally per Control/Constant Option:

Screenshot 2024-03-06 11.31.54.png

Or may be as global setting in the Options.

The current register event callback node is allowing an easy way to handle ActiveX and .Net Framework events. This node is also very similar in appearance to the property nodes, yet it does not have an insert (Add Element) or remove (Remove Element) function available in the context menu. Since the property nodes, and also the named (un)bundle nodes are having this implemented, I think it would be nice to have these easy to access functions instead or having to grow the node, change all the elements below the one that we want to insert and rewire everything.

One downside of this idea is, that it will throw the wires a little further away than the upper mentioned named (un)bundle and property nodes do, since it is a 3 terminal height element.

Similar to the library banner functionality, I find myself wanting to replace the icon of method overrides with the icon in the parent. This is done automatically for new overrides, but I haven't seen any way to apply a new parent method icon to its overrides once they exist already.

 

I imagine this working like the library banner: whenever the VI icon of a dynamic dispatch VI with overrides in memory is changed a dialog could pop up and ask if you want to apply it to the children as if the icon had been freshly generated the way it is for new overrides.

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.