LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Custom Watermark Decoration

Changing a graph's axis mapping (linear to/from logarithmic) is super easy using the context menu in edit mode. But as far as I can tell, this feature is not available at run time:

It's inconvenient to have to stop a VI to change the axis mapping (and sometimes impossible, e.g. in stand-along applications) and I believe that most users would expect to find lin/log controls in the context menu, right next to autoscale. Why not enable this feature in run-time? If, for whatever reason, a developer doesn't want these options displayed, it would be easy to delete them from the run-time context menu.

It's certainly possible to change the axis mapping programmatically, but I would prefer if it were built in to the graph control, and enabled by default. It's frustrating to manually create axis scale control elements, over and over again, every time an application doesn't permit stopping the VI to change mapping from the edit-mode context menu.

Swap Structure Add After/Before Items

These context menu items should be swapped to be intuitively ordered so Before is before After and After is after Before. With a Case Structure, Diagram Disable Structure, Conditional Disable Structure, and Flat Sequence Structure, the right-click pop-up menu items to Add Case, Subdiagram, or Frame After are first and before the Add ... Before items. These being opposite intuition always make me pause and think to pick the right one. Help us be more productive, please.

View All (1)

Left shift registers (For Loop, While Loop) can be either initialized or not.

In general, the programmer knows what is needed for the correct behavior of the code, but code modification (say a broken wire followed by a Ctrl-B) can change this status:

Step 1:

Step 2:

Step 3:

If this last step is performed without remembering that the shift register needs to be initialized for the rest of the code to function properly, an insidious bug can result.

My suggestion: Let the user specify whether a shift register initialization is required or not (just like a VI connection can be specified)

View All (2)

Mass Compile within Project Tree

Arrange VI Window (Ctrl+Space, Ctrl+F), when applied on the Front Panel, aligns controls that are connected to the terminal. Any control that is not connected to the terminal is relocated below controls that are connected to the terminal.

Unfortunately this plugin doesn't take Window Run-Time Position into account, which can produce undesirable results. As an example, here is a screenshot of a VI before and after using the shortcut:

Before

After

I think it is reasonable to expect the content area to stay untouched during this operation. What I would expect is something like this (error terminals were added to emphasize):

1) Any control inside the bounding box of Window Run-Time Position should stay untouched

2) If the bounding box is visible, offset origin by a few pixels to keep it visible after arranging controls

3) VIs without Window Run-Time Position should behave like before

Find attached a version of this plugin that produces the output above. I think this behavior should be supported by the version that ships with LabVIEW. I am also curious to know if anybody uses the shortcut to align controls that are visible at runtime (and why).

View All (3)

Apply Icon to Child Implementations

So you just finished editing a bunch of icons in a very low level class. Wow, they look pretty. Bummer though, that all the child implementations still have the old icons. Guess what, time to grab a cup of you favorite form of liquid caffeine and start grinding through all the descendant class VIs to manually do the same thing over and over and over and over...

Similar to when you edit a library icon, when I edit the icon of a dynamic dispatch VI, I'd really like to be able to automatically propagate that change through to all higher level implementations that exist in the project.

-mje

View All (2)

Docking Palette/View of open files.

Having a dockable palette/View of files that are open in labview.

Many developers would probably agree that having 30 VIs open creates lack of order in their desktop, and the way to swicth between them now is by clicking the taskbar icon and scrolling through till you find the one you want (in windows7 - grouped view at least, even worst without grouping with 30++ icons in your taskbar)

This could be solved by having a viewer, either standalone or even as part of the project explorer. buttons to either see BD or FP before or after the name of the file would also be prefered as having two entires; one for BD and one for FP creates dual entires and is only adding to the mess.

Thanks

View All (4)

I am always putting flat sequence structures around "set" and "unset" busy cursors because if I wire error clusters into them to enforce data flow and an error is passed in, they don't execute. Nothing like having an error occur then your cursor stuck as busy. I suggest having these two subVIs execute even if an error is passed in (just like reference closing/releasing functions do). This way the error cluster can be used to enforce data flow and we can all avoid unnecessary flat sequences. The only issue I see with changing this is if previous code has been written taking the current functionality into account and expects a cursor to stay busy when an error happens and unset busy is managed in the error handling state, or something of the like.

For ethernet and GPIB communication I have the choice between the LabVIEW "native" drivers (residing in function palettes "Instrument I/O" and "Data Communication") and VISA. LabVIEW 6.1 was the latest version which also supports "native" drivers for serial interface. In LabVIEW 7.0 and later you are forced to use VISA.

Besides all advantages of VISA - the biggest disadvantage of it is its HUGE communication overhead it produces. If you use interface sniffer like PortMon, you will see that VISA heavily communicates with the interface chip (requesting its status etc.). So for sending a simple "Hello" over RS232 you don't have only four actions (configure port, open port, sending "Hello", close port), but ten and more.

As consequence VISA often lockes out if you have heavy traffic on your serial interface (e.g. if you have to send data every 250ms over the interface) - and if VISA lockes out, you have a serious problem...

So PLEASE, give us the native driver for serial interfaces back!

Several extension in file dialog

View All (2)

LabVIEW Core Edition

This suggestion has been made before twice, in 2010 and 2011, in a more or less similar manner, and declined both times, but in light of the recent announcement of LabVIEW Community Edition I thought it might be worth a 3rd shot, so here it is with my own rationale for it (originally posted here).

Consider eventually also making available an (also free) "Core" edition of LabVIEW coupled with a much-reduced-in-size "LabVIEW Core Runtime", with everything hardware- and advanced-math-related removed, but allowing for commercial and academic usage.

There would be many benefits in doing so:

It'd would allow LabVIEW to develop more into general purpose language, suitable for developing generic cross-platform desktop and web applications;
It'd bring all manners of new developers from outside the very specialized field of industrial applications;
These non-industrially-focused developer would develop new libraries and open source packages that'd expand LabVIEW's capabilities in all manners of directions;
And then all these elements -- 3rd party "for core" tools, new developers, new ideas -- would provide a boost to the industrial-related versions, which would become the natural upgrade paths.

Doing this might risk losing a few sales of paid-for versions, and it'd also incur in costs as NI would have to decouple many things, which would require lots of engineering hours to do. But I believe long term it'd boost LabVIEW's usage in significant ways, and result into even more sales down the line.

Typical usage progressions would become something like this:

Core → Community → Base → Full → Pro → Pro + add-ons → Suite(s)
Core → Core + (new, paid for) Advanced Math and similar core-focused add-ons → etc.
Core for entry level generic programming classes → Academic licenses for classes focused on industrial applications → Academic licenses for actual research

And so on and so forth.

Please consider it, okay? 🙂

View All (6)

Reference Inputs Default to Required

This idea is for improving the connector pane to default to required inputs for terminals that use reference type data. So if I have a new blank subVI and I wire a VI reference to an input, this should be set to Required by default. I'd also suggest this be the same for a Create SubVI from selection. Obviously you could change it from required, because the developer may have some code in the VI to detect an invalid reference and do something specific. But in most cases if I do something like wire a Queue reference to an input, that input should be required.

One could make the argument that this idea could be done today, by making all inputs default to required, which I think goes too far. Many times I have code that detects unwired inputs (by looking at the default value for the control) and it shouldn't make an input required if it isn't really required. What I mean is in my work flow the majority of inputs should be recommended, but the majority of references (Queues, DVRs, Control References, VI References) should be required. There are a few data types like Classes that could be reference based or not, and I could see an argument for this being required, or recommended, and for these I don't really care how they behave. But for inputs that are clearly reference based I think it would help from making code that the developer mistakenly leaves recommended.

This could be an INI key in LabVIEW for those that don't want it, or for those that choose to make all inputs required.

LabVIEW Idea Exchange

Mouse over

Custom Watermark Decoration

Allow axis mapping context menu at run-time

Swap Structure Add After/Before Items

Left shift register initialization: required/recommended option

LabVIEW built applications should be identical

Mass Compile within Project Tree

QD plugin Arrange VI Window should respect Window Run-Time Position

Apply Icon to Child Implementations

API for the "Profile Performance and Memory " tool

Docking Palette/View of open files.

Remove Common Error Functionality From Set/Unset Busy Cursor

Native drivers for serial interface (RS232 etc.)

Add Windows/Linux/OSX PC Target in a project

Several extension in file dialog

LabVIEW Core Edition

Event Structure Current Frame Indicator

Reference Inputs Default to Required

Show the Representation of numerics in tip strips for terminals and wires.

Find objects within areas of code