LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Enum History Probe Improvement

View All (2)

I would like it if LabVIEW offered the option of creating Block-Diagram-Only VIs. These VIs would be just like regular VIs, but without the Front Panel window.

BD-Only VIs would be beneficial because:

They would remove the need to spend a few seconds tidying up the Front Panel of every VI. In a large application most VIs do not have a user-facing GUI. Most of the time tidying up the FP is "busywork" that slows down the developer. (The alternative: creating BD code without ever looking at the FP results in the FP being a mess, which is even more undesirable than wasting a few seconds to tidy the FP up.)
They would reduce the developer workload, thus making developers faster.
They would reduce the surface-area of the codebase.
They would replicate functionality that exists in all text-based languages where creating functions or methods does not involve "touching" a GUI.

BD-Only VIs would be my default choice for small, low-level VIs that serve as subVIs deep inside my application. For example, does a VI that takes "a", "b", and "c" as inputs, and outputs "3D Distance = sqrt(a^2 + b^2 + c^2)", really need a GUI (the Front Panel)? Do most class accessor VIs really need a GUI (the Front Panel)?

Notes

I realise that implementing BD-Only VIs is not trivial. But I believe that the benefits would far outweigh the implementation cost.
The Connector Pane functionality would have to be implemented in the Block Diagram. This has already been suggested by CaseyM in a comment to his popular Make the default behavior of opening a VI open ONLY the block diagram idea: "Hell, you could even add the connector pane wiring functionality to the BD - then I'd have even less reason to go to the FP on most VIs."
Steen Schmidt has aluded to the need for BD-Only VIs in a comment from 2014 to the popular Allow ONLY the Block Diagram to be opened Without Front Panel idea: "But this idea of Jack's here is about being able to have the BD open only, and leave the FP closed. Not about having VIs without FP at all (that discussion is a totally separate one, which we will have hammered out in due time :-)."
I would be happy if, for technical reasons, BD-Only VIs would use a dedicated file extension, for example ".vibd", similar to how malleable VIs use the dedicated file extension ".vim".
It would be ideal if BD-only VIs could be converted to regular VIs, and vice-versa. But I would be happy if, for technical reasons, this is not possible or too difficult to implement.

Thanks!

View All (4)

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)

Right now, there's no way to easily open show a LabVIEW project file in the "native operating system file explorer" on Linux (for me on Ubuntu, that's the the Gnome "Files" Nautilus app and I can easily open a folder from a terminal/shell by executing an `open .` command).

Side Note: In VS Code (as described in the documentation), you can open to the location of a file or folder in the native operating system file explorer by right-clicking on a file or folder and selecting Reveal in File Explorer on Windows, Reveal in Finder on macOS, or Open Containing Folder on Linux.

Let's please add this to LabVIEW for Linux! 🙂

View All (1)

Auto-expanding nodes

Say you have new errors you want to merge into an existing structure. You have to expand the merge error, then bring the new error to the merge. Here is what I'm proposing.

Start wiring the new error, then click on the merge error node.

LabVIEW expands and connects the error wire

This would also be nice for any expandable node like build array, concatenate strings

BA and Cat.png

Bonus points idea, but might cause more polarization so don't let the entire idea hinge on this. Clicking on an existing unbroken wire can insert the node.

The existing UI behavior just wires a new source into an existing wire, which really only breaks the wire. I'm not sure the above behavior would take capabilities away from the user. For build array to work this way, it would have to detect if the singleton was the same type as the array wire you were clicking on. This is a bit more iffy in my mind.

View All (1)

I was almost certain this idea already existed, but I couldn't find it. If it does exist, please cross-link and disable this idea.

There are a coupe of functions which could really benefit from backwards propagation of data types. By this, I mean the ability to change a functions input datatypes based on a wired output.

Some functions already do this (like Variant to Data). However, that implementation has its flaws (as far as I can tell, the backwards propagation only works if wired to an indicator terminal).

Functions like Select, Obtain Queue, and Create User Event would benefit greatly from this (as well as many others).

Essentially, what I would like is a Type Specialization Structure that works backwards.

To implement this using today's technology, I guess we could create express VIs which have scripting function calls whenever the outputs are wired??? But that's janky and not practical for everyday development.

Simple example of Select

Here's a previous idea I posted, for this post, I'm proposing a generalized version of what I suggested there.

Sidenote: here's a plugin I created to make working with Select easier.

The help page, that is supposed to provide a starting point for the developers on creating readable, high quality code in LabVIEW seems to be unchanged for quite some time: LabVIEW Style Checklist - NI.

At different workplaces (including NI) and different teams I have seen different implementations of such guides, many of which included extra "rules".

One such example is the file naming convention:

Using spaces for separating words.
Using Libraries to namespace VIs instead of including the noun in every related VI.

These are the most prominent examples I can come up with from the top of my head, but I'm sure that there are more.

I'm curious if an updated version exists somewhere that could be used to replace the above refenced help page?

If there is not, then I think could we collect some ideas here for updating this document.

View All (2)

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)

Excel displays the number of selected cells.

1 (edited).png

VS Code displays the number of selected characters.

5 (edited).png

LabVIEW should display the number of selected items in the Project Explorer.

2 (edited).png

LabVIEW should also display the number of selected items on the block diagram and the front panel.

4 (edited).png

Notes

In the Project Explorer the functionality would be useful to count/monitor/audit the number of VIs and CTLs in a lvclass, lvlib, or in a virtual folder of these owners, etc. It would be nice to know at a glance "oh, there are 12 public VIs in this class".
The block diagram count functionality can become more useful in large projects and VIs. For example, I recently edited the block diagram of a VI in a DQMH-based project. The project contains 16 DQMH modules at the moment (more to be added). I wanted to check that the VI I was editing was calling the Start Module.vi public VI of each of the 16 modules (wanted to check that the VI would launch all DQMH modules). The only way to do this was to "manually" count the VIs on the block diagram. Selecting them and LabVIEW displaying "Count: 16" would have been easier.
In the block diagram the information displayed by LabVIEW could be more nuanced. For example, it could display the total number of items selected (subVIs, nodes, property nodes, etc), but also a breakdown based on item type: number of VIs, number of nodes, number of property nodes, etc. All these selection stats may occupy too much space for all to be displayed at once. Perhaps they could be displayed in an element that, when clicked, expands to present all the information.
The block diagram and front panel count functionality would enable programmers to quickly estimate the complexity of a VI. Pressing Ctrl + A on a block diagram to select all items, then looking at the selection stats would reveal the relative complexity of that VI.
If a whole structure is selected on the block diagram, then the count should return the count of all items contained in the diagram, not just the items displayed to the user. For example, if a case structure is selected, the number of items contained in all cases should be displayed.

Thanks

View All (3)

If I have a standard VI that's hung, I can highlight execution, and then drill into the hung VI (reentrant or not) to see what's going on:

But...if it's a class override method, I can't do this:

(There is technically an exception: If the override is not reentrant, and you guess the correct override in the popup, then you can debug it.)

This experience would be so much better if I could drill into the overrides seamlessly, without being prompted for which override to look at, and with the correct runtime instance of the override popping up. This is the kind of thing where, on complex projects, this improved debugging could literally save me hours on some bugs.

Some very useful properties for UI manipulation on graphs and charts do not exist. This makes it impossible to make very dynamic UI's with variable number of plots or dynamic resizing in panels.

It is possible to set Legend.number of plots and Legend position. It is not possible to set:

Graph palette, scale legend or cursor legend position. This makes resizing graphs very limiting.

Further, it is possible to programmatically create a custom legend. However it is not possible with cursors because there is no property available to get the current cursor values. Please can we have cursor.values[] and cursor.legend.number of rows

View All (4)

I just realized that when creating an interface you cannot create property node folders.

You can see from the pictures below that option is missing from interfaces.

You can also see from that screenshot that it is possible to have property folders in interfaces and they work just fine. You have to edit the xml to do that, but it works. So it is implemented, it is just removed from the IDE.

Now I talked to Darren and he seemed to think the original reasoning was "Well property nodes are for storing things in the class private data and there is no private data with an interface, so you don't need them." I can't really argue with that logic, however, there are times when an existing class uses a property node and you want to create an interface that includes that method. For example you may have multiple instruments that have a VISA ref property. You currently can't create an interface with that "write VISA ref" VI (without editing the xml.) If you create a method with the same name/conn pane and it is not in a property folder, the compiler complains. Now you could just go back and edit the original class and remove the property node and just use a regular method. However then you break every piece of calling code that is using a property node.

Here is a use case, which I think is fairly common - it happens to me a lot:

I inherit some code. It is using some particular instrument (Oscope, DMM doesn't matter) They want to support another similar instrument (maybe newer version of the DMM).

The instrument code is wrapped in a class. Great. As a first step, I can refactor. I can create an interface that has all the same methods and make the code rely on the interface. If it is a class wrapped in a DQMH module, all I have to do is replace the object in the Shift register with the interface and somewhere set the concrete class in the initialize. It all works exactly the same as before, but now I have an interface.

Then I create another class that implements that interface and add some logic to pick which one - some kind of factory. Done. I've made very minimal changes to the existing code and it now supports a different instrument. This is the holy grail of OOP. I create a new class and just inject it and everything works.

Not so fast. NI has decided I shouldn't be able to do this if the class uses a property node (oh no!) why? I should be able to have 2 classes that both have the same property. Sure the data's not getting stored in the interface, but what does that matter?

It does matter to the compiler. If I want to do what I proposed above and the original developer used property nodes anywhere this doesn't work directly. I have to either do some xml hack on the interface or I have to replace all the property nodes in the calling code with subvi calls and then go edit the class and remove the property folders. Why?

It seems like all that is needed is enabling the right click menu, because if you manually edit the xml, it all works. That is already implemented for classes, so I imagine the fix would be rather simple.

View All (1)

We need a “modal when called” behavior where the VI is NOT modal when the VI is not currently running (being called). Otherwise, accidentally opening the VI during development while the main VI is running will make it so you can’t interact with any other front panels, block diagrams, or any other LabVIEW windows; and you’re stuck — you have to kill LabVIEW from task manager or cmd.exe (taskkill /f /im LabVIEW.exe)

My work-around is to add this little snippet of code that uses a Floating behavior in development and a Modal behavior in a built application (EXE).

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

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.

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.

View All (3)

When running NI web server, the domain URL of the server will always redirect to the NI web server (or Systemlink) login page. Every Labview-built web application/webservice has a name and therefore must have a path (like: https://example.com/mywebapp)

I would like to be able to set a default redirect in the NI Web Server configuration to redirect the domain url to the default web application on that server.

It can probably be done in some Apache config file, but those a really managed by the NI web server configuration and are easily corrupted. My forum post about this issue has not yet been answered.

View All (5)

"Find Callers" for Class Data

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