LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

View All (4)

Reduced inteface size

I am missing a tool to clear the revision history of all VI's, classes, controls, ... in the current project.
I find this useful since when building, some of the revision history is still checked and causes longer build times and even build errors due to this revision history still referencing old missing VI's which are not even part of the repo anymore.
To extend this: Why is there still a revision history in every VI, control, ...? Everybody uses a version control system like GiT or any other one, so it is even better to just switch off revision history tagging in the LabVIEW options for a project (just like separate compiled code checkbox)!
This would be a nice feature and will clear all my errors, pain and time consumption..

View All (2)

Default cases should be pure!

When wiring a numeric or enum to a case structure, we get the existing case as 1 (or the second enum item) and a default case also containing "0" (or the first enum item). Many times we need a special case only for one item and everything else should be in the default case.

Case structures are happy with just the word "default" in the second case. The unfortunate automatic existence of one other specific selector value in the default case hampers workflow. For example in the vast majority of my coding, I want the special case to be zero and the other case to be the default.

After wiring the selector, I could just enter the desired value in the non-default case that is showing, except if that desired value also exists (for no good obvious reason!) in the default case. If this happens, I need to edit the default case. That should not be necessary.

Suggestion: Whenever a default case is automatically created, it should not contain any extra specific selector values.

View All (1)

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.

Hi all,

I' normally using one or multipe queued message handler with a clustered enum (which is saved as Type Def.) and a variant as a basic architecture of my programs. This makes sense and it is relatively easy to search forward and check a program step by step. Unfortunately, it is not so easy to go stepwise back in the program for debugging., especially if there are multiple callers of a function.
Therefore I wish I have a function, where I can search for a single item of this enum Type Def.
I know that there is a possibility to search a text and of course it will find these items, but is also finds all other kind of things labeled the same.

I had a small chat with a engineer of NI already and we had an idea to gerneralize this a little to give it more use cases.
In the current situation, we can search for a:
- Type Def. , but then it will find each item of the enum OR
- text, but then it will find all items labeled with this text.

So here is our idea:
Create a possibility in the search window to combine these 2 search formats with a boolean operator, in our special case, this would be AND. But in other cases it might be also useful to have some other operators.

You are welcome to share any thoughts about it.

Best Regards, Patrick

A recent version of LabVIEW has introduced the ability to make the Iteration Terminal of For Loops and While Loops invisible. This is a useful new feature, I use it often, thanks for implementing it.

The problem is that currently the only way to toggle the visibility of the Iteration and Conditional terminals is to right-click, navigate to Visible Items, and select the desired option. This can take one or a few seconds, which is slow. Moreover, sometimes it is necessary to right-click and access the menu twice in quick succession. For example, for loops are created with their Iteration Terminal visible and their Conditional Terminal invisible. If one wants to invert the visibility of each terminal (make the Iteration Terminal invisible and the Conditional Terminal visible) one needs to access the same menu twice. This can take a few seconds.

Solution: The Iteration Terminal and Conditional Terminal configuration of a loop can be set via a single keystroke. For example, pressing "0" would make both terminals invisible (if possible). Pressing "1" would make the Iteration Terminal visible, and the Conditional Terminal invisible. Pressing "2" would make the Iteration Terminal invisible and the Conditional Terminal visible. Pressing "3" would make both terminals visible.

Notes

While keys "0", "1", "2", "3" are proposed above, I would be happy with any other keys, or key combinations, being chosen as the trigger of this action.
The digits 0/1/2/3 were chosen as they can represent a two-by-two binary table of the visible/invisible states of the two terminals. I.e. 00 = both terminals off, 11 = both terminals on, etc.
Pressing the key should have no effect in those cases where the requested action is impossible. For example, a While Loop must always show its Conditional Terminal. Pressing "0" could make the Iteration Terminal invisible (if it is not wired), but would have to leave the Conditional Terminal being visible.
This idea sits in the "increase developer productivity" category. I want my IDE to enable me to be as productive as possible. Every second matters. In fact, even tenths of a second matter.
This idea is similar to the following: Pressing the "L" key should toggle label visibility. These ideas were posted on the same day.

View All (2)

Currently the quickest way to open a typedef is right-click >> Open Type Def.

Holding down a modifier key (Ctrl, Alt, Shift, or a combination of these) while double-clicking on an existing typedef constant or terminal (Block Diagram) or control/indicator (Front Panel) would be quicker.

Notes

The gesture could open the private data definition (ctl file) of a class when double-clicking on an object constant, terminal, or control/indicator.
Opening the typedef for inspection/modification is one of the most common actions when working with typedef clusters and enums.

View All (2)

Big clusters that go beyond the limit of the FP are annoying, especially to resize them automatically and reorder the controls.

Here are a couple of improvements that could be made:

"Reorder controls in cluster..."
- Allow user to scroll while re-ordering the controls to have access to all elements instead of having to do it in multiple time.
- Shortcuts like Escape and Enter should respectively cancel-exit and validate-exit the reordering phase
  These are pretty standard shortcuts and already widely used within the Labview environment
"Autosizing"
- Autosize to "Compact". Where instead of aligning all element vertically or horizontally only, they would be in the "most compact" (to be defined) possible configuration to simplify the access to all info in the cluster.
  For instance compacted in a square way, sorted by class (Booleans/numerics/strings etc.)
  I understand that this one might be more complex, but it would be really helpful in my opinion
- Less important (to me): In Edit Mode, in case a cluster is autosized to "none" and some items are hidden outside for whatever reason, the developer should be notified somehow. For instance the same way than for strings
- (In the same case than above, allowing scroll bars could be interesting in some situations.)

-Vincent.

View All (4)

"Find" -> "Class Constant" option

Error 1003 occurred at an unidentified location

Possible reason(s):

LabVIEW: (Hex 0x3EB) The VI is not executable. This error may occur because the VI is either broken or contains a subVI that LabVIEW cannot locate. Select File>>Open to open the VI and verify that you can run it.

The RT Image contains a secret subset of the host's vi.lib. Excluding vi.lib is the default build setting and is recommended in LabVIEW: (Hex 0x6C0) When Deploying Source Distribution to RT Target - NI

When running deployed code, we get error 1003 if the RT Image does not contain a .vi or .ctl that exists in the host's vi.lib. My tests showed that this can likely be a single .ctl.

I ask NI either to publish which .vis and .ctls each RT Image contains, or, even better, to create a log that helps identify which .ctl or .vi is missing. A log with even an obscure signature of the item that failed to load is better than having no information. The alternative—disabling “Exclude vi.lib” because of one or two missing files in the RT Image—leads to unnecessary bloat and code duplication for every single plugin deployed.

I ask NI to either publish which .vis .ctls each RT Image contains or better to create a log which can help identifying which .ctl or .vi is missing. A log with an obscure signature that failed to load is better than no info here. The alternative of not excluding vi.lib because of one or two missing files in RT Image is effectively unnecessary bloating and duplication of code.

View All (1)

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)

For anyone that has used CAD software, you know how much of a timesaver this feature is. It is very similar to quick drop but relies more on graphical selection than keyboard input (although, these shortcuts often allow text entry as well and have a configurable menu).

For example, pressing the "S" key in SolidWorks pops up a contextual, configurable menu at the current cursor position that allows you to rapidly click on common operations as well as customized shortcuts.

I have my own janky extension to quickdrop that makes a graphical menu present after pressing multiple buttons (ctrl+space, ctrl+q, then one of WASD or a mouse click on the popup .vi front panel), but it would be nice if I didn't have to go through multiple shortcut selections to hit my toolbar-of-target. Said another way, a more extensible quickdrop-like shortcut bar would be nice. Something like the right click and shortcut keypresses for Autodesk Fusion and Solidworks are the inspiration.

It's always a pleasure to uncover shared memory problems when working with base vi.lib methods that *should* work as preallocated clones and have uninitialized shift registers and then having to establish a chain of vi references to safely call those methods in an application with distributed/parallel threads. It feels like extra work but does fix the problem. It's a major unknown gotcha unless you're already familiar with the vi you are calling.

My most recent hiccup: the NI PID library. I needed two closed loop controllers in actor framework, and was getting very strange timing, setpoint, process variable, and control output crossovers until I realized the stock .vi's had shared memory in the form of uninitialized shift registers (despite being in the context of a pre-allocated actor). Creating references of the vi's I needed and storing them in the actor at launch fixed the problem, but at that point the effort in writing my own PID .vi starts to be a favorable time tradeoff. At least I am able to peek under the hood of the PID library, other aspects of vi.lib... not so much.

Or maybe this is a teaching problem. I haven't come across ways of navigating this issue from official NI documentation, in fact the way I learned I needed to call the PID.vi by-reference was from the forum and rather matter-of-factly. There are a couple of great blogs that cover this issue in detail, so I don't feel alone in my ignorance. Maintaining State Information in LabVIEW Applications, Part 5 - LabVIEW Field Journal Archives | LabVIEW Field Journal Archives

View All (5)

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:

The current process of moving one of these elements:

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!
Wire to the new element, and deal with deleting the old wire
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:

Context menu with a "Move Up" and "Move Down" action (not so elegant)
A pop-up window that allowed rearrangement (think "Rearrange Cases..." on Event Handler or Case Structures)
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)

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.

View All (7)

Abstract VI execution

It would be nice to have a performant way to execute an abstract represented VI.

There are currently two generic ways to execute a VI by reference:

- abstract represented but not performant (FP required, running in UI threading)

- specific represented and performant

Executing a VI currently.png

Is it possible to provide such a functionality which combines the advantages of both solutions like this?

Executing a VI proposed.png

This means, the target VI could be handled in abstract way without coupling to the specific VI connector panel.

On a block diagram string constant, there are shortcut menus to change the display style. Currently, we can change the style without making the selector visible. That leads to bugs when later programmers do not realize that the string they are editing is in a different mode. Currently, we have to choose "Visible Items >> Display Style" first, which makes the shortcut menu items useless (because then we just use the now-visible selector ring). In the future, when we change the style through one of the shortcuts, I would prefer that the selector automatically becomes visible.

LabVIEW Idea Exchange

Path control with auto-complete (similar to Terminal)

Reduced inteface size

Clear the revision history of all VI's in the current project

Allow Wire Labels to Dictate Name Inheritance in Bundles

Default cases should be pure!

LabVIEW should have tabs instead of new windows

Respect OS “Lines Scrolled” Setting When Scrolling String Constants

Extend the search function (Ctrl+F) to get more detailed search results / Search a single item of an enum Type Def.

Pressing "0", "1", "2", "3" should toggle the visibility of Iteration and Conditional Terminals of For and While Loops

New gesture: Ctrl + double-click on typedef should Open Type Def

Improve cluster reorder and autosizing

"Find" -> "Class Constant" option

Meaningful Log for Error 1003 When Running Deployed Code

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

Graphical context menu at mouse pointer, super-duper quick drop

Eliminate uninitialized shift registers from vi.lib

get DLL path from the call library function node

Rearrange Unbundle and Bundle By Name

Abstract VI execution

Changing display style on string constants should make the style selector visible