LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

My front panels are typically large tab controls so most of the FP design and editing takes place on tabs.

In this scenario we lose significant usability, for example:

We cannot double click on empty space to create a free label
We cannot see the alignment grid.
...

Proposal:

The background alignment grid should continue across tab controls and other containers (e.g. clusters) in edit mode.
double-clicking inside an empty area on a tab should start a free label operation, same as on the plain background. (only clicking near the border should "find" the terminal instead).

View All (3)

This is similar to the idea about moving items in the connector pane and is an extension of it for any input or output on the block diagram -

Often, you connect a wire to a wrong input or output. Today, fixing it requires wiring to the new location and manually deleting the old piece of wire. The only exception is two-input functions with both inputs already wired, where you have a keyboard shortcut for swapping the wires.

A much more natural and general method would be this - if you use the wiring tool on a wire source or sink and then on another, the wires should be swapped (or if there's only one wire, it should be moved).

In this example I wired the 7 into the wrong input and I want to move it one input down, so I:

1. Click the top input. This "grabs" the wire, so to speak.

2. Click the bottom input. This moves the grabbed wire to that input.

Message Edited by Support on 10-22-2009 01:25 PM

HABF?

An acronym for one of my favorite Spolskyisms. Great article, read it.

Background

When you discover what you consider to be a bug in LabVIEW's IDE or language, it's a difficult process to report the bug and track the bug's status as new LabVIEW editions debut. This idea addresses the transparency and facilitation of this process, and is meant to appeal to both those who create LabVIEW and those who use LabVIEW.

Problems with Current Issue Tracking Platform

"Platform" is a generous term for the current reporting and tracking process:

The issue reporting procedure is undocumented - few seem to know how to report issues, fewer know how to track documented issues
Issue tracking status is largely monitored by a squad of Dedicated Volunteer Bug Scrapers
Duplication of effort (for users, AE's, and R&D) is probable since there is not a centralized, searchable repository
Relies on unreliable methods including email, FTP uploads, phone conversations, forums...

Comparing LabVIEW Issue Tracking and Feature Tracking Platforms

Before the Idea Exchange, there was the Product Suggestion Center (PSC). What's that, you ask? It's a hole in the internet you threw your good Ideas into. The Idea Exchange revolutionized Feature Suggestions by introducing a platform that allows an unprecedented level of public brainstorming and symbiotic discussions between R&D and customers. Further, we can watch Ideas flow from inception to implementation.

I want to see an analogue for Issue Tracking.

Proposed Solution

A web-based platform with the following capabilities:

Allows users to interactively search a known bug database. Knowing the status of a bug (not yet reported, pending fix for next release, already fixed in new release...) will minimize duplicated effort
Allow embedded video screen captures (such as Jing)
Allow uploaded files that demonstrate reproduceable issues
Allow different "Access Levels" for different bug types. View and Modify permissions should be settable based on User ID, User Group, etc... (Some types of bugs should not be public)
Allow different access levels for content within one bug report. For instance, a customer may want a bug report to be public and searchable, yet attach Private Access Level to proprietary uploads.
Allow collaborative involvement for adding content to Bug Reports, where any member can upload additional information (given they have Modify Access Level privileges)
The Homepage of the Issue Tracker should be accessible and visible through ni.com (maybe IDE too, such as a GSW link)
A more detailed Bugfix Report for each LabVIEW debut (cryptic subject lines on the current Bugfix List is not helpful)
Specific fields such as Related Bug Reports and Related Forum Posts that allow easily-identifiable cross-referencing.
An email-based alert system, letting you know when the status or content changes in bug reports of interest ()
Same username and logon as the Forums
Bonus: Visible download links to patches and other bug-related minutiae

Additional Thoughts

I have used the Issue Tracking platform used in Betas, and the exposed featureset is too lacking to fulfill the spirit of this Idea
I realize the initial and ongoing investment for such a system is high compared to most Ideas on the Exchange. Both issue tracking and economics are sensitive issues, but the resultant increase in product stability and customer confidence makes the discussion worth having.
Just to clarify, a perfectly acceptable (and desirable) action is to choose an established issue-tracking service provider (perhaps one of NI's current web service providers carries an acceptable solution?), not create this behemoth in-house.

(Picture first spotted on Breakpoint)

Generally: you are voting for a platform that eases the burden of Issue Reporting, additionally offering a means of Issue Tracking.

My suggestions are neither concrete nor comprehensive: please voice further suggestions, requirements, or criticisms in the Comments Section!

View All (14)

I often create maps in a for loop, as shown below. However, the "Insert Into Map" value input doesn't adapt to the value type, leading to extra hurdles in order to create the correct map constant to feed into the for loop/VI.

It'd be cool if I didn't have to do the extra work to create this map constant. Ideally I'd be able to wire any value type into the "Insert into Map" VI, and then just right-click on the output terminal and select "create constant".

(It appears that you can now drag and drop a value type into a map constant which does make it easier, previously I would "build map" node in, get the constant it from it, and then delete it. Either way, it's still extra steps.)

At my work we often have structures inside structures several to many layers deep. We try to keep the inner most ones small to keep things to a single screen size overall if possible. But this causes a problem when you have to move an item inside a structure that it currently doesn't fit in. you first have to make room somehow for the structure to get bigger then you can drag the item inside and again shrink the surroundings (the last step can get really ugly when you have multiple layered structures or a lot going on around the outside).

So what if instead of moving the item into the structure you could move the structure around the item. If you could CTL+drag an edge, and instead of trying to push everything around the structure out of the way as it grows, it instead envelops the items you drag over (or spitting them out if you decrease the size). Same basic behaviors as dragging an item into or out of a structure but from the reference frame of the structure instead of the item (or the other way around, not sure how to describe it, kind of like plotting the motion the earth from the suns perspective or the motion of the sun from the earths perspective, they are both fundamentally wrong but both very useful for different tasks).

goes to or vice versa where the only thing that was moved would have been the right side of the inner case structure while holding CTL (or shift or alt or some other equally suitable special key)

I am guessing that it is not a simple request but would be very helpful to me on at least a daily basis.

View All (1)

Parallelisation of loops is a great thing in LabView that offers a lot of possibilities and it's very easy to implement. In opposite to this debugging can drive you crazy regularly. A typical situation for me is that there are two loops in parallel whereby the first waits for user input (and handles it) and a second one cycles all the time doing some other stuff.

Assumed that the one with the user event handler needs to be debugged I place a break-point on a good place. When the execution stops there, I usually want to go step by step through the code. The problem is now the 2nd loop: because it is running in parallel the execution pointer jumps always between the two loops. I have to step through each function of both loops even that I only interested in the first one.

This becomes very annoying, confusing and time consuming if there is a lot of code in the 2nd loop, if the diagram becomes larger at all and if the highlight mode is activated.

To avoid this I suggest to show optional elements for debugging for each loop. With those elements I could decide if I only want to step through the code of the first loop while the second is executed normally (no highlighting, no single step).

Current situation:

improved functionality:

View All (9)

As described here, the Event Structure has a few interface issues. One of which is that the "Rearrange Case" Dialog window is not resizable, and the "Complete selector string" has no scrollbar:

If you have dozens of cases, some of which may contain a dozen different events, this is a nightmare to use.

Don't get me started on the way you can rearrange cases only by dragging and dropping one at a time (ever heard of alphabetical sorting for instance?)!

Thanks for reading.

View All (1)

The Property class, which represents the property node, has a property called All Supported Properties which ideally would show all the properties supported by the class the property node is linked to.

The problem is that it doesn't. If you have nested properties which come from another class (for example, the properties for the caption which can be selected by opening the pull right menu, as seen in the top image), those properties aren't returned when you call the property, and instead you just get the property for the caption reference, as seen in the bottom image, where the ControlIndex property is shown immediately after the Caption property.

Instead, I want either this property or a new property to return all of the nested properties as well, just like you get in the UI.

This would be useful for setting properties using scripting and alternate UIs (like this one or this one, which can't work today, because they can't get the full list of properties).

Add LV version info to Help

View All (2)

Sometimes you have to read a lot of shared, local or global variables in sequential order. In this case, it can be a bit "boring" having to drag all the variables by hand. In addition, if you are reading shared variables, you also have to wire all the error cluster inputs and outputs. It could be useful to implement something similar to a property node or a Read/Write Control FPGA Node that you can resize and select which variable must be read or written in each position of the node as you can see in the following image:

View All (2)

Allow 45 Degree Free Labels

View All (4)

LINQ-like query nodes

It would be useful to have something similar to C#'s LINQ in LabVIEW. Basically a way to "query" array of clusters/objects (and for some nodes even array of strings/numbers/whatever) without needing to use loops. I imagine nodes similar to invoke nodes, something like the below examples:

Query Nodes.png

If one wired an array of clusters one should be able to choose from the elements in the cluster, like an Unbundle By Name node. For the Where node one should subsequently be able to select how to filter based on the data type of the selected element. For example: Equals, Greater Than, Less Than, Greater or Equal to, In Range, etc. for numbers. Equals, Contains, Starts With, Ends With, etc. for strings.

When right click on a cluster and selecting "Reorder controls in cluster..." the bloody control indexes hide the labels of the controls in the cluster, rendering it difficult to select which ones should be in which order. How does the programmer distinguish between one or another control??!!!??? :mad:

Hopefully the image below is worth 1000 words. And yes, I did resize the cluster in the hope that the re-order index would go further to the right of the control, but it didn't.

This is something that needs to be fixed. It should actually be considered a bug rather than a product enhancement.

When dealing with a small cluster, it might be okay... but when dealing with clusters having over 200 controls, setting the proper order in a royal pain!

Download All

View All (1)

Every time I need to open up several VI's at the same time, my Windows Taskbar becomes full of open windows and it gets hard to wade through everything. Part of the reason for this is that every time a VI is opened, two windows have to be opened to view the block diagram (both the front panel and the block diagram). I would like to see a fix that allows me to just have several block diagrams open at one time without their front panels, making it easier to deal with the numerous open windows I get sometimes.

Duplicating graph scale programmatically

We can duplicate a graph scale by right click, but we cannot do it when the VI is running.
It's better that we can duplicate and delete a scale both manually and programmatically on running VI.

For programmatic approach, I suggest invoked method like this:

Download All

View All (3)

Strict typedefs and non-strict typedefs differ significantly. There's too much of a gap for me. Sometimes I'd love a control to be somewhere in between.

There have been times where I wanted to force a typedef to have a constant size or colour or other parameters without having to force all other parameters to be identical.

It would be nice if a typedef could simply be gradually converted to strict by selecting which parameters are locked. That way we could shoose to long only boolean text, width or colour but leave the other properties free. VI Server would need to return an error that the type definition does no0t allow that change, but that is kind of already there for when you try to change properties of a strict typedef.

So by default a typedef would refer to data only (See HERE) but any further cosmetic changes (to which the datatype does NOT belong) we could simply select which parameters are locked and be done with it.

Run-Time Menus with Icons / Glyphs

When was the last time NI updated the Run-Time Menu Editor?

Yes, it's been a looooong time 😉

I think this should be put on the road map as soon as possible.

The user should be able to define glyphs that are shown next to the menu items, just like in any modern UI library.

The RTM editor itself could use a complete rework, too. At the moment that's not what I'd call use-friendly (you can't even resize the window!).

This applies both to run-time menus of VIs as well as controls and menus that are called programmatically.

No, I don't attach an image here - just click into the menu bar of any remotely modern application on your computer to get an example of what I'm talking about 😉

LabVIEW Idea Exchange

Improvements for editing on tab controls

Use the wiring tool to swap inputs or outputs which have been wired incorrectly

HABF: A New Platform for Issue Tracking in LabVIEW IDE

"Insert Into Map" VI: Adapt to Value Input

CTL + drag structure edge to envelop items outside

improved Debugging for parallel loops (optional / selective debugging)

Rejuvenate the "Rearrange Case" window of the Event Structure

Make the All Supported Properties property return nested properties

Add LV version info to Help

Compare aggregates option for scalar comparisons

Always Show Abort Button on Block Diagram

Implement Variable Nodes similar to Property Nodes

Allow 45 Degree Free Labels

LINQ-like query nodes

Do not hide cluster control label when re-order controls

Allow the Front Panel Window to be Closed While Keeping the Block Diagram Open

Duplicating graph scale programmatically

Add the ablity to monitor a compiled executable to "Profile Perfomance and Memory Monitor"

Bridging the gap between strict and non-strict typedef

Run-Time Menus with Icons / Glyphs