LabVIEW Idea Exchange

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

A parent IDE window with 2 child windows each supporting "tabs", one for all Front Panels and another for all Block Diagrams. A 3rd child window for the project manager. All can be docked or undocked.

 

Operation:

Selecting a VI tab on one window would automatically select the corresponding VI tab on the other window so they always track together.

The child windows can be docked side by side or one above the other within the parent window or they can be undocked to place on separate monitors.

When child windows are docked, have a setting to memorize their position.

When in the “Highlight Execution” mode, the VI (Block diagram and associated Front panel) of the current execution path is automatically opened, if not already, and the tab selected.

Despite being growable for adding outputs (capturing groups), the "Match Regular Expression" XNode is missing some convenient features from other growable functions:

 

1. Cannot add a new element at the top while resizing the node:

Resize from top.gif

 

2. Missing "Add/Remove Element" right-click menus:

 

raphschru_0-1781017278636.png raphschru_1-1781017452535.png

 

 

The lack of these features forces us to rewire everything manually.

This idea has the same motivation as this previous one: making the editor more ergonomic and predictable.

 

Regards,

Raphaël.

If you set up Windows 11 as Microsoft suggests (at your peril), your user Documents folder will be synchronized to OneDrive. Unfortunately this is also the location of the default data directory for LabVIEW. Various side effects ensue but the one I've run into is the compiled object cache, a SQLite database that can get into the gigabytes, winds up getting synchronized which is a complete waste of bandwidth.

 

To deal with this I think there should be a warning dialog with "don't show again" checkbox when LabVIEW detects the default data directory is in a synchronized folder to prompt the user to choose a different location.

This idea is an extension of an existing one.  Here the idea is to have alpha layer support in the Picture Control.  But the truth is NI already added it in 2020 but never put it on the palette, or documented it.  I made a quick demo showing how you can have a highlight over an element of an array showing which one is moused over here. The main VI that powers this is here:

 

https://youtu.be/gqJWBbqoR4s?si=_JT8-K7FoNfaPVhz

 

National Instruments\LabVIEW 2020\vi.lib\picture\PNG\Draw Flattened Blended Pixmap.vi

 

But I would like this idea to extend beyond just putting this VI on the palette or documenting it.  I think NI should add more alpha layer functions too.  Things like convert LV Data to 32 bit, set or adjust the transparency level, and make a single VI that can call the normal Draw Flatten for a 24 bit or less image, and call the Blended one if 32 bit so that a single VI can be used.  I have a couple of these type of features in a pack on VIPM.IO but I'd rather they be built in to LabVIEW.

 

And lastly. If we are going to think about places that alpha information can be used, I think the first place I'd like it is to be able to get an image of a control, but have the background be transparent using something like this:

 

wiebeCARYA_1-1741949642891.png

Combining this with the other tools would mean there's more flexibility in making image based controls.

It would be nice if there was some option to configure the separator behavior of combo boxes. Currently, entering a hyphen (-) as an item turns into a separator automatically, and there is no way to configure that. What I think would be best in terms of configuration options is a "Separator Value" property in the Edit Items tab of the Properties dialog. The hyphen could be the default value, and it could be changed to an alternate character or character sequence if the developer needs the hyphen to appear as just that for whatever reason. If the value of the property is empty, there are simply no separator lines created.

 

FireFistRedhawk_0-1779113435039.png

 

There is also a bug involving the hyphen as the separator value. When a combo box has the Allow Undefined Strings property unchecked and also has a separator as one of the items, a hyphen is still treated as a valid entry since it is technically one of the values present. This bug exists in the most up-to-date version of 2026 at time of writing, 26.1.2f2. I think the existence of this bug warrants taking a look at the separator behavior in general, but also possibly adding this idea as an enhancement to it.

Windows Clipboard History is a very useful tool in Windows to manage copied data. But it doesn't work with LabVIEW content. Right now, when pasting copied VI content from the clipboard history, it is pasted as a regular image.

 

I am not sure how copy paste VI content works under the hood, but since VI snippets are regular png images, I guess this should be feasible. 

 

Having consistent (and therefore predictable) right-click menus is essential for maximizing coding efficiency.

 

Most structures have the following right-click menu items:

 

Visible Items
Help
Examples
Description and Tip...
---------------------------
Add Breakpoint
---------------------------
Structures Palette
Auto Grow
Exclude from Diagram Cleanup
<specific menu 1>

<specific menu N>
Replace with <other structure type 1>

Replace with <other structure type N>
Remove <structure type>
---------------------------
<other specific menus>

 

The right-click menu however has some inconsistencies regarding item order and menu separators for certain structure types:

 

1. "In Place Element Structure" has "Replace" and "Remove" items reversed:

raphschru_0-1778671181846.png

The "Remove" item should always be the last one in the item group (right before the separator) since it is a very common action and the separator offers a quick visual reference point.

 

2. Depending on whether you click on the structure border, the frame name label or the subdiagram label, sometimes an extra item separator appears for no reason:

raphschru_3-1778673447637.png  raphschru_6-1778673672106.png  raphschru_5-1778673565395.png

 

The grouping of the generic items shouldn't vary depending on where you click on the structure. Here we sometimes have 4 item groups instead of 3, which hinders quick menu identification and selection.

 

3. This is more a general remark, but I think items specific to a structure type shouldn't be mixed with the generic ones in the first 3 groups (except maybe for the "Replace" items, since they are related to the "Remove" action).

 

So any specific menu item should belong after the first 3 groups:

raphschru_2-1778672934373.png  raphschru_7-1778673846675.png

raphschru_8-1778673934000.png  raphschru_9-1778673982744.png

 

This last remark could be subject to discussion though, as configuring iteration parallelism and shared clone allocation could be considered a "primary" action (therefore requiring to be closest to the top), even if it is specific to certain structure types.

 

Regards,

Raphaël.

Many SW vendors still keeps supporting the DDE interface, it would be nice to go with newer versions of LabVIEW but now we need to use 2024 Q1 which is the latest version with working DDE VIs. INI-file mods to support CodeInterfaceNodes not work.

Quiztus2_0-1777992326142.png


The layering of values shown during highlight execution mode should take the data type into account. I suggest moving types whose values do not change—such as refnum or lvclass—to the back of the display stack. This should also apply to ordinary VIs, similar to how property nodes are already handled. Otherwise values worth to know are hidden by actually useless info.

Customer received this error after trying to send J1939 frames on XNET Bus Monitor,  once user select J1939 database , there is no option to transmit frames ,  not sure why XNET Bus monitor does not have that tab,  xnet does it support it, using a labview code is possible but xnet bus monitor is something very practical for Customer to use before going to code.

Also when this type of error occurs need to have better description as J1939 and CAN FD not supported in XNET Bus Monitor.

Even citadel database is not 64-bit.  64-bit version of LabVIEW Data Logging and Supervisory Control is needed.

Not too long ago i learned of the excellent Quickdrop command "Remove Unconnected" (ctrl+shift+r) on Build array and (un)bundle.

However it doesn't work with Index array and i wish it did. 🙂

That's all!

Yamaeda_0-1777370033284.png

Ctrl+space -> ctrl+shift+r ->

Yamaeda_1-1777370073167.png

 

Suggestion, it should work in this case also!

Yamaeda_2-1777370165875.png

 

Recent improvements to editing string constants on the block diagram—such as enabling Ctrl+A to select all text—have been very helpful. When testing parsers, I frequently work with large string constants, and smooth navigation becomes important.

Currently, scrolling inside a string constant always moves by a single line, regardless of the operating system’s configured “number of lines to scroll per mouse wheel notch.” 

 

Please update LabVIEW so that scrolling within a string constant honors the OS-level scroll-wheel configuration. This would make navigating large constants more consistent with user expectations and system-wide behavior.

Currently converting a string to an array loses the "Size To Text" property, this should be preserved to maintain the desired display after conversion

change to array size to text.png

The interpolate 1D array function has a powerful but under appreciated feature of being able to do segmented linear interpolation when the array input is an array of points.  (For example in an array of PID profile setpoints).  The interpolate function will directly produce the correct interpolated y value for any 'segment' in the array which is very cool.  However it does not expose the threshold index which would be very useful and is most certainly already computed internally.  In the use case of traversing an array of PID profile setpoints, it would be good to know what segment is being interpolated at any given time.

Add a context menu option to open class private data directly from block diagram / panel.   Currently need to select "Show Class Library" then expand and open control from Project Explorer.   During initial development I'm needing to modify private data frequently and this is how I'd expect to do so based on Typedef behavior (right click - Open Typedef)

 

class private data.png

Add a note here if the VI is dynamic dispatch to aid in code readability:

avogadro5_0-1776205743247.png

 

When creating a Polymorphic VI, please let us add VIs more easily.

 

Intaris_2-1776154590598.png

 


Either allow multi-selection of VIs when choosing "Add" (Button in Red) or allow drag and drop of multiple VIs from a project or explorer (Blue area is a target for drag and drop).

 

While I'm at it, please allow selecting and editing the "Menu Name" and "Selector Name" in place. Having to go through a button press and a dialog for each and every VI is tedious.

Currently, a malleable VI will not show coercion dots for any case (that I can find). It would be nice if it would show a coercion dot if it leads to one inside the vim:

 

BertMcMahan_0-1775166268652.png

 

 

(taken from avogadro5's post here)

 

I would propose that ANY coercion happening inside the VIM would lead to the dot, so even if the wire split and went to one non-coerced terminal and one coerced terminal, you'd still see the dot.

The default cursor color in the Fuse palette is yellow, which is nearly impossible to see:

 

cursorcolor.png

 

Since we can't set a default cursor color for a graph, and there are no events exposed that let us know when the user creates one, can we at least get the default color to be somewhat visible? Maybe dark gray?