LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Enforce proper spelling of "LabVIEW" online

View All (1)

When working with multiple projects at a time I try to keep all of one projects windows on my primary display and all of the windows for the other project on a secondary display. This can become tedious to move every window I open. I know each VI remembers its' last location and opens there but it would be great if there was an override setting.

So for instance, when I open a project, there could be an option in the Project menu for "Open project windows on this display" that would then force any windows related to that project to stay on the same display.

Randy B

EDIT: An alternative which might be easier to implement would be to add an option (Gather Project Windows on This Display) in the Window menu that would move all of the Projects currently open windows to the active display.

View All (5)

Let's say I have a ring control filled with lots of of items, but I decide that it would be better for the user if he could see all the options without having to pull down the ring. I right-click on the ring control, choose replace and select a Listbox. Now I have an empty listbox though, and I have to recreate the list. Most of the times when I do this I want the items I had in the ring control to transfer to the new control, like this:

replace with content carried over.png

The transfer of items should work both ways, and apply to similar replacements, like a change from ring to enum e.g.

It would be nice to have a way to choose whether to keep the items or not of course (key control while doing the replacement or a dialog asking if you want to keep the items), instead of having to delete the items afterwards if you did not want them, but I am not sure it would be needed that often. I would be perfectly happy for the default to just keep the items.

PS. Writing a quick drop shortcut plugin is one existing way of getting this functionality without having to wait for NI to implement it in the IDE...Perhaps someone has already done that (?). This request is for it to become (or be a part of) the default behavior though.

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:

With LabVIEW classes, I appreciate that:

- I can save and load class data to/from disk.

- Backwards compatibility is automatically taken care of with no coding required (in most cases).

However....this functionality breaks as soon as you rename a class (which includes moving it into a library).

It'd be great if I could rename a class (or add it to a library) and then still load data that was saved with a previous version of that class. I've been burned by this a few times where legacy data files are unrecoverable after code refactoring.... and it's a tradeoff I'd rather not have to make in the future!

(Apologies if this suggestion has already been submitted...but...didn't find it in my search)

We are already using the shortcut Ctrl+i for opening the VI properties window.

But to open a VI's Icon Editor window, we do

Right Click on the Icon → select Edit Icon (or)
Double Click on the Icon

Think about the improvement in development speed if we have a shortcut Ctrl+Shift+i to open the Icon Editor window.

This will also come in handy if we are dealing with wider VI windows.

Current Environment takes ~2.5 seconds to open the Icon Editor

Move the cursor to the VI Icon (~1-2 seconds)
Two mouse clicks (double click) (~1 second)
(or)
Move the cursor to the VI Icon (~1-2 seconds)
Right click on (~1 second)
select Edit Icon (~1 second)

Proposed Environment will take ~1 second to open the Icon Editor

Press Ctrl+Shift+i (~1 second)

We are already familiar with the Ctrl+Scroll to explore the Structures in the Block Diagram.

It is a handy feature to explore the Numerous Pages of a structure.

And on the Front Panel, we have a similar Primitive which has the ability to have as much pages as required - The Tab Control.

In different scenarios, we may end up with numerous pages on our Tab Control and even we may not have the Tabs/Page Labels Display visible in the GUI.

In such scenarios, while editing the GUI, we may need to switch between different pages. To switch between pages currently we have only one option with the Right Click->Go To Page->select page process.

This is making the whole GUI editing process slower.

We also have some workarounds to avoid this Right Click->Go To Page->select page process delay by temporarily making the Page Labels Display visible during the edit time to select which page to be shown.

But lets consider the efficiency if we have this Ctrl+Scroll feature for Tab Controls to explore the pages!

And it may work only in the Edit mode.

It is pretty nice that we can create custom palettes for lvclass libraries and set them as default; being able to right-click on a class wire and get an organized menu (i.e. method VIs arranged in sub-palette folders), rather than just an arbitrarily-ordered bunch of all the member VIs.

However, it doesn't appear that the palettes inherit -- if I right-click on the class wire of a child of the class with the custom palette, I am presented with the child members and the parent members, with no palette customization.

Example

Parent Class (with custom palette)

Child class (which includes the parent members, but without the subfolder organization):

Could the IDE support inheritance of the palettes, such that right-clicking on a child class wire showed me parent items in their organized default palette view?

View All (3)

Send Feedback Button

When NXG was released, NI added a button that you could click and send feedback to NI about things you liked and about things you didn't like about it. I realize this is most helpful in a product that is in beta like NXG, but there are still times I'll be doing something and I think "Man I don't like how this works" but I often move on or forget to post an idea about it.

So this idea is to add a "Send Feedback" button in LabVIEW where the developer can then send suggestions to NI.

Feedback Button.png

Feedback Dialog.png

A valid criticism of this idea would be "Isn't this what the idea exchange is for?" And I can agree with that. But still I thought it was a cool feature of NXG, and if it was useful there, why wouldn't it be useful here? I figured I would submit the idea and let the community to decide if this is a valuable feature or not.

NXG had a neat feature I miss in LabVIEW 20xx and that is resizable nodes for operations like OR, AND, and Add. There are other nodes that could benefit from this too like subtract and multiply, but here is the idea.

Resize Nodes.png

I'm aware that the Compound Arithmetic is a resizable node that covers the examples I have here. But often times I will start with just two inputs so I'll use the OR, then later on I'll need to add a node and now I need to replace it with the Compound Arithmetic and then add the other inputs. If the suggestion is to just use Compound Arithmetic, then why even have an OR node?

When creating a real-time app (.rtexe) intended to be run on multiple targets with target-relative references, the recommended technique is to create a build with a IP address of 0.0.0.0; then, using some other utility outside of the LabVIEW environment, copy the executable to the startup folder on the target.

Given that, it would seem reasonable to create a feature within the LabVIEW Project Explorer that allows for direct deployment to a specific RT target or targets from the right-click menu instead of having no option to select an alternate target(s). If setting the IP address in the project to 0.0.0.0 is the recommended technique for creating a target-relative (versus absolute) executable, then LabVIEW Project Explorer should be able to key off of this value to take a different and more appropriate action.

The same would be true of the Set as startup and Run as startup right-click menu options.

View All (6)

Channel Wire graphical improvement.

View All (2)

When connecting to an RT target from the LabVIEW Project view, LabVIEW RT automatically makes changes to the lvrt.conf file's startup app settings. I’ve never really understood why it needs to do that. I suppose that for some users, maybe less experienced users, this action enforces some sort of consistency that may help to avert potential tech support issues in some scenarios. However, in my case, it is an annoyance that I have to manage.

In my opinion, the LabVIEW Project view should not alter the startup app settings in the lvrt.conf file unless you use the Deploy feature from the menu. (For PharLap-based controllers, it would affect the ni-rt-.ini file). If you use the Deploy feature, then that behavior may likely make sense.

NI should consider either eliminating the automatic edit to lvrt.conf when connecting to an RT target from the Project view and/or editing lvrt.conf only if using the Deploy feature is used. If for some reason NI feels that the behavior is justified for some technical reason (and I would be curious to know what that reason is), what I would like to see in lieu of that is a LabVIEW option (checkbox setting) that gives the user the ability to prevent that automatic edit.

Currently, the specific changes that connecting to an RT target makes to the lvrt.conf file are:

It changes the name of the startup app back to the default name of startup.rtexe.
It changes the value of the key RTTarget.LaunchAppAtBoot to FALSE.

Deploying a library to an RT target should also not alter the startup app settings.

View All (6)

Switch until released radio buttons

Allow the mechanical action of radio buttons to be switch until released.

The way I make arrow buttons now is to put switch until released buttons in a cluster and watch for the value changed event of the cluster. When it changes, I convert the cluster into an boolean array, that array into a number, then feed that number to a case structure. Switch until released radio buttons, "No Selection" being a necessary default, would make that code nicer. The case selector would be an enumeration instead of a number.

LabVIEW Idea Exchange

Enforce proper spelling of "LabVIEW" online

Open Project-Related Windows On Same Display

Allow App build specs for different OS in the same project

Consistently expose nested data in Property Nodes

Keep items when replacing ring (or enum) with listbox (and vice versa)

Ctrl+Click while wiring change the cable source

Error Description for Error Ring Custom Error codes should be searchable

Drop-downs for Selecting Conditional Disable Structure Options

Smart Bundle\Unbundle nodes

Backwards Compatibility of Class Data -- After Name Change

Ctrl+Shift+i to Open Icon Editor

Ctrl+Scroll Mouse Wheel to Explore the pages of Tab Containers on the Front Panel - Edit Time Only

Inherit lvclass parent's default palette

Send Feedback Button

Resizable Boolean and Numeric Operations

Easier Way To Deploy Target-Relative Apps To RT Targets Needed

Channel Wire graphical improvement.

Make it easy to add VIs to Quick Drop

Add LabVIEW Feature To Prevent Automatic Edits to lvrt.conf Startup App Setting when Connecting to LabVIEW RT Target in Project VIew

Switch until released radio buttons