LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Currently, you can place a probe on a wire while developing, which is an indicator of the data on a wire. I want the ability to CONTROL the data on the wire, with a data forcing mechanism.

The implementation would be very simple... right click on a wire, and in the context menu the option "Force" would be right under "Probe." It would pop up a window of the forcing control, and while the VI is running and forcing is set to "Enable", the programmer can control the values that pass on the wire. If the force window were set to "Disable", the data in the wire would be completely controlled by the VI's logic.

I think the implementation by NI could be trivially simple. If you only allow a forcing control to be added during edit mode (not while the VI is running), the force could be added as an inline VI (as denoted by the green rectangle on the wire). The code inside the inline VI would be as follows, and the front panel would be "Data Force (1)" as shown above.

Of course, if you could add a force to a wire during runtime like probes, props NI. But I would be PERFECTLY happy if you could only add these force controls in edit mode prior to running.

One level further (and this would be AMAZING, NI, AMAZING): enable and disable certain parts of the cluster that you would like to force and allow the other elements to be controlled by the VI logic. I made the example above because it would be very natural to ONLY force Sensor1 and Sensor2, and letting the output run it's course from your forced input.

View All (9)

If we type up a list in a text label we can now (since LabVIEW 2023) right-click on it, select quick change and convert it to a number of different objects (array, enum, boolean etc)...Once you have done however, right-clicking on the result does not offer the quick change option anymore.

It would be nice and feel more consistent if the same option was available when right-clicking on the supported objects as well; allowing us to convert those to any of the other options and/or even back to the original list (which would allow you to then edit that list efficiently and then reconvert it). Basically an label/object to object/label quick change, instead of just label to object.

PS. I know there are various quick drop plugins that do parts of this, but this would extend the now in-built function to cover those and more scenarios...

Many times data is generated or transformed using a function or vi with a single output. In those cases the wire name is the one given by the function or VI terminal, but it would far more descriptive if the wire could have a proper name according to is usage in the block diagram. You can attach labels to wires but these are not propagated particularly when used in places like "bundle" or in structures (for, while, etc.). In large diagrams thus it can be difficult sometimes to now what a wire is for.

This idea proposes to enable the override of the default name of the wire connected to output terminal to that of the label of the function, in case the label is not empty, for single output function or VI. In a similar fashion to the propagation of labels of constants. This could be automatic (not empty label) or deliberate (for instance, using a tick box in the properties page)

This is different from idea Allow-Wire-Labels-to-Dictate-Name-Inheritance-in-Bundles in that it follows the current LabView behavior of the wire name being dependent on labels on constants, and avoids possible conflicts.

tl;dr There's a summary at the bottom if this is too long for you.

Quick Drop is pretty useful when it comes to dropping things and the fact that it also gets items from the project is great.

What I don't like about QD, however, is the keyboard shortcuts. These allow you to perform custom actions in LV and the concept itself is great, but the implementation QD uses has some issues which other similar tools like the right-click framework and LabVIEW Speak don't have, such as the items in the following list.

The problems:

It requires you to remember keyboard combos to call the plugins. That's great as a secondary access mechanism, but is terrible as a main one for a few reasons:

It is not discoverable.
It requires you to remember key combos.
It doesn't work if you want a longer list of macros which perform all kinds of useful operations, because you run out of available shortcuts.
Likewise, you have shortcut collisions, because people want to use the same shortcut for different plugins, so you might say "Ctrl+T", and it will mean something else to the person you're talking to.

Setting options on the plugins is done by pressing the Shift key or other similar magic combos instead of having a clear representation in the user interface.

So, what can we do about it?

I think a good first step would be to stop thinking of these as "keyboard shortcuts". They should be thought of as custom actions or macros and they should simply appear in the list
along with the regular items, like so:

There are a few things to point out in this image:

The actions appear in the list using their full names and they have a glyph to set them apart from the other items.
The actions may (or may not) have a shortcut.
The actions may (or may not) have a keyboard shortcut (and there's no reason in principle why regular items can't have them too). This solves the existing problem of the shortcut limit - you only assign shortcuts to actions you access regularly, just like you can already do today with menu items.
There's a ring on the bottom which shows just the items, just the actions, or both. Ideally, the value of this ring would also be settable by other means (e.g. open QD using Ctrl+Shift+Space and the list only shows the actions or open QD when you have a selection and the list only shows the actions).

OK, so that's step one and it solves the first issue - the actions are discoverable, accessible and not limited in number.

Now step two - some of you may have noticed that the image has another new thing - there's an expand button on the right side.
Clicking that button will open this panel:

This area shows the details of the currently selected action and allows selecting options for it.

Here's what we see in this example:

A title.
A description.
An image.
In the settings area, I gave the "Build array of references" action an option - you can choose to align the Build Array node to the center, the top or the bottom of the references.

The panel should remember its last open setting between calls and when it's open, it should work asynchronously, so that it doesn't delay the operation of QD.
For the VIs which appear in the panel, there should be a standard template for loading and saving values, for showing titles and help data and for shutting down. If the VI fails to respond to the shutdown command within N ms, Quick Drop should proceed and not wait for it.

Of course, once we have this panel, the next logical step is to also have it show the help for standard items, similar to this idea:

So, to sum up:

Custom actions should be in the list of Quick Drop items.
Shortcuts for actions and items should be fully customizable. That means that you can still use keyboard shortcuts to call the actions, just like today.
There should be a panel which allows customizing options for actions and show the help for regular items.

View All (3)

Bleach Dead Code

It has come up here in a different discussion, but I think it should be a separate idea, so here it is!

If we disable part of the code using the diagram disable structure, the disabled code gets lighter in color. The new compiler is good at eliminating dead code (i.e. things that don't need to be computed because there is no output), so it could be useful if these code parts are also bleached in a similar way to indicate that fact.

Here's how it could look like.

I would even suggest this to be enabled by default. Of course there also needs to be an option to turn it off....

(I was about to write up this idea, but then, searching for "dead code", I found comment by SynchronizationOverhead. So the original credit goes there, of course ;))

View All (2)

The VI documentation window could use some improvement and several additions could be made to make editing the text a lot easier.

Improving adding control and indicator name.

Typically the text in the documentation window does refer to the control and indicator connected to the connetor pane.

It would be very convenient to have this information already in that window so we don't have look it up when needed. Additionally, the control and indicators are typically bolded in the resulting text using the <b></b> tag. It would be convenient if this would be done automatically for us.

In the propose idea (see image below) the VI icon with the controls and indicators is shown and the controls and indicators when clicked do insert their name into the VI description.

Note: The control name may be made to look like an hyperlink to indicate that there are click able.

For example, in the image below, clicking the "Items to filter" will insert the "<b>Items to filter</b> tagged text in the VI description.

Improve general text editing

While fancy text editing is limited in the VI description, adding a toolbar to improve text formatting would be useful.

View All (4)

I am struggling with my Event Structure event list and the corresponding list of cases in the parallel consumer loop Case Structure.

Both have currently over 100 cases each and finding one or scrolling down to access the latest one has become painful due to the lack of a scrollbar in these lists.

For instance, here is the Event Structure list:

Same goes for the list of controls in a Local Variable (and other objects, I am sure).

There is no reason why such lists do not have a vertical scrollbar when that corresponding to a Enum do have a scrollbar:

Or is there?

Suggestion: All long pulldown lists should have a vertical scrollbar

View All (1)

VIMs are awesome but when wire inputs are broken they aren't awesome. They'd be awesomer if there was a way to specify that when specific frames of type specialization structures are active, there is a way to get specific strings added to the error info for the caller. Having a way to add custom strings to VIMs would overcome the general "An unsupported data type is wired to this subVI node." error string we're currently given. This can also help differentiate between LabVIEW breaking during type prop for odd (bug) reasons and properly invalid inputs... Do I need to just delete a wire and re-wire the input or do I need to hope the developer provided good VI documentation?

With some additional frames in Type Specialization Structures and maybe something like a subdiagram label but instead it could be a error reporting field at the bottom of a frame, it would be much easier to provide meaningful information back to a developer such as "GUID input only accepts GUID.ctl or a String". Then if the caller breaks with the unsupported data type error for the VIM, error details from the currently active TSSs can be concatenated to the Details string displayed in the Error list dialog. Alternatively, each error message found in TSSs could be separately listed in the Error list.

My 10 second idea:

TSS Error.png

Resulting in the Error list perhaps showing it as either an error or concatenated into the Details:

TSS Error list.png

Working with class method VIs becomes easily confusing if you need to use VIs from several classes that are inherited from each other. Every class adds or overwrites VIs from one of the ancestor classes but usually you don't know which one. And if you're just user and not developer of this class structure you're usually also not interested in the exact inheritance hierarchy.

Look at the picture: As programmer of the application "main.vi" I'm just interested in Class 3 but I also need to know the internals of Class 1 and Class 2 whereby Class 1 is not even in my project. So I can't see that there are also other cool methods within Class 1 and to get methods from Class 2 I also have to search inside of it and compare against Class 3.

As reference: This is the content of Class 1

What I suggest and expect is the following:

=> The class tree shows all available methods within each single class!

bright colors: Methods that are defined in this class; pale colors: inherited methods

View All (4)

Drag & drop to replace

Hi,

Currently to replace something (for instance a node on the block diagram) you have to right-click and then select Replace... and then usually a lengthy navigation into the function palette or onto the disk with the OS file explorer.

Most often I already have a LabVIEW-project open, one or more explorer windows (opened at a useful context), and maybe also one or a couple of pinned sub-palettes - but I am not allowed to replace anything from these locations. I suggest that this will actually be allowed; that is: drag something onto the block diagram, and if you're enough on top of another object, then a replace-outline appears for you to drop your new object into. Here's an illustration for replacing something in the block diagram, but the same could apply to the front panel as well:

All the usual stuff should happen when you replace this way, as if you replaced through the context menu. For instance a prompt to save a VI that leaves memory, automatic update of a project's dependencies etc. Many ideas are submitted to this Idea Exchange to enhance the Replace context menu in different ways, but a feature as I'm suggesting here would improve my own workflow the most, simply because I already have much quicker access to my "replacer", through existing explorer windows, than going through the Replace context menu no matter how intelligently it gets populated.

Cheers,

Steen

View All (8)

Event When User Event Becomes Invalid

So when it comes to using a queue, there is a somewhat common design pattern used by NI examples, which makes a producer consumer loop, where the consumer uses a dequeue function with a timeout of -1. This means the function will wait forever until an event comes in. But a neat feature of this function is it also returns when the queue reference becomes invalid, which can happen if the queue reference is closed, or if the VI that created that reference stops running.

This idea is to have similar functionality when it comes to user events. I have a common design pattern with a publisher subscriber design where a user event is created and multiple loops register for it. If for some reason the main VI stops, that reference becomes invalid but my other asynchronous loops will continue running. In the past I've added a timeout case, where I check to see if the user event is still valid once every 5 seconds or so, and if it isn't then I go through my shutdown process.

What I am thinking is that there could be another event to register for, which gets generated when that user event which is registered for, becomes invalid so that polling for the validity of the user event isn't necessary.

before:

after:

Enter Equation In Numeric

View All (4)

Fix the LabVIEW Compare Tool

The compare tool is fundamentally broken which is somewhat shocking considering that such a tool is essential to any sort of large scale or long term software development.

Attached is a basic LV 2023 example which illustrates some of the many flaws with the tool. If you compare "old version" and "new version" vi without including cosmetic changes, the tool shows 33 differences, most of which are incorrect.

View All (1)

I would like to introduce a little shorthand for creating numeric constants with non-decimal radix. New constants should be able to autoadapt for radix, much like they do for type: Drop a constant, enter '0x20' or 'x20' to get a constant with Hex radix (visible!), and the proper value.

In addition, it would be nice if automatic conversions would take place if radix specifiers are entered into (non-hex) constants (or controls). For example, entering '0x20' into a numeric control with decimal radix should result in a value of 32 being entered (auto conversion). Hex is an exception, obviously, because b and d are already valid. The other radices have no such problem.

View All (1)

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)

View All (6)

Make "New" mean something

View All (2)

LabVIEW Idea Exchange

Find and open cloned instance of the VI for debug

Allow Data in Wires to be Forced During Development

Label to Object (Quick Change) upgrade to Object/Label to Object/Label

Allow single output function / VI label to override wire name

Supercharge Quick Drop - Turn QD keyboard shortcuts into first class citizens

Shift Delete to remove structure (in stead of deleting it)

Bleach Dead Code

Improve text editing in the VI Properties Documentation Window.

All long pulldown lists should have a vertical scrollbar

Type Specialization Structure Error Message

Show inherited VIs as "ghosts" under child class in project tree

Drag & drop to replace

Event When User Event Becomes Invalid

Enter Equation In Numeric

Fix the LabVIEW Compare Tool

Autoadapt numeric constant radix plus automatic radix conversions

Automatically Display Value in Tip Strip for String and Path Constants

String control/indicator/constant with line number display.

Make "New" mean something

Control all the 4 [6] colors of Booleans from their Properties page