LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

As much as I love Quick Drop, I don't love this:

This delay occurs because we have to load all the palette information in the background to be able to drop objects by name. You can choose Tools > Options > Controls/Functions Palettes > Load palettes during launch to front-load this delay during LabVIEW launch, but (1) a lot of you don't really like the longer launch time much better and (2) a lot of users still don't know about this setting.

I'm sure there's a way to solve this problem and make Quick Drop instantly usable, but I don't know enough about the underlying palette code to get it done. Solving this problem, by the way, could have positive side effects on LabVIEW launch time, palette search performance, and maybe some other areas as well.

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

View All (2)

The static VI Reference has the ability to be made strict. A strict and static VI reference shows the icon of the target VI (static part) and a small red star (strict part). This allows a strict, static VI reference to be wired directly into a CBR node.

However, the new async CBR feature does not work with strict, static VI references because it also requires option 0x80 or 0x100 to be wired into the Open VI Reference.

There should be a way to specify an async call inside a strict, static VI reference. That way, an async call can be made by way of a reference returned by a strict, static VI ref and not just with an Open VI Ref.

We can specify custom markers for axes, but even if we do so, there will be two additional markers that cannot be hidden: the Min and Max!

I would prefer an option to get rid of these two extra markers. Often they are distracting and not desirable for a clean look. For example we might want the x-axis to start at zero, but we want some padding to the left so data points (e.g. small circles) are not cut off by the other axis. Here we might want the x-axis min to be e.g. -0.02, but we still want the first maker to be at zero with no markers to the left of it.

If I specify custom markers, these are the ones I want, nothing else. 😉

Message Edited by altenbach on 06-10-2009 04:22 PM

View All (3)

Version-aware LabVIEW launcher

I, like many others I am sure, have multiple LV versions installed on my computer.

I have often wished for a small launcher program (linked into Explorer.exe under Windows) which has a peek to see what version a VI (or ctl or whatever) is BEFORE calling the respective LV version.

It could also have an option to show a dialog whenever a VI is double clicked in a version different to a version of LV which is ALREADY open asking if it should be opened in the native version or in the currently opened version.

An alternative would be to treat VIs opened from a different version as locked (read-only), forcing either a manual setting of write permissions or saving under a different name.

Shane.

View All (2)

Jog-wheel (unlimited range knob)

Hi,

I suggest adding a jog-wheel (unlimited range knob) to the palettes:

The current knob you set the minimum and maximum range, and can then select inbetween those values by turning the knob from one endpoint to the other.

A jog-wheel you configure with only the range for one complete revolution of the knob, but you will then be able to turn it as many revolutions as you wish and it'll continue to increase or decrease its value (depending on if you turn it CW or CCW). This'll work like the jog-wheel on a video-player; configure it for a range of 10/revolution for instance, if you then want to move 30 upwards, you just turn the knob three full revolutions CW. It should support the mouse scroll wheel on top of it of course, for "quick jogging".

Cheers,

Steen

View All (10)

I don't know why LabVIEW does this, but when you copy and paste (with ctrl-c and ctrl-v as opposed to ctrl-drag) certain items on your block diagram, they do not act as most would expect. I think copy and paste should make an exact copy of what you are copying instead of changing the functionality/behavior. Examples

Local Variable:

If you copy a local variable, it creates a new control and makes a local variable out of that. I really just want a copy of the local variable that's already there. If I wanted a new control, I would have made one, no?

Property Node:

Copying an implicit property/invoke node changes it to an explicit node. Why wouldn't it just make another copy of the implicit node that I already had?

I'm sure there's other examples of this behavior that I can't think of now, so feel free to add them to the comments. If you have a good reason why this behavior is here, please let me know as be happy to be corrected...

Cluster Justification

Currently, all setup (any any other configurable items) for LabVIEW is stored in the LabVIEW folder hierarchy. I would like to see it moved to the User folders. This would provide several advantages:

Multiple users can use LabVIEW without having to worry about reconfiguring someone else's setup. This can be especially nice for the pallette menus, if different users like to "tweak" the default layout and create personal custom palltte menus.
For people who use roaming profiles (such as me), whatever station I sit down at and log into will have the LabVIEW configuration I use on every system. Any modifcation is automatically updated in my profile and "moves" with me from PC to PC.
It would provide an easier way to backup settings, since all customizable settings will be in one place, and not mixed in with LabVIEW installation files which aren't customizable.

View All (2)

There are many times when I need to grab the last element or last n elements of an array. This usually involves a call to Array Size and then a subtraction, costing me time and block diagram clutter. Array reversal is essentially free, but again costs clutter and clicks. For common array types I have personal VIs to do the job, but that is just a band-aid with the proliferation of data types that I use. My idea would be to treat negative values input to the index array or array subset VIs (for example) as counting from the end of the array. The last value would have index -1 and so on. To get the last n values I would put -n into the Array subset VI and that's it. For expanding the Array Index VI, my preference would be that it counts down (-2,-3,-4,...).

View All (2)

Hopefully low hanging fruit? I'm constantly checking the error list when working in a VI that's part of a broken class hierarchy to see if the VI itself has errors or if it's just due to a hierarchy error or dependency error. I often repeatedly check it to confirm if the VI I'm currently working in has the errors and could save a bunch of time if something was different about the broken run arrow and I only had to glance at it to confirm I can move elsewhere in my development as expected, or continue to the error list to see what's really broken.

View All (4)

multicolumn listbox

View All (5)

A typedef control has no block diagram. When you modify an existing typedef, block diagram instances of that typedef are updated; but any block diagram display customization is lost. This can seriously affect the appearance of a block diagram when the typedef is inside a state machine.

I suggest that a typedef control should have the ability to define the block diagram appearance, and that it should have it's own flag for regular or strict. A typedef could be defined as regular for the front panel while the block diagram could be set as 'strict'.

The typedef editor could display the front panel and block diagram appearance in adjacent panes (see image below).

Who has ever made a cluster typedef, then added some elements, then added more, then a little more? Have you noticed the "typedef explosion" of your block diagram as a result, with constants overlapping other code? Make a right-click option to "link" a bundle by name to a typedef. Note that the two pieces of code below would be identical, but the bundle on left would not suffer from typedef explosion. In addition, have a selectable menu

Another idea is to link the bundle to the destination:

View All (2)

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)

LabVIEW Idea Exchange

Eliminate Quick Drop's Initial Launch Delay

Make Current Control Values Default

Probe Watch Window - Last Update - Show milliseconds instead of date

Make "Split Number" and "Join Numbers" primitives growable

Advertise Idea Exchange in Getting Started Window

Allow Asynchronous Call By Reference with Strict, Static VI Reference

An option to hide edge markers of axes

Version-aware LabVIEW launcher

Jog-wheel (unlimited range knob)

Fix Copy/Paste for property nodes, local variables, etc

Cluster Justification

Add "Add Element" and "Remove Element" to the Index Array context menu

Move LabVIEW INI, other config setups to User folder

Negative Values in Index Array or Array Subset

Show a different broken arrow when the VI doesn't have errors itself.

Block diagram Clean Up Tool improvement - loop conditional terminal

multicolumn listbox

Add Block Diagram design for typedefs

Eliminate Typedef Explosion on Block Diagram

Compound Close References