LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

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)

It's a little annoying to try to draw long wires to a terminal that's currently off screen -- you have to hold your mouse at the edge of the screen and LabVIEW slowly scrolls the window (Shift will speed this up a little bit). Currently, neither the mouse wheel nor the touch pad work for panning/scrolling while a wire is currently in progress.

As an improvement, it would be great if the mouse wheel allowed panning the diagram while the new wire was still in progress.

See the attached video.

View All (1)

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)

Idea:

So my idea is to add an optional parameter "ObjectRef" to both GObject methods "Replace" and "Replace No Attributes":

My request is mostly for replacing a control or a constant, but the proposed formalism could also work to replace any Node (SubVI, Structure, ...), a Diagram, a Panel, a Pane... by copying the properties and content of an existing one in memory.

Reasons:

Often in my scripting, I need to replace a control or a constant by copying an existing one. Most of the time, this is to change its data type, but also sometimes its style.

The current GObject methods "Replace" and "Replace No Attributes" are very handy to replace a control or a constant while maintaining their links to the other objects on the diagram, provided that you have the path to an existing (saved) .ctl file to give as a parameter to the method.

If the data type is not a type definition or is an unsaved type definition, things get complicated. This can happen and I don't have control over the data types passed to my tool.

To achieve this, I found 2 techniques:

1. Replace by a temporary Control file:

- Create a new VI of type "Control VI";

- Drop a new control using VI methods "Create from Data Type" or "Create from Reference";

- Save the .ctl file to a temporary path;

- Use method GObject.Replace with parameter "Path" on the old control / constant .

This works in most cases except when the data type contains out-of-scope typedefs. I can then work around this by disconnecting the typedefs and replacing sub-elements by path as a post-process, unless some typedefs are not saved by the user...

2. Recode the Replace method from scratch:

- Drop a new control / constant using VI methods "Create from Data Type" or "Create from Reference";

- Copy all relevant properties from the old control / constant to the new one;

- Reconnected its terminal to the wire on the block diagram if needed;

- For a control, relink locals, linked properties nodes, linked method nodes, references;

- For a control, reassign it to the connector pane if needed...

- ...

- Delete the old control / constant.

This is a lot of work, seems quite inefficient and also is not future proof in case new properties are added to controls.

Regards,

Raphaël.

View All (8)

DIff String Constants in LVCompare

In Windows File Explorer, Alt + double-click on a file or folder pops up that item's Properties page. It is equivalent to right-clicking and selecting Properties. This is a useful, time-saving keyboard shortcut/gesture.

The same keyboard shortcut/gesture should work in the Project Explorer. Executing the shortcut would pop up the Properties window of whichever item was double-clicked on.

The shortcut should work for lvclass and lvlib items, VIs, and CTLs (and possibly other item types too). For lvclass and lvlib items the Properties window would appear. For VIs and CTLs the VI Properties window would appear (equivalent to Ctrl + I).

Screenshot 1

1 (edited).png

Screenshot 2

2 (edited).png

Thanks

View All (4)

Background

The DAQmx apis allow streaming measurements to TDMS. This supports spanning multiple files (by setting the max file size for individual files in the span set), which is very useful.

We need a similar feature for files we're writing to directly (i.e. not using DAQmx) with the TDMS File functions in LabVIEW.

Note: The main reason we wanting this feature, right now, is that our files are growing quite large and when we run the TDMS Defragement function, we get out of memory errors in RT on cRIO (e.g. if we have 512MB RAM on our cRIO and the TDMS file is around the same size).

Alternatives

We're thinking to do this ourselves, however the TDMS file api does not support checking the file size from a TDMS file reference (and that's a great idea, too).

I'm not totally sure how this would be added to the TDMS file api -- maybe there could be a "TDMS Advanced Spanning" palette with options for configuring and interacting with TDMS spanning.

View All (1)

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)

Idea: The Assert Structural Type Match node should be growable (able to expand the number of inputs downwards and/or upwards). This would be similar to how many well-loved nodes can be "grown" downwards or upwards, such as Build Array, Concatenate Strings, Index Array, Merge Errors, etc.

1 (edited).png

3 Growable Nodes (edited).png

The following screenshot shows a real-world VIM that I created where I would have benefited from this feature. I needed to ensure that three inputs were all of the same data type. This required using two Assert Structural Type Match nodes. It would be possible to use a single node with three inputs if this idea was implemented. This would result in fewer wires and fewer objects on the block diagram.

View All (2)

Size of Decorations

View All (4)

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)

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)

(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)

View All (3)

When refactoring code, I often find myself in a situation where I've broken dependencies. Maybe it's a name change, or a library path change. This is precisely when I'm most in need of the ability to just replace the missing file (be it a VI, control, class, or PPL). Yet this is when LabVIEW decides that nope, it can't be that easy:

Instead you have to track down every instance and manually swap them out.

The request: allow us to replace missing files using the "Replace with..." option.

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 have wasted ~~days~~ weeks of my life tracking down why dependencies are loaded in LabVIEW.

This is because the "Why is this item in Dependencies?" tool isn't particularly useful in larger projects. And it isn't particularly useful because it highlights any file in your project (and not in the dependencies) that is dependent (no matter how indirectly) on the chosen file.

In this example, if I click on "Why is this item in Dependencies?" on library C, I get pointed to a VI in the project (A.a) which has a very indirect dependency on library C.

It would be far more useful to me if I instead only got shown the VIs that directly depended on my dependency (even if they were in dependencies themselves). If I then wanted to follow this up the chain, I could just click on "Why is this item in Dependencies?" again, but on the found item.

When selecting a set of object that are from the same class, I'd like to be able to change some of their main properties at once from the right click menu.

For instance, when selecting a bunch of numeric controls, being able to change all their representation to U8 without having to open the property page (which sometimes take some time to load.

This could be done either via the r.click option, or even via the properties page that would show that it is for more than 1 item. Via the property page

From the property page, it would be nice to have the possibility to easily change their label and caption independently and faster (using tab) than to have to change them manually by double clinking on the labels, hoping to not click on the side of the box.

This happens to me all the time:

This could be a viable option in my opinion (Please excuse my poor designer capabilities):

- Vincent.

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)

LabVIEW Idea Exchange

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

Allow mouse wheel(s) to pan diagram while wiring in progress

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

Method to replace a Control/Constant from a template object in memory

DIff String Constants in LVCompare

New keyboard shortcut: Alt + double-click to open Properties in Project Explorer (similar to Windows File Explorer gesture)

Need "TDMS Advanced Spanning" api -- an easy way to span TDMS files and limit individual file size

MyLabVIEW

The Assert Structural Type Match node should be growable

Size of Decorations

Allow Data in Wires to be Forced During Development

Visual indication that VI will run even on error

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

Connector pane double click terminal jumps to control

Move Conditional and Iteration to the "Visible Items" submenu

Enable "Replace with..." when dependency not found in project.

Improve text editing in the VI Properties Documentation Window.

"Why is this item in Dependencies" should only show items that are directly dependent on it

Bulk change common properties of object from the same class (Like numeric representation)

Active Structure Debug Indication