LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

LabVIEW classes are how you create new data types in LabVIEW. But part of being a new LV data type is having a front panel representation. Although users can write XControls for displaying their classes, and they can put those XControls in the palettes, whenever a user of their class chooses "Create Control" or "Create Indicator" for the LabVIEW class terminal, they get the cube display. In order to really add a new data type to LabVIEW that behaves as well as, for example, the Timestampp or the Waveform, there needs to be some way to associate a class with an XControl and say, "This particular XControl should be used as this class' default control/indicator whenever one needs to be built." (To prevent infinite recursion and load dependency problems, whenever you did Create Control/Indicator on a member VI of the class, users would still get the cube control/indicator.)

View All (3)

In LV 2011, an asynchronous Call By Reference feature was added to LV. This feature added two new nodes:

Start Asynchronous Call
Wait On Asynchronous Call

It would be nice if there was a way to use the LV event structure to wait for the results of an async call. For example:

I am not necessarily proposing this is the way to integrate the ACBR with the event structure, it is just one suggestion. Instead, I hope this idea can gage the amount of interest in some sort of event structure integration. If anyone has any better ideas or suggestions, please say so in the comment.

View All (4)

View All (3)

I continually find myself fussing over the "configuration" of terminals. There are many permutations of icon/condensed view and label alignment, yet little consensus thus far for a standard.

My goal is to convince you this: Having different "flavors" of terminals does not make LabVIEW easier to understand or more "customized" to your preferences or learning style. Instead, it creates a source of confusion for new users to identify these Block Diagram components, and creates a hassle when it comes to formatting new or existing VIs to "your style". And no more label gymnastics trying to fit what should be a into a or a .

Just a few Common Terminal Configurations:

Default Alignment - Not too bad, but not so great for stacking terminals vertically
Block Diagram Cleanup Tool - Interesting choice of label alignment...
CTRL+Space then CTRL+T - This is the "best" style, but it falls short in correctly aligning label in Icon View (arguably of inconsequence, since Icon View is not "best" style)
The "Rogue Drag" alignment - Now where'd that label go?
The "Monk" alignment - Everything has to be perfectly snapped to center
The "There's a 'Size to Text'??" alignment - AKA - "This is what happens when I open your VI on my system" alignment
The "Don't Stop - Believing - Hold on to that Feeeeling" label - I can't let go of LV 4.0 or Power Ballads
The "But it takes up too much BD space - I'm'a remember what it's called" guy - or worse - "Neat, terminals can all have blank labels!!"

Oh yeah, and to add to the confusion of configuration permutations, we have some more ingredients:

Many Ideas - some very popular - have hinged around Terminal Configuration. Respectfully, I think they should all be supplanted by this Idea. The goal here is to eliminate even the need for a configuration:

The prelim artwork is an attempt for an information-dense, easily-recognizable, same-footprint, attractive alternative to the current terminal configurations. It offers no display configuration, always showing the label for the sake of self-documentation. It was designed to complement the Improved Control References and the New LV2010 Local Variables. I would envision being able to double-click on the integrated label in order to rename the node.

For completeness, here's what an array would look like. Or perhaps, one of the array alternatives on the Redesign Terminals Idea that focuses on the inability to clearly show array dimensions with the currently implemented terminal:

Finally, you're not voting for my artwork, you're voting for this concept: Standardize terminal configuration to make it non-configurable, robust against self-documentation SNAFUs, and universally recognizable. Just like the zero-config behavior of the Local Variable, we want a what-you-drop-is-what-you-get Terminal.

View All (7)

Compound Close References

When using extensive numbers of property and invoke nodes (for example, using the TestStand API) it's very common to end up with many references that need to be closed. This leads to structures like this:

It would be very convenient if we had a Compound Close References node that we could wire multiple references into. Since order often matters with closing references, the node could execute top-down once all references are available at the inputs. This would substantially clean up block diagrams and make API code a bit easier to follow. For example, the above code could just be replaced with:

View All (2)

Improved PPL Debugging

I've encountered quite a few limitations when debugging debuggable PPLs, and feel that a number of improvements could be made to this process. I often find myself having to open a second project with the specific dev library in it, and then toggling back and forth between the two which is both confusing and inefficient. This is just scratching the surface, but here are some improvements I'd like to see made:

Non-editing menu options should remain available. One I use quite commonly: right-click on a class cube, and select "Show Class Library". But it's not available:

The workaround I use is to "Copy Data", press ctrl+n to create a new VI, drop the class cube there, and then right-click on that and select "Show Class Library", then toggle back to the temporary VI and close it.
VI Properties aren't available in VIs:

I often want to double-check reentrancy settings on VIs to ensure everything's configured correctly.
Private class data isn't shown. I get why this isn't available in non-debuggable PPLs, and I understand that there's a healthy debate that can be had as to whether or not this should be available in debuggable PPLs. I'm of the opinion that private data should be available in debuggable PPLs as they are meant for debugging, not for distribution.
Private class methods don't show up in the project. But if you click on the sub VI for a private method, you can open up the block diagram. If the block diagram is accessible, it really should show up in the project. I often find myself searching for a VI in the project, and not finding it anywhere, because the method is private.
Unusual interactions. I've seen a number of scenarios where I'm prompted with requests that I shouldn't be asked. For instance, if I double-click on a malleable VI in a PPL's block diagram, I get this popup:

Currently if code is already written, it is difficult to put it into a sequence structure, splitting the code into multiple frames, without breaking wires. It would be great if when I right clicked on the edge of a sequence structure and chose "add frame after" it allowed me to draw the next frame before placing it.

I would also like to be able to selectively split an existing frame up

Wouldn't this be easy and intuitive?

I tried to look for other ideas like this on the exchange and all I found was this but he was a little confusing in explaining his idea and how would it work.

View All (10)

For as long as I can remember (I have used LabView since 4.0) the decorations and contropls pallette have remained unchanges for the most part. End users want an application more like the iPhone than windows98. We need a new decorations capability to be able to customize controls to a high level. The square circle and triangle of 2 colors and flat or 3d/rounded nolonger cuts it. I would like to see a new type of decoration.

- Decoration made of vector graphics so it is scalable, user can add or remove verticies and move them around to make new shapes.

- Labview native color pallet linked to item colors (default can be 2 color option of FG, BG but scale this to an array of colors to make more complex decorations)

- Colors add transparancy and alpha channel

- Grouping allows building of a single new decoration from several primitive shapes.

- Decoration possible support gradients (color blending)

*** Decorations should have optional labels so that they can be addressed programatically

-Decorations added to customized controls that have lables associated with them become part of the control and can be accessed via a property (ie can be set to not visible through a property node)

I know this is asking quite alot, but I have found that when I make my applications not look like LabView (and it is easy to spot a LabView application) it is not a well recieved as when I present a highly customized application that does not look like a labview example. Allowing the community to easily create very professional looking new controls and indicators will do wonders for our GUIs.

View All (3)

View All (7)

Local Variables. When a VI has a hell of a lot of Controls or Indicators, creating a Local Variable can be a pain. The list to choose from can get very, very long, sometimes so long that it needs a scrollbar.

The current method of selecting which control a Local is connect to looks like so:

All in all, not too bad. I like the alphabetical ordering, and the fact that you can type to choose one.

However, from this image you have no idea what datatype each of these variables are (the name helps a bit). I suggest adding the Data Type and Control/Indicator information to this menu like so:

You can now easily see that "Params" is a cluster control, "XY Graphs" is an array of Refnums control, and "Vg Points" is an indicator array of I32. Notice that the datatypes are color coded and look similar to the block diagram icon.

In addition to this simple display change, it would be nice if there were an option somewhere in the preferences that sorted this list in different ways. Perhaps two different options: 1. First by Alpha, then by Type - or 2. First by Type, then by Alpha.

For those of you who prepend a data qualifier to the beginning of your controls and indicators (such as "str_Input1" or "dbl_Numeric"), this will still help you via the color coding. Plus you probably don't do that for ALL your controls, ones that end-users will be modifying when you release your code.

View All (7)

Fit to pane = Fit to tab

Using "Fit control to pane" and the "Scale Object with Pane" options it is now relatively simple to build front panels that scale the way users are used to from other applications - however there is one shortcoming that it is easy to run into: cases where you want a tab and (some of) the controls (a table e.g.) on it to scale with a pane.

Getting the tab to fit and scale is a done deal, but then comes the scaling of the objects on the tab...

The option you have today is to fit the controls on the tab to the pane...however that does not give a proper behaviour because then they grow larger than the tab they are on. Objects that are set to fit and scale to the pane should basically use the tab as their "pane" - not the pane the tab is on.

View All (6)

There should be an option to fully enable optimization when building an application as to automatically remove performance impacts caused by diagram elements that shouldn't cause any.

As summarily declined by NI, this idea

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Improve-Diagram-Disable-performance/idc-p/3253939#M34372

shows that unless you manually go over ALL your VIs disabling debugging, Diagram Disables (that are supposed to not avoid executing some code!) you'll suffer a performance impact.

It is preposterous to expect the users to manually disable/reenable debugging on every single VI when building an application.

Please add an option to enable full optimization.

I don't know how many times I've built an application or packed library during my 25+ years using LabVIEW. What still annoys me extremely much is when the AppBuilder gets a tiny error, like "wasn't able to copy this file" (always at the END of the job), or something else having no effect on the (already built and completed) application or PPL itself. Still AppBuilder deletes the whole build, sometimes 30+ minutes time wasted, and simply tells you the build "FAILED".

My suggestion is: Make AppBuilder just a tad smarter and don't delete the EXE or PPL! Just let the developer know what file(s) to copy manually, or what post action didn't work!

It's useful that we can open the Error List window via the Ctrl + L shortcut.

It would be great to have keyboard shortcuts that allowed us to navigate to the next and previous errors (broken run arrow locations). This would be similar to how Ctrl + G and Ctrl + Shift + G can be used to navigate to the next and previous result in the Search Results window.

I would be happy with any key combinations chosen for this purpose.

Thanks

View All (2)

Current Behavior:

When using the "retain all errors" option of the Merge Errors function the combined error message JSON output is not a valid JSON string.

This is the source output of Merge Errors when retain all errors is active - it is not a valid JSON string.

<JSONErrorMultiple_1.0>[{
    "status": true,
    "code": 111,
    "source": "This is a test message including\nnewlines"
},{
    "status": true,
    "code": 222,
    "source": "This is a test message including\nnewlines"
}]

Desired Behavior:

Make the combined errors source string a valid JSON string so that it can be parsed by other tools.

Valid JSON string:

[{"status":true,"code":111,"source":"This is a test message including\nnewlines"},{"status":true,"code":222,"source":"This is a test message including\nnewlines"}]

The above JSON string can be formatted nicely by most tools - e.g. JSON pretty print - https://jsonformatter.org/json-pretty-print

The below string including the JSONErrorMultiple_1.0 key (but formatted correctly) also works:

{"<JSONErrorMultiple_1.0>":[{"status": true,"code": 111,"source": "This is a test message including\nnewlines"},{"status": true,"code": 222,"source": "This is a test message including\nnewlines"}]}

When dragging a control / indicator label or caption, if you move within a certain distance from the owning terminal the label will snap to one of a set of given positions (top-left, top-middle etc). Outside this distance (or if the user presses the spacebar to toggle this behaviour), the label can be freely positioned.

The selector terminal for a polymorphic VI should display the same behaviour with regard to the owning VI icon. A polymorphic selector is currently always free-floating.

LabVIEW Idea Exchange

Tag an XControl as the default control/indicator for a LabVIEW class

Integrate Asynchronous Call By Reference with Event Structure

programmatically create and delete controls dynamically at run time (G Type?)

Synchronize "right-click options" with properties dialog.

Block Diagram Terminals Improvement

Compound Close References

Improved PPL Debugging

Add Frame After and Split Frame in Sequence Structure

Improved decoration and control graphics

Allow Drag and Drop of Images into Icon Editor from Disk

Add datatype info to "Select Items" menu of a Local Variable

Fit to pane = Fit to tab

Add an option to disable debugging/enable optimization when building application

PLEASE make LabVIEW Application Builder just a tiny bit less stupid!

Keyboard shortcut to navigate to the next edit-time error (broken run arrow reason)

Retain all errors option of Merge Errors.vi does not output a valid JSON string

Polymorphic VI Selector should snap to VI icon when dragging

Coordinated Autoscale of multiple axis

Block diagram Clean Up Tool improvement - loop conditional terminal

If diff has no panel differences, show the block diagram on top