LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

View All (2)

Problem

I find myself wanting to Ctrl+Drag to add/remove diagram space INSIDE of a structure without actually resizing the structure itself AND without modifying any other frames – I just want to clean up the visible diagram that I am working on.

However, this is not how LabVIEW currently works – the structure itself is also resized, and the space within other frames of the structure are resized as well (outward/inward from the same point as the Ctrl+Drag action), which can mess up both the code in other frames as well as the code outside the structure.

Proposed Solutions

Option 1: Lock Structure Size Add the ability to lock the size of structures (or perhaps only lock them from growing during creating/removing space), so that I can use Ctrl+Drag to create/remove space without impacting the structure and the code around it. This would be similar to "Auto Grow" but would perhaps be an "Allow Grow" or "Lock Size" setting.

Option 2: Modifier Key Use the Shift modifier during Ctrl+Drag and Ctrl+Alt+Drag to NOT resize the containing structure. This would maintain backward compatibility while adding the new functionality.

Why This Matters

When working on complex VIs with multiple frames in structures, it's frustrating to have simple diagram space cleanup operations affect the entire structure and surrounding code. This feature would allow developers to better organize/tidy the code within individual frames without the ripple effect of resizing everything (in other frames and outside the structure).

View All (2)

Add structure on bare wires

Current Behavior of LabVIEW
Currently, the error messages that emerge from bad call to a Property Node or Invoke Node only state that the error occurred in a property node or invoke node.

User Need

As a user of LabVIEW, it saves me considerable time in development/debugging, when I can precisely know why and where in the code an error occurred , so that I can get on with the actual work of fixing the bug in my own code/logic.

Problem For Users

The current behavior, described above, makes it impossible to know (without placing probes and retaining wire values):

A) Which Property Node or Invoke Node actually generated the error (in cases where there are many of such nodes)? Again, all we know is that some Property/Invoke Node on the block diagram of the VI raised the error.

B) Which specific Property actually caused the error, in cases where a Property Node has multiple properties that it is reading and/or writing. Again, all we know is that the error occurred inside a Property Node.

Proposed Solution

Error message for invoke/property nodes should state:

- the Name of the Method or Property where the error occurred
- the Class Name of the VI Server Object (if available)

- the Object Refnum value (e.g. the hex value of the object reference)

- possibly even (only if running in the editor and not the runtime environment) the VI Server Scripting UID of the GObject node on the Block Diagram for super-fast debugging with a "fancy error dialog of the future" (TM) whose LV Idea Exchange post with undoubtedly be coming soon...

View All (3)

Starting from LV 2023 Q1, the terminals height of some nodes was harmonized to 16 pixels to improve diagram readability by reducing the amount of needed wire bends.

Some candidates for this harmonization were omitted though:

- Data nodes of timed structures (timed loop, timed sequence).

- I think pretty much all of FPGA nodes (IO nodes / methods / properties, FIFO / memory / register / handshake methods, IP integration, high-troughput math nodes, ...).

Example with a Timed Loop:

The idea is to also allow RT and FPGA developments to benefit from this harmonization.

View All (4)

View All (1)

Currently each error in terminal contains the following description: "error in can accept error information wired from VIs previously called. Use this information to decide if any functionality should be bypassed in the event of errors from other VIs. Right-click the error in control on the front panel and select Explain Error or Explain Warning from the shortcut menu for more information about the error." This occupies 367 characters (bytes).

Currently each error out terminal contains the following description: "error out passes error or warning information out of a VI to be used by other VIs. Right-click the error out indicator on the front panel and select Explain Error or Explain Warning from the shortcut menu for more information about the error." This occupies 271 characters (bytes).

This applies to terminals of all styles: Classic, Modern, Silver, Fuse Design System.

This adds a total of 638 characters (0.62 KB) to each and every VI that uses a pair of error in/out terminals, which is probably a majority of VIs in LabVIEW.

The descriptions appear in the Context Help window and can be useful to beginners. But this benefit is not worth 638 bytes of space in so many VIs. The contents of the descriptions should be mentioned in training material such as LabVIEW Core 1 or the LabVIEW Help.

This proposal is to remove (clear) the error in and error out descriptions, such that VIs are "slimmer" and codebases are smaller.

View All (2)

A very common task when operating with 2D pictures are mouse down/move events where we are interested which pixel was just clicked. While there is an event data node for the clicked coordinates these are relative to the front panel and translating them into image pixel coordinates is a chore and requires ~~jumping through flaming hoops~~ tweaks. (i.e. label yes/no? zoom factor? etc.)

However, there is a "Mouse" property for 2D images that has all the information directly in pixel coordinates and mouse button states. Currently, we need to read that property inside the mouse event to easily get the information we always (always!!!) want in such an event!

It would be cleaner if mouse events on pictures would output these mouse properties directly as an additional event data node.

Two clear advantages:

Cleaner code for those who know how to work with this property.
Stop sending newbies on a snipe hunt trying to figure out how to translate the current "coords" event data node into something useful for the intended task.

Here is an example where this idea would have helped

Here's a picture for the graphical thinkers!

Thanks for voting!

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.

View All (5)

Drag wire to insert vi

For pass-through values like errors, classes, visa sessions, etc. it's a hassle to insert a vi into existing wires. It would be intuitive and very efficient if you could "pick up" the wire, hover over the vi terminals, and have the connections made automatically.

View All (3)

What is a strictly-typed reference?

A strictly-typed reference is a kind of reference whose type descriptor contains an inner, user-specified data type.

For example, a queue is a strictly-typed reference because it contains the data type for its elements, specified when creating the queue.

Here is a non-exhaustive list of such reference types:

- Queue

- Notifier

- User event

- DVR

- Datalog file reference

- Strictly-typed control refnum

- Strictly-typed VI refnum

- Shared variable

- Network stream (reader/writer)

- RT FIFO

- FPGA IO / register / memory / FIFO / handshake

- ...

Idea:

Add a new primitive that would output the inner data type of any strictly-typed reference.

Here is a design example of the primitive, which could be named "Get Contained Data Type of Strictly-Typed Reference":

It would work for all the strictly-typed references mentioned above.

Motivations:

The implementation of malleable VIs is sometimes limited (or made complicated) by the fact that we miss some basic "type operators", such as getting the contained data type of a strictly-typed reference. While this missing function could be implemented using some tricks for most strictly-typed reference types, it is for example impossible for user events (See this thread for more details).

Typical application:

A malleable VI that takes a user event (for its type) and outputs a newly created refnum with the same contained data type:

This simple code is currently impossible in the general case due to the nature of user events.

Remarks:

1. The output terminal of this primitive will have to be named exactly as the contained data type, which is crucial for user events.

2. The output would have the LabVIEW default value for the data type (False for booleans, 0 for numerics, "" for strings, ...).

3. The primitive could be placed in a dedicated "Malleable VI Tools" palette.

4. In case the FPGA-specific implementation creates a dependency to the FPGA module, we could have a separate primitive just for FPGA (and also for RT if required).

What do you think?

Regards,

Raphaël.

View All (8)

No autogrow while typing

View All (1)

LabVIEW Idea Exchange

Fix bug: replacing cluster constant should not alter 'View Cluster As Icon' setting

The Build status window should display elapsed time

Show coercion dots on malleable VI if there is one inside the VIM

Add/Remove Diagram Space Inside Structures Without Resizing the Structure

Problem

Proposed Solutions

Why This Matters

Add dynamic dispatch status to context help notes section

Allow Resizing on Parent Interface Selection Window

Add structure on bare wires

Show VI Server class name and method/property name in Property/Invoke Node error messages

Normalize terminals height for timed structures and FPGA nodes

Enhancements to QuickDrop insert (Ctrl + I)

Allow LabVIEW to work with Windows Clipboard History

Remove description of Error In and Error Out terminals

Mouse events on 2D pictures should have an event data node for mouse information

System-wide conditional disables should work when the VI is not in a project

Add threshold index output on interpolate 1D array function when the 1D array input is an array of points.

Add unbundle to wiring menu for clusters

Drag wire to insert vi

Indexing option for set and Maps out of loops

New primitive to get the contained data type of a strictly-typed reference

No autogrow while typing