LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

After some searching, this ideas was already discussed in the comments of this declined idea. but I think it deserves to stand on its own, so here we go.

We have a nice menu entry "Menu...Edit...Make current values default" that (if nothing is selected) does just that. In 99% of my cases only the controls are important, because all the indicators, while often containing tons of data (graphs, arrays, etc) can be easily re-created from the control values at any time.

So while the control values are useful to be able to run a VI out-of-the-box with reasonable input values, default values for indicators just contribute to VI bloat, increasing the size on disk.

Making indicators default is useful for the rare cases where a forum users want to show what he gets or expects to get, but not in general development. Yes, we can of course select all controls first, but they might be scattered all over the panel and over several tab pages, so that's not a good solution. (We could also request a menu in addition to the "edit...select all" e.g. called "edit...select all controls", but that is probably a different idea.)

In summary, there should be a menu entry that ignores indicators when making values the default.

It should also work if multiple items are selected "Make Selected Control Values Default", in which case it would ignore any selected indicators.

View All (1)

While debugging LabVIEW, we often have many VI windows open. It can sometimes be difficult to manage these windows, especially once the debugging session is over. I think we can improve this situation greatly with a minor change to the All Windows dialog. This dialog (launched from the 'Window' pull-down or by pressing Ctrl-Shift-W) currently shows a list of all LabVIEW windows that are currently open:

There are several columns of information describing all the open windows, and the list is sortable by clicking a column header. You can multi-select in the list and click 'Close Window(s)' to close multiple windows at once.

Idea: If we add a "Time Opened" column that lists time stamps of when the windows were first opened, it would be easy to sort by that column, then close all the windows that were opened during a span of time, i.e. while debugging.

While we're at it, there are several other usability enhancements that could be made to this dialog that seem to be low-hanging fruit:

Make the window a non-modal floater, with the list dynamically updating as windows open and close.
Add a 'Minimize Window(s)' button.
Give useful key navigation to the 'Close Window(s)' button (and any other buttons we may add).

I know there are other ideas about making debugging easier (don't show panels, etc.). I'm scoping this idea to improvements we can make specifically to the All Windows dialog to make debugging easier.

View All (1)

Please let me opt out from this new feature, introduced in LabVIEW 2017, permanently in the setup dialog.

Using LabVIEW for a very long time (since LabVIEW 2.0), I never wished such a feature (it got only 27 Kudoes) - and - I am even using it's "anti feature", implemented up to now, constructively to detach objects (Pull control into a structure, connect it to the new target - and "Ctrl B").

This new feature, forced onto everybody, would be less annoying, if pressing "W" would reliably disable the feature. However, at least in vritual windows machines (Parallels) on a Mac, it does not work 50% of the time.

"Get Data Size" node

It would be useful to have a node that could be fed any wire and return the size (in bytes) of the data on that wire. In other words, the node would return the number of bytes that the wire occupies in memory.

1 (edited).png

For example, the node would return a value of:

1 byte when fed a U8 wire
2 bytes when fed a U16
4 bytes when fed a I32
8 bytes when fed a DBL
800 bytes when fed a 1D array that contains 100 DBL elements
9 bytes when fed a cluster that contains a DBL and a U8
9 bytes when fed an object that contains a DBL and a U8
18 bytes when fed an object that contains two other objects that occupy 9 bytes each
and so on

Notes

The node would would enhance LabVIEW programmers' ability to monitor and audit memory usage.
The node may serve as an additional tool to detect memory leaks (by repeatedly calling the VI on the same wire and checking whether the size is going up).
The node would simply be interesting to programmers interested in performance and would enable programmers to learn more about LabVIEW internals.
The node would be useful especially to query the size of complex data structures, such as objects that contains other objects that themselves contain objects, or clusters that contain arrays, or arrays that contain clusters, or objects that contain DVRs.
I would be happy if the node had a second input named "Mode" (or similar). This input may be a typedef enum with items named "Shallow Measurement" and "Deep Measurement" (or similar). This input could be required, recommended, or optional.
- When "Shallow Measurement" mode is selected, the node would return the size of all the by-value data fields in the main input wire, but would not add up the size of data referenced by DVRs or other references. For example, a wire that contains a cluster that contains a DBL, a U8, and a DVR would return perhaps 13 bytes (8 + 1 + presumably 4 bytes for the DVR reference itself). It would not add to the result the size of the data referenced by the DVR.
- When "Deep Measurement" is selected, the node would recursively scan all data structures, including DVRs and other references.
In both "Shallow Measurement" and "Deep Measurement" modes there should be no limit to the scanning depth. In other words, if a cluster contains a cluster that contains a cluster and so on, they should all be measured regardless of the nesting depth. Similarly, if "Deep Measurement" is selected, and a DVR contains a DVR that contains a DVR and so on, the data behind all these DVRs should be added to the total.
When in "Deep Measurement" mode and fed a Queue reference wire, the node could perhaps return the size of all the data in the queue. In other words, the size of all the elements present in the queue.
Perhaps the LabVIEW compiler already uses a "Get Data Size" function internally? If such a function already exists, perhaps it would be relatively straight forward to expose it as a node in the palettes?
Perhaps the best location for this node would be in the Programming >> Application Control >> Memory Control palette.

Thanks!

View All (3)

Smart Bundle\Unbundle nodes

Many programming languages IDE are able to distinguish the cluster level. However, selecting a cluster element in LabVIEW requires covering the full path from the top cluster until the desired element. The consumed time for this actions is directly proportional to the cluster size. It would be great that the bundle\unbundle nodes distinguish the cluster level in LabVIEW to speed up the cluster item selection.

Currently, a selection of an item requires a full navigation:

With the improvement a selection would only require partial navigation:

The getting started windows fills with irrelevant entries if we open many VIs and projects from the forum. We probably never want to see them again. Also, if items exist that have the same name, but reside in different folders, they will show with the full (often very long!) path and the filename is not directly visible unless we e.g. hover over it or make the window gigantic. Here we want to remove the stale one, even if a copy still exists on disk.

We can currently do some cleanup by editing labview.ini but it is tedious. (just try it!)

I would like to request a feature that allows us to easily and permanently remove any entry in the list.
(...maybe it could even show for pinned entries?)

IDEA: I suggest to show a special glyph that, when clicked would remove that entry from the list.

It could also be e.g. an "X" (or similar) that shows next to the pin when hovering so we can either pin or thrash an entry.

These are just some suggestions, but there should be a way to easily weed out unwanted entries from the GSW. Of course the actual files will not be touched. We would just go back to the state before we opened that item.

Download All

When programming with large applications, often times you'll have clusters carrying a lot of information. If you hover over the cluster wire and observe Context Help, you might see something like this:

This Context Help window above is rather large and doesn't necessarily make it any easier to see the structure or contents of the cluster. My proposed idea calls for the ability to expand or collapse the cluster contents within the Context Help window, such as this:

What do you think?

View All (2)

On a For Loop that is configured to have parallel iterations there is a nifty feature when using errors on a shift register. This feature is explained in an article here. It basically ensures that For Loops that run 0 times, will preserve the incoming error as if the tunnel was a shift register. However this feature also means that errors from iteration 0, won't be passed into iteration 1. What is returned if the loop runs 0 times is just the incoming error. But if it runs for more than that, the errors are all merged and returned will be the first error seen.

This idea is just to allow this already existing feature to work on non-parallel configured For Loops. When would this be useful? Say I want to delete an array of files. I want to attempt to delete all files, even if there is an error in trying to delete some, just keep trying to delete the other files. Initially you may think this:

But that has the clear problem that if the incoming array is empty, then the error will be cleared. So we often do something like this.

And honestly this bit of code isn't that big of a deal, but this feature already exists. However it only works on For Loops that are configured to run iterations in parallel. In this case I might be attempting to delete files in a specific order due to their placement on disk, and running in parallel isn't what I want.

Since not everyone wants all errors in loops to act this way it would need to be a right click menu to turn the tunnel into a normal one, a shift registered one, or a preserve and merge one.

That is what I want.

Boolean case improvement

So, i just changed a case from a string input to a boolean input. Ofcourse it gets broken with a red "1" in the case selector. That's logical.

Now i need to select the case selector and write False, then switch to the other and write True ...

Once both cases are correct i can r-click and switch them with a "Make this case False".

Improvement suggestion:

If having a boolean input, the Make this case True/False should be active for all cases always.

Even if you have multiple cases (it'll still be broken and you'll have to clear the extra cases)

NI's response to the ideas thus far appears far too sporadic. For example if you check out the top LabVIEW ideas (http://forums.ni.com/t5/ideas/v2/ideaexchangepage/blog-id/labviewideas/tab/most-kudoed) 7 of the top 10 ideas are still listed as new! Adding insult to injury the average age of these ideas to date is 1,017 days! It is ok to decline ideas but please provide us some indication that this is something you take seriously. It would appear that NI is cherry picking the easiest half dozen or so items from the list so you have a marketing gimmick to list on the LabVIEW release notes. I propose that a threshold is set and made public so that if an idea reaches a certain amount of kudos, R&D must address it, even if that means declining it.

View All (5)

Searched briefly but couldn't find any ideas about this.

I know we have the ability #via_ignore comments to ignore specific tests for a specific VI, but I am looking at a different use case.

Here's the use case, I use DQMH. When you create a new DQMH module there is a lot of plumbing code that comes with it. It's standard stuff. Very rarely do I have to open or edit it. Much of it is scripting generated. It often fails tests but I don't care. In addition to failing, it takes up test time, which slows my feedback loop. I would a way to signal to VI analyzer to skip these files. I know I can use the VIAN API to limit the files it checks, but I was thinking there had to be a better way.

Implementation Ideas - I had 2 main ideas

- Regex matching on VI names - with the regex pulled out of a text file somewhere ala gitignore. Many of the DQMH generated VIs have standard names, so that is easy. When generating events, they don't but you could easily add a prefix/suffix or something that the regex would pick up.

- Using the Tag API to tag the VI. I like this because the scripting can just apply the tag or apply it to the template the scripter uses. Downside is: kind of hidden from the user and perhaps if I decide to make some edits to this VI I may want VIAN to stop ignoring it and it's not immediately obvious how to do that.

Note:

I picked the Execution and Performance Label because it didn't seem to fit any of the labels easily. If this is the wrong label and you are an admin, please relabel it.

View All (2)

With a case structure I can place the mouse cursor over the structure and Ctrl + scroll wheel to cycle through the cases without it being active. If I try doing this on arrays it doesn't work.

For front panel arrays the numeric indicator must have focus for this to work. Doesn't work when the array data is selected. I understand that multidimensional arrays would be a problem, but for 1D arrays it would be nice if it cycled through the elements.

For array constant block diagram elements, no scroll action works regardless of what is active. Again it should allow the user to cycle through elements for 1D arrays simply by hovering over the item and Ctrl + scroll wheel.

Not a duplicate of http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Array-scrollbar-quot-scrollable-quot-with-scroll-wheel/idi-p/1009220

[admin edit: Adding animation image at the request of the OP]

Hello,

I'm telling my strudents how they should use the error cluster and how important it is. In subvis no error dialogs should be shown and so on (see topics of LabVIEW Core 1 / Core 2).

But many VIs written by NI have been programmed very sloppy.

Example: VI "Write into spreadsheet file". The error cluster is not wired to the inputs/outputs and if an error occures, an error dialog would pop up. Here is the block diagram of your V "Write into spreadsheet file"I:

Please check all of your VIs and do a revision that we can make well-coded applications where the error handling will work correctly.

Regards

View All (3)

Some very useful properties for UI manipulation on graphs and charts do not exist. This makes it impossible to make very dynamic UI's with variable number of plots or dynamic resizing in panels.

It is possible to set Legend.number of plots and Legend position. It is not possible to set:

Graph palette, scale legend or cursor legend position. This makes resizing graphs very limiting.

Further, it is possible to programmatically create a custom legend. However it is not possible with cursors because there is no property available to get the current cursor values. Please can we have cursor.values[] and cursor.legend.number of rows

View All (4)

Currently, for waveform/XY plots/graphs, the legend, graph palette, cursor window, etc are all "coupled" with the graph itself from a "graphical" perspective.

This means that all of these "addons" must be attached to the graph, and you can't put them in a different part of the panel. Screen resizing thus tends to screw things up, especially if your plot names can be defined by the user.

I'd like to decouple these somehow.

For example, I'd like to be able to put my legend and zoom tools in separate panes separated by splitter bars, or even in a right-click style menu (like a subpanel popping up). This feature would let you use automatic resizing on the plot itself and keep the legend separate.

You could theoretically program your own version of this, but:

-Recreating the legend functionality (line size/width/etc) would be a large undertaking, especially since there isn't a native Datagrid type control that could display a checkbox, string, and small image.

-I don't know of a way to get at the built-in zoom/pan tools programmatically (yes, you could create your own, but it's a big PITA)

-It wouldn't work at edit time, like the current features do, unless you baked all of it into an Xcontrol

Basically yes, you COULD get a lot of this done yourself... but it'd be nice to just use the tools NI already made, which work great. I don't want to reinvent the wheel just for some graphical convenience.

Align input and output of Select function

View All (2)

(note: this idea is similar to this one, but different enough that I thought it warranted a new post)

LabVIEW 2019 will include a Clean Up Front Panel feature that repositions front panel objects to match their positions on the (already wired) connector pane. I think we should also consider implementing the opposite behavior, where you can arrange your front panel the way you want your connector pane, then assign that arrangement to the (currently empty) connector pane:

I envision the gesture used to employ this feature would be a Quick Drop Keyboard Shortcut, an entry in one of the drop-down menus, or a right-click on the Connector Pane.

LabVIEW Idea Exchange

Make Current Control Values Default

Make numeric display format auto-set to what you input

Improved Window Management While Debugging

Opt out permanently from "maintain wires connected"

"Get Data Size" node

Smart Bundle\Unbundle nodes

Unbundle By Name: Element Autopopulation

Let us easily cleanup the Getting Started Window (GSW)

Expandable/Collapsible Clusters in Context Help

Allow For Special Loop Error Shift Register on Non-Parallel For Loops

Boolean case improvement

Require LabVIEW R&D response to any idea over N kudos

VI Analyzer Ignore Certain VIs Completely

Ctrl + mouse wheel: Scroll through array elements when hovered over

Revision of many VIs written by NI (usage of the error cluster)

Dynamic/smart Index/scrollbar on array constants

Waveform graph and chart manipulation new properties

Decouple plot legend/tools/etc from the plot graphic itself

Align input and output of Select function

Make Connector Pane Match Front Panel Arrangement