LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

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!

View All (3)

Support Relative Paths in Build Specs

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.

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 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!

View All (3)

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

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!

View All (3)

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

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!

View All (1)

recursive malleable VIs

There! I said it 😎.

The problem

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

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

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

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

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:

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.

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:

View All (4)

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:

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.

View All (2)

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:

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:

Or for example, 5 rotated copies:

Even in Color mixer simple computations are allowed:

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

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

This is what I mean:

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:

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

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

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.

View All (3)

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.

View All (4)

Replace icon of method overrides

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.

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.

In the drivers (DAGmx,NI-Scope/Fgen,...)

If a value (usually as DBL) enters a config vi, it could be coerced by the driver.

That vi should directly output the actual value.

Most often seen in the Forum: A user declares a non valid DAQmx Timing Sampleclock and wonder why the wfrm(data) is not what he expected.

Yes, RTFM help, you can read the properties after configuration but it would easy to add an output to the config vi with the actual (maybe coerced) value. Making the user avare of that 'feature' (instead of popping an error 😉 )

Should not only cover samplerate , other values like FGEN standard funktion parameters (frequency, Phase), actual range, ...

View All (1)

Often, I have wires already on a block diagram and I want to add a new structure (case, flat sequence, etc.) that utilizes those wires internal to the structure or in some cases passes them completely through the structure. For example, consider needing to implement data flow for a node that has no error input and output, such as when using the Wait (ms) function. To implement data flow when using this function, I might place it in a flat sequence with a single frame and pass an error wire through it as shown:

If the wire already exists and you try to put a new structure over the top of it (using the same example referenced above), you get the following behavior:

It would be really nice if LabVIEW would automatically pass the wire through the structure or at least wire up to the left border when doing this as shown in the following pictures:

The automatic wiring behavior of whether to pass the wire completely through the new structure or to only wire to the left border could be evaluated on a case-by-case basis for each structure (For Loop, While Loop, Case Structure, Event Structure, Flat Sequence, Diagram Disable Structure, Conditional Disable Structure, etc.).

View All (3)

Background

The DAQmx apis allow streaming measurements to TDMS. This supports spanning multiple files (by setting the max file size for individual files in the span set), which is very useful.

We need a similar feature for files we're writing to directly (i.e. not using DAQmx) with the TDMS File functions in LabVIEW.

Note: The main reason we wanting this feature, right now, is that our files are growing quite large and when we run the TDMS Defragement function, we get out of memory errors in RT on cRIO (e.g. if we have 512MB RAM on our cRIO and the TDMS file is around the same size).

Alternatives

We're thinking to do this ourselves, however the TDMS file api does not support checking the file size from a TDMS file reference (and that's a great idea, too).

I'm not totally sure how this would be added to the TDMS file api -- maybe there could be a "TDMS Advanced Spanning" palette with options for configuring and interacting with TDMS spanning.

View All (1)

Currently, the TDMS File api does not offer a way to get the TDMS file size.

Our use case is that we'd like to limit the size of the TDMS files and span them accross multiple individual files (and I've posted an idea suggestion for adding that as a native feature, too). To do this, we need to be able to monitor the TDMS file size, so that we can save/close the current file and then create the next file in the span for continued use (until we hit the size limit again).

View All (1)

I like channel wires for obvious reasons. I like to have modules, which work on their own, coming with their own GUI. This is convenient for developing my modules and testing them. Afterwards I want to be free to insert this module into a bigger project, which takes control of my module.

The channel wire controls on the connector pane can be set optional, but LabVIEW throws an error, when executing a VI with not connected channel wire control. (All branches of a channel wire must be connected to a channel endpoint...)
Please make VIs working with not connected, optional channel wire controls on the connector pane. That way, we can have channel wire based modules, which can run on their own, as a single VI, or can be controlled remotely without any change.

View All (3)

LabVIEW Idea Exchange

Boolean constants should be 16 pixels wide and 16 pixels tall (currently 16 x 14)

Support Relative Paths in Build Specs

Tabbing between front panel elements should be possible at Edit Time

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

Project Explorer "Move to Owner Folder" option in Files view

recursive malleable VIs

Pass a subarray that is only read as a referene, not copy the data

Add "Show Control" option to Event Registration Refnums on Front Panel

Distinctive icon in project explorer for overridden methods

Enable "Replace with..." when dependency not found in project.

Allow simple arithmetical operations on Numerics like embedded Formula String

Allow inserting and removing event handlers in the Register Event Callback node context menu

Replace icon of method overrides

Make Class Mutation History Optional

In the drivers (DAGmx,NI-Scope/Fgen,...) if a value enters a config vi and it could be coerced, the vi should directly output the coerced value

Automatically Pass Existing Wires Through or Wire Up to Newly Placed Structures

Need "TDMS Advanced Spanning" api -- an easy way to span TDMS files and limit individual file size

Need a way to get TDMS File Size from a TDMS File Reference

Optional Channel Wire Control on the Connector Pane

Property Browse Button for Front Panel Right Click Menu and make Browse traverse complete property tree