LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

View All (3)

Have you ever placed a background image on your front panel to make it look good, but then found that most of the controls and indicators covered everything up?

Ever wish LabVIEW had more appearance customization to make better looking GUIs?

I would like to propose an opacity slider control in the appearance settings tab of front panel object properties. The added setting would not make the entire objects opacity change; ideally the opacity control would only affect the borders and grey space. With this added control users can make better looking user interfaces without having to make custom controls.

Take a look at the difference:

Not Ideal Front Panel with background image and NO Opacity Control

Beautiful Front Panel with background image that you can still see by setting Opacity Control to 50%

Before and After Appearance Settings tab in the Properties Window for a waveform graph:

Currently the only easy way to implement a similar type of setting is go fully transparent by using the tools palette paintbrush tool and setting the color to transparent:

Kudos and share this idea if you want it to happen!

View All (9)

We have (collectively) complained about coercion dots many times on various LV forums -- they are nearly invisible and there are three different kinds, which require different levels of concern. The problem is that there are very few pixels within a terminal and there's no space for any pattern to differentiate the three kinds of coercion (and changing colors is a problem for reasons discussed here in the Idea Exchange).

Another LV developer had an idea that I liked: add an option to view giant coercion dots. We have avoided this because coercion dots bigger than the terminal would interfere with wiring. However, many developers have a policy of eliminating all coercion dots on their diagrams. For those who have such a policy, they could eliminate the coercion dots as they work, and thus might not see any problem from such large dots. Large dots would solve lots of other usability problems that coercion dots have today.

This option could be something in Tools>>Options, but I'd rather it be something in the View or Edit menus so it can be quickly toggled on or off with a shortcut key.

These graphics are "programmer art" -- I just made the three dots look different. Please sumit alternate images for the three dot types if you have better style suggestions. I did make the three dots differ in both pattern and color so that we avoid problems with colorblindness. The type-only was a solid dot, the widening coercion is a bulls eye, and the narrowing coercion is a single ring. Any redesign should definitely take colorblindess into account.

View All (5)

MyLabVIEW

Yup, Upgrading LabVIEW versions takes a day.

The "Process" today is:

Install from media
Configure the new LabVIEW.ini
install tookits (OpenG, Deploy, VIPM, TSVNtk.....)
Mass Compile all them......
Fix palatte views... and import and mass compile User.lib\ for here.....
Sync glyphs on the icon editor (If the link works......)
Add VIT's
Add Project Templates
Mass compileVIt's and Templates
fix "Metadata.xml"...

Yup, about a day of watching paint dry...........mass compiling, ignoring warnings etc......

"MyLabVIEW" would find all of those customizations and import them to the new version!

View All (1)

Title basically says it all but I'll elaborate. With increasing monitor resolution, a 16x16 glyph on a listbox doesn't work very well. On a 4K monitor this is awful tiny. This idea is to support larger glyphs in Listboxes, Multi-column Listboxes, and Trees. Glyphs are used in several places but on favorite of mine is to have item selection with checkboxes, example here. Allowing for these glyphs to grow with the row height would make them appear more cohesive. There is a thread discussing this topic, and a work around involving an array of picture rings that is placed over the listbox control. Here is a demo from that thread:

This work around is fine for simple things but doesn't scale well, and doesn't support trees easily. I for instance want to have two trees, where a user can drag and drop from one to the other with the larger glyphs coming along with the drop. Having to handle where the user dropped, and then dynamically building the glyphs to overlay on top of the tree, with indentation, and hiding when a tree's leaf is closed is a major pain. Please NI add a feature allowing for larger glyphs, and I would be so happy.

I've had enough! Your code does not have to look like this:

Or this:

You don't have to wire a string into Build Path's second input! It can take a relative path just fine! This is particularly helpful when building relative paths that involve climbing a directory structure. But it's also useful for building hard-coded folder paths, or even just specifying a file name:

I've seen code that looks like the first two images way too often, so I propose the following:

Change the name of the second input of the Build Path function to 'relative path or name'.
Change the default data type of this input (i.e. what it looks like when unwired) to path instead of string.

The function will still work fine with string inputs (so existing code is fine), but this approach encourages developers to actually use the path data type when working with paths. You should kudo this idea if you have ever (1) written code that looks like the first two images, (2) needed to explain to someone that they can wire a path into Build Path's second input, or (3) gotten burned by multi-platform issues when somebody typed path separators into a string wired into Build Path.

Size of Decorations

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)

NXG had a neat feature I miss in LabVIEW 20xx and that is resizable nodes for operations like OR, AND, and Add. There are other nodes that could benefit from this too like subtract and multiply, but here is the idea.

Resize Nodes.png

I'm aware that the Compound Arithmetic is a resizable node that covers the examples I have here. But often times I will start with just two inputs so I'll use the OR, then later on I'll need to add a node and now I need to replace it with the Compound Arithmetic and then add the other inputs. If the suggestion is to just use Compound Arithmetic, then why even have an OR node?

I really like having two different default locations for my terminal labels. What I do not like so much is that I still end up dragging a lot of labels around after changing a control to an indicator or indicator to control. I would like it if the label location was automatically moved to the default position when the direction of a terminal is changed.

You could get fancy and only move it if it is currently in the default location, I'd prefer it to always be moved. And I am not interested in the Quick Drop shortcut here. I do not want a quick way to clean up the mess I do not want the mess made in the first place.

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

View All (3)

Active Structure Debug Indication

When entering debug mode (turn execution highlight on) it can be hard to see what is happening.

With event structures it can be hard, but there are subtile changes. Sometimes it's impossible. For instance, if you run this VI, and wait a while, it is impossible to why the VI has not stopped. In this case it's easy to deduce, but it can be really hard. Probes also don't provide a solution here...

SubVI's get a green arrow when they are executing. So, could structures get them as well?

View All (2)

(This is an idea related to Jack's idea here, which however deals with "reshape array".)

When using "built array" with parts that are mismatched in lenght, the largest input wins and the rest are padded with the default value for the given datatype (zero for numerics). This is often not desirable, for example when graphing multiple plots.

Padding with zero causes extra data (zeroes) to show on the graph that did not exist in the original wires. A more desirable option here would be to pad with NaN so only actual data is graphed.

My suggestion is to add an optional input to "built array" that allows defining the pad value is case the inputs are mismatched.

Here is an example how it could look like. (of course the icon would probably need to change a little)

View All (2)

This has been discussed in various places like here, but I couldn't find an idea for it...

There are quite a few LabVIEW primitives which will always run, even if presented with an error on the "error in" terminal. Common examples are "Close Reference" and "Close File".

What would be really useful is to have some kind of visual indication of this behaviour. Ideally this would be a simple marking on the VI icon which could be easily replicated by LV users when we create such VIs ourselves. (It could possibly even be an option in the icon editor!)

Currently the only indication that a VI will run on error is this discrete line in the VI help:

I believe a visual indicator would be much more fitting for LabVIEW as a visual language, and would make this behaviour far more obvious to LabVIEW users.

View All (3)

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)

Multiple Wire Insert

View All (1)

LabVIEW Idea Exchange

Bring back the State Diagram Editor

Opacity/Semi-Transparency appearance settings for attractive Front Panel objects and User Interfaces

View >> Gigantic Coercion Dots (now with a variety of colors)

MyLabVIEW

Support Larger Glyphs in Listboxes and Trees

Make It More Obvious that Build Path Can Accept a Relative Path Input

Size of Decorations

Fix the LabVIEW Compare Tool

Resizable Boolean and Numeric Operations

Obey default label position when changing from control to indicator and vice versa

Find and open cloned instance of the VI for debug

Type Specialization Structure Error Message

Connector pane double click terminal jumps to control

Property Nodes Should use Enums

Active Structure Debug Indication

Add a Terminal that Defines Default Data for building arrays from mismatched parts

Visual indication that VI will run even on error

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

Allow Data in Wires to be Forced During Development

Multiple Wire Insert