LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

I like to collapse long string and path constants to consolidate diagrams. Showing the string or path value in the tip strip is useful but tedious to update.

I suggest an appearance property that would automatically display the current value in a tip strip for string and path constants.

This property would be most useful if the Block Diagram Options page was also modified to allow a global setting.

View All (3)

The top For loop + Unbundle is the current method to get the Keys and Values of all elements in a Map as arrays. If you need both, this is ok, but I'd prefer the second option, with a native node.

If you only want one (e.g. the Keys), then the For loop and Unbundle takes quite a bit more room than a similar-type of node (here the size is taken from the Collection Size node, and the paired outputs in the second row are from Matrix Size).

Can we have nodes to access the keys in particular, and perhaps the Keys + Values of a Map without requiring the For loop?

Improved PPL Debugging

I've encountered quite a few limitations when debugging debuggable PPLs, and feel that a number of improvements could be made to this process. I often find myself having to open a second project with the specific dev library in it, and then toggling back and forth between the two which is both confusing and inefficient. This is just scratching the surface, but here are some improvements I'd like to see made:

Non-editing menu options should remain available. One I use quite commonly: right-click on a class cube, and select "Show Class Library". But it's not available:

The workaround I use is to "Copy Data", press ctrl+n to create a new VI, drop the class cube there, and then right-click on that and select "Show Class Library", then toggle back to the temporary VI and close it.
VI Properties aren't available in VIs:

I often want to double-check reentrancy settings on VIs to ensure everything's configured correctly.
Private class data isn't shown. I get why this isn't available in non-debuggable PPLs, and I understand that there's a healthy debate that can be had as to whether or not this should be available in debuggable PPLs. I'm of the opinion that private data should be available in debuggable PPLs as they are meant for debugging, not for distribution.
Private class methods don't show up in the project. But if you click on the sub VI for a private method, you can open up the block diagram. If the block diagram is accessible, it really should show up in the project. I often find myself searching for a VI in the project, and not finding it anywhere, because the method is private.
Unusual interactions. I've seen a number of scenarios where I'm prompted with requests that I shouldn't be asked. For instance, if I double-click on a malleable VI in a PPL's block diagram, I get this popup:

View All (6)

View All (1)

Searched briefly but couldn't find any ideas about this.

I know we have the ability #via_ignore comments to ignore specific tests for a specific VI, but I am looking at a different use case.

Here's the use case, I use DQMH. When you create a new DQMH module there is a lot of plumbing code that comes with it. It's standard stuff. Very rarely do I have to open or edit it. Much of it is scripting generated. It often fails tests but I don't care. In addition to failing, it takes up test time, which slows my feedback loop. I would a way to signal to VI analyzer to skip these files. I know I can use the VIAN API to limit the files it checks, but I was thinking there had to be a better way.

Implementation Ideas - I had 2 main ideas

- Regex matching on VI names - with the regex pulled out of a text file somewhere ala gitignore. Many of the DQMH generated VIs have standard names, so that is easy. When generating events, they don't but you could easily add a prefix/suffix or something that the regex would pick up.

- Using the Tag API to tag the VI. I like this because the scripting can just apply the tag or apply it to the template the scripter uses. Downside is: kind of hidden from the user and perhaps if I decide to make some edits to this VI I may want VIAN to stop ignoring it and it's not immediately obvious how to do that.

Note:

I picked the Execution and Performance Label because it didn't seem to fit any of the labels easily. If this is the wrong label and you are an admin, please relabel it.

View All (2)

View All (5)

Navigating long lists in LabVIEW can get painful, e.g. for producer consumer design patterns and message handlers.

This idea is to add submenu parsing for dot notation items.

Now your case structure can do this:

I don't think it will effect ranges in the case selector as it requires two dots... e.g. "Init.Step1".."Init.Step4"

Credit: This thread for inspiration: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Case-structure-easier-selection-for-structures-with-a-large/idc-p/4192417?profile.language=en#M43910

Suggestions required on how to handle a list in this situation where its a lot of numbered messages.

Also I just learned from a colleague that by grouping controls carefully (& some caveats) with the dot notation on FPGA it allows for a submenu. (And clusters on a FPGA can take up a lot of gates). So LabVIEW already has some code for this feature. Can it be leveraged? See below:

https://forums.ni.com/t5/LabVIEW/Group-FPGA-Controls-With-Dot-Naming/td-p/2767678?profile.language=e...

This post generated this idea which is the same problem in the FPGA space... grouping long lists to make them easier to use.

https://forums.ni.com/t5/LabVIEW-FPGA-Idea-Exchange/Better-FPGA-FP-Control-Selection/idi-p/3074718

View All (5)

View All (2)

Permanent Knight License

It's useful that we can open the Error List window via the Ctrl + L shortcut.

It would be great to have keyboard shortcuts that allowed us to navigate to the next and previous errors (broken run arrow locations). This would be similar to how Ctrl + G and Ctrl + Shift + G can be used to navigate to the next and previous result in the Search Results window.

I would be happy with any key combinations chosen for this purpose.

Thanks

View All (2)

Color Picker Event On Mouse Movement

If I drop down a color picker control, I can get an event on it for when a new color is selected by using the value change event. But what if I want to know what color the user has their mouse over, before clicking on it? Many of NI's controls change color as you select a new color. The Graph plots for instance will update as you move the mouse around.

This idea is to allow color picking controls to have a new user event, which is Mouse Over Color which gets generated when the user mouses over a new color. This way we can make applications that change the color of some UI element before the user picks the new color like NI does.

This can be accomplished today by recreating the color picking functionality in a new VI. Here is one example posted that allows you to pick a color. Using this someone could generate a User Event, or post to a global as the new color selection is being made.

vi properties window name

I'm developing code, and like most people I know, I have multiple VI's open at once.

If I then go and open the VI properties dialog, I lose track of what VI the properties are for, especially if I get an interruption. I know I can just close the properties window and open it again for whichever VI I wanted (or go to the parent category to see the name), but this could be solved by simply adding the name of the VI to the window title of the Properties dialog.

like this:

View All (2)

Add Control Anchors to Labview

.net and many other languages have an intuitive and simple way to allow you to define how a window behaves when you resize it: anchors. Anchors allow you to define the distance between an edge of a child control and the edge of a parent control regardless of the size of the window. The size of the control itself stays constent unless it violates the rules of the defined anchors in which case it changes sizes to meet those rules. For example a front panel with the following anchors:

Would be resized into:

In LabVIEW you need to know the number of sub matches at edit time and cannot handle arbitrary regular expressions. It would be nice if there was a regex function that returned sub matches in an array which can be handled much more abstractly than a pre-sized xnode.

C++, the regex utilities return a container-like class https://www.cplusplus.com/reference/regex/match_results/

PHP an array of matches is returned https://www.php.net/manual/en/function.preg-match.php

JavaScript returns an array of matches https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/match

View All (4)

Key focus Event

View All (5)

Currently, for waveform/XY plots/graphs, the legend, graph palette, cursor window, etc are all "coupled" with the graph itself from a "graphical" perspective.

This means that all of these "addons" must be attached to the graph, and you can't put them in a different part of the panel. Screen resizing thus tends to screw things up, especially if your plot names can be defined by the user.

I'd like to decouple these somehow.

For example, I'd like to be able to put my legend and zoom tools in separate panes separated by splitter bars, or even in a right-click style menu (like a subpanel popping up). This feature would let you use automatic resizing on the plot itself and keep the legend separate.

You could theoretically program your own version of this, but:

-Recreating the legend functionality (line size/width/etc) would be a large undertaking, especially since there isn't a native Datagrid type control that could display a checkbox, string, and small image.

-I don't know of a way to get at the built-in zoom/pan tools programmatically (yes, you could create your own, but it's a big PITA)

-It wouldn't work at edit time, like the current features do, unless you baked all of it into an Xcontrol

Basically yes, you COULD get a lot of this done yourself... but it'd be nice to just use the tools NI already made, which work great. I don't want to reinvent the wheel just for some graphical convenience.

There is a path type selector (Valid Path/Not a Path) on all the path controls. This is useful on "data" type controls (subVIs) where you may wish to test input values, but rarely useful (may even be confusing) on path controls used on end-user facing front panels. They make no sense at all on indicators. These selectors are most prominent on the NXG style controls:

NXG Style Path.png

Here's an idea to be able to hide these buttons, just like we can hide the browse button. Perhaps Show/Hide/Hide at runtime options, but at least Show/Hide options.

View All (5)

The idea is simple: if the label ends in a number (i.e. consecutive string of numeric characters), increment that number:

It seems like it only works if there is a space character. If there is a good reason for doing it that way, help me understand what it is.

I linked some similar ideas below. I like these discussions for the most part, but they tend to have broader scopes than what I'm suggesting.

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Smart-er-automatic-label-names-on-copy/idi-p/1873663

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Auto-increment-number-in-middle-of-control-name/idi-p/977710

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Don-t-skip-quot-1-quot-during-automatic-naming-of-copies/idi-p/977300#A2089

View All (2)

I think it would be a good idea to enable running code formatter, like Darren's Nattify VI, automatically when saving a VI. Currently, most IDEs have built-in formatting tools which promote a unified, clean code style, and programmers don't have to worry about it because the code is automatically cleaned up before saving. I think a similar function would be a great addition to LabVIEW.

In Visual Studio it is called "Run Code Cleanup profile on Save". You can also configure different profiles (different styles or flavors). This option would be nice to have.

It would be great if it were possible to reduce the amount of time spent cleaning up LabVIEW code while keeping the code in decent visual condition.

View All (5)

LabVIEW Idea Exchange

Automatically Display Value in Tip Strip for String and Path Constants

Directly access a Maps Keys and Values

Improved PPL Debugging

String control/indicator/constant with line number display.

Webservice Swagger/OpenAPI document generation

VI Analyzer Ignore Certain VIs Completely

Add licensing and activation tools for packed project libraries (PPLs)

Dot Notation for Auto Submenus for Easier Navigation of Long Lists

Boolean Array to Number Right Click Menu

Permanent Knight License

Keyboard shortcut to navigate to the next edit-time error (broken run arrow reason)

Color Picker Event On Mouse Movement

vi properties window name

Add Control Anchors to Labview

Provide regex functions with match outputs as an array

Key focus Event

Decouple plot legend/tools/etc from the plot graphic itself

Allow hide of path type selector on path controls

Increment label ending in numeral when copying control

Run Code Cleanup profile (Nattify VI) on Save