LabVIEW Idea Exchange

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

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

 

Jim_Kring_0-1715216735950.png

 

Jim_Kring_2-1715216863669.png

 

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

Oftentimes, rearranging or reordering a Bundle by Name or Unbundle by Name for clusters can yield fewer wire crossings. For instance, below, wire crossings can be eliminated by moving "Timestamp" to the bottom of the Unbundle and "Value" second to bottom on the Bundle:

 

20985iEE7ABCE2AA5DD1B3

 

The current process of moving one of these elements:

  1. Increase the size of the node using the Resize Handles on top or bottom, or select "Add Element" from Context Menu (and hope you remember if it adds and element below or above the cell you are clicking on!
  2. Wire to the new element, and deal with deleting the old wire
  3. Delete the old accessor using either Resize Handles or "Remove Element" from Context Menu

This can be laborious. Instead, I would like a way to quickly reorder the elements. I have a few ideas how this can be accomplished:

  1. Context menu with a "Move Up" and "Move Down" action (not so elegant)
  2. A pop-up window that allowed rearrangement (think "Rearrange Cases..." on Event Handler or Case Structures)
  3. A native drag-and drop on the Unbundle/Bundle node itself. This could be realized given the current "click regions" on the node (hover your mouse and sweep horizontally over one of these nodes... you'll discover the 4 regions). The two "Arrow" regions currently move the node on the BD, but they could be used to rearrange the node (see below)

20991iC0D9F95AD3E82BBE 

 

Just throwing out some ideas, I'm not stuck on any one. So, the idea you are voting for: Provide a User Interface for quickly rearranging elements on a Bundle or Unbundle by Name.

It would be really nice if double-clicking column header separators in tables, trees, and multicolumn listboxes automatically resized the columns based on their contents (like Microsoft Excel). This would be useful in these types of controls and indicators at both edit and run time. It would also be useful to have this capability interactively (initiated by the developer or user) and programmatically (through properties or methods).

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.

A malleable VI on a block diagram can be converted from an Instance VI to a Standard VI, which I've found useful to aid debugging. Unfortunately this modifies the calling code and requires the changes to be reverted to restore the original malleable VI.

 

This idea is to provide an additional right-click option for malleable VIs - View Instance VI. This would open the instance VI in memory, and allow read-only viewing of the block diagram.

instance-vi-1.png

This is useful when examining how the Type Specialization Structure cases are being evaluated given the currently wired inputs to a malleable VI. It also offers ability to quickly view the instance VI data types, helping determine which malleable input wires are *actually* broken. In the example below LabVIEW shows all of the inputs to Stall Data Flow.vim as broken, though viewing the instance VI shows only one input is actually broken.

 

instance-vi-2.png

 

When the Instance VI is opened for viewing, it wouldn't offer any runtime debugging, but means no changes need to be made to the calling VI when performing static code analysis at edit time.

 

The ability to view instance VIs already exists in LabVIEW through VI scripting (see example below), but would be nicer to have quick access to it when right-clicking a malleable VI.

 

instance-vi-3.png

At the moment, using Diagram Disable Structure with Channel Wires results in a broken arrow, which prevents compilation. However, it would be highly beneficial to allow temporarily disabling the transmission of values or messages to different parts of a program—for example, during debugging.

Quiztus2_0-1755004887752.png

A tedious workaround used in the past involved connecting ))Channel.vi with ChannelOp.ctl from the generated Channel Wire library to the channel in the enabled case. This allowed bypassing the broken arrow issue.

Quiztus2_1-1755005119160.png

However, since around 2025, these components have become natively private, making the workaround even more cumbersome and less viable.

I’d like to propose the following improvements:

  • Native compatibility between Channel Wires and Diagram Disable Structure.

  • Optional front panel connection for Channel Wire controls—i.e., they shouldn’t require a wired connection to function or compile.

These changes would streamline debugging and development workflows and reduce unnecessary complexity.

 

I've been doing a lot of string comparisons lately and I really hate having to drop To Upper/Lower Case function in front of my Equal? comparisons, as shown below:

 

 Case Insensitive Equal.png

 

It would be so much nicer if I could just have a special Case Insensitive mode for the Equal? node (and, it would be nice if the Equal? function changed its visual appearance, somehow, to signify that it is in a Case Insensitive mode):

 

 
Case Insensitive Equality Comparison.png

Problem: When developing or inheriting a large code base it is helpful to know which VI has Automatic Error Handling (AEH) enabled and which has it disabled. Currently, the quickest way to get this information is to bring up the VI Properties window (pressing Ctrl + I) and navigate to the Execution page. This is tedious when done on large numbers of VIs.

 

Solution: LabVIEW should display whether AEH is enabled or disabled on the Block Diagram. For example, a grey triangle located in the bottom-right corner of the block diagram window could indicate that AEH is disabled, and an "error green" triangle could indicate that AEH is enabled, as seen in the screenshots below. This display method is just a suggestion - professional UX designers may well find a better method. I would be happy with any indication method that I could at a glance see on the block diagram window.

 

2 Screenshot (AEH off).png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

3 Screenshot (AEH on).png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Idea expansion:

  • Executing a single left click on the triangle (or any other indication method) would toggle the setting to its other value. For example, a single left click on the grey triangle would toggle the AEH to enabled and the triangle would become green.

I wish there was a boolean text specifier for Format into String functions.

 

% followed by "?" would expect two possible strings like this. Why not?

 

boolean.png

 

 

Problem:

I faced to delete multiple elements form the array which is having 20 steps.

 

solution:

if able to select multiple elements by holding the shift key we can delete selected items 1 time and can insert 1 time.

 

 

Array element.png

 

 

I realize that the DBCT is nearing its 20th birthday, and probably is not a priority for a fix, but this is so simple and has tripped up a number of LabVIEW programmers doing database applications for so many years.

 

The VI Rec Fetch Next Recordset (R).vi has a flaw which manifests itself in stepping past the last recordset in a multi-recordset return - then leaks a reference which causes mayhem in downstream code.  A simple test of the recordset reference would make this VI properly useful.

 

Among my other posts in reply to forum users about databases, the issue is captured succinctly here.

 

I long ago made the mods to the toolkit VI (actually, two), and reapply them with each new LabVIEW version as needed.  If anyone at NI/Emerson wants to look into this, I'd be happy to share the particulars.

 

Dave

I use the conditional disable structure in my projects to turn debug options on and off.

At the moment before every build I have to go into the project properties and make sure that DEBUG variable is set to FALSE and after the build I have to change it back.

You can get around this by automating you build but an option in the build specifications would simplify this.

 

It would make life much more convenient if there were a list of the available (non-system) conditional disable symbols in the application builder dialog where the appropriate variables for the build could be set. This would also allow for a simple duplication of a build spec to have one with DEBUG=TRUE, and one with DEBUG=FALSE.

Almost every widely-used software framework, ecosystem, IDE, ... has a public bug-tracking dashboard where bugs can be:

  • reported
  • monitored
  • voted
  • ...

Jira or Mantis are quite common solution.

As a NI user, the current situation it's really frustrating: even for bugs originally reported by me, the ticket is created by a NI engineer.

And so I don't know what information it contains, its priority, if someone is working on it, if it has been already solved, ...

 

Many years ago NI was a pioneer with the community, but now is ages behind everyone else.

It seems that if you have a VI (or function) inside of a disabled frame of a Diagram Disable Structure or Conditional Disable Structure then the Find and Find All Instances features in LabVIEW will not report them. I'm OK if this is the default behavior, but maybe the Find dialog should have an option/checkbox to search inside of Disabled Structures.

 

Note: This is really important for cross-platform and embedded target development where there's lots of use of Disabled Structures.

Jim_Kring_0-1607621796261.png

 

Since 1986, when LabVIEW first launched, there has been one constant.  Icons are 32x32 elements. 

 

That made sense on 17inch CRT monitors.  There have been improvements in displays since then but, no corresponding improvement to the Icon resolution. 

 

Isn't it time to change that?

Open the VI Properties dialog when the Control key is depressed and the VI's icon in the upper right is double-clicked.

 

Right-clicking the icon shows a pop-up menu with VI Properties, Edit Icon..., and Find All Instances. Double clicking it opens the icon editor.

I use a lot of user events and often define the user event references in a typedef cluster before actually writing the create/generate/destroy code. It would be really helpful if the Create User Event primitive would change its input datatype based on the output (i.e back propagate the datatype), much like the Variant To Data primitive.

 

Back Propagation of Data Types.gif

 

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.

Jim_Kring_0-1707938647270.png

 

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.

Given the properties dialog box isn't resizable, and there's nothing under the table (apart from one tick box), could you make the items table longer? It's really annoying when there are a few extra values that can't be seen because the table is too small.

 

Proposal to make the Edit Items box longerProposal to make the Edit Items box longer