Home Community Idea Exchange LabVIEW Ideas : Top Ideas

LabVIEW Idea Exchange

Community Browser
Top Authors
View All
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
Post an idea
61 Kudos
Darin.K

Connector Pane Editor

Status: New Submitted by Trusted Enthusiast on 08-10-2010 04:24 PM 7 Comment

I am migrating and updating some of my favorite tools to LV10, and one of the first to make the move is always my Connector Pane Editor.  This is a homemade tool I have had around since LV8.2, which allows me to quickly wire the connector pane in a style reminiscent of the Icon Editor.  I use my version constantly and can not live without it at this point.  I would like NI to adopt something similar for a few reasons.  1) I am a UI pragmatist, and this could probably use a little help in this regard.  2)  It is hard to incorporate tools like this into the IDE.  Right now I use the Tools menu which is ok, but I'd like to get this into the Right-Click menu that we currently use to edit the connector pane.  3) It drives me nuts when I am on a computer that does not have this.

 

Here is a screenshot of my version and zoom on the right-hand side.

 

21055i12DB0EFCA0AC94F9

 

21059iD4CEEA35EC3F9767

 

Features I like about my current version:

1) No squinting and carpal tunnel issues trying to land on tiny terminals

2) Auto increments controls, when one control is placed, the target is automatically incremented so the next control is ready to go.  Arrow keys allow you to skip controls.

3) Front panel image shows which control is currently being wired, which one is currently attached to a terminal when the mouse is over it, and is clickable to choose which control to wire.

4) Control descriptions are editable at the same time.

5) Shift-click grabs the currently wired terminal.  If you want to move a connection, Shift-click to pick it up, move to the new location, click to drop.

6) Clicking on a currently wired terminal replaces that connection with the current target, and makes the previously wired control the new target.  Swapping terminals is a two-click process.

7) Optional autowiring, Error In/Out as well as references/paths can be autowired according to my preferred style.

 

In short, even my crude attempt is an incredible timesaver, I can wire a ConPane in a matter of seconds, without the back and forth trips between the FP and the ConPane with the wiring tool.  A little NI-ification, as well as integration should make it even better.  If it gets screwed up, at least it should be similar to the Icon Editor which can be modified by those who want to badly enough.

 

 

Labels:
View All (1)
61 Kudos
altenbach

Provide an event terminal for event queue size

Status: New Submitted by Knight of NI Knight of NI on 07-20-2010 03:33 PM 3 Comment

(This came up an a somewhat related discussion here. Possibly it would be easier to implement and thus has a better chance.)

 

The suggestion is to provide an event terminal that outputs the current number of queued up entries in the event queue for that particular event.

 

(The main purpose is to deal with stale event accumulation. Details are in the quoted idea thread.)

 

Labels:
61 Kudos
Manzolli

Swap Colors in Tools Palette

Status: New Submitted by Active Participant on 01-15-2010 05:47 AM 4 Comment

Sometimes, like in many other software that have a paint feature, we need color swapping between foreground and background. The idea is to add a spot in the Tools Palette to allow this operation in one click. Here is a suggestion:

 

swap colors.png

 

It's difficult to see the spot because I did not changed anything, just added the double ended arrow. One way to help the visibility is turn it white when the mouse hover over it.

Labels:
View All (6)
60 Kudos
craigc

pop up comment on Block Digram

Status: New Submitted by Active Participant on 10-07-2009 11:10 AM 5 Comment

Hi,

 

Often you see in code one large text box for comments and labels on each section of code for which the comment applies.

 

How about a small speach bubble type icon which can be placed on the block diagram, which when clicked/hovered on will pop up comments either in its own window or in the context help window.  This could be linked into the new requirements tracking tools as well.

 

Craig

Labels:
View All (4)
60 Kudos
tst

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

Status: New Submitted by Knight of NI Knight of NI on 07-22-2009 02:06 AM 15 Comment

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.

 

Move Wire.gif

 


Message Edited by Support on 10-22-2009 01:25 PM
Labels:
60 Kudos
MGiacomet

Event Structure: Configurable timeout terminal

Status: New Submitted by Member on 08-20-2015 08:18 AM 9 Comment

Tired of resizing an event structure and having to relocate the timeout constant?... Simply double-click on the hourglass and type the timeout value!

 

Of course, the option of wiring to the event structure timeout input should still exist. Just like the timed loop, where you can double click and set the period, etc.

 

 

 Untitled.png

Labels:
60 Kudos
manu.NET

Add Defer Panel update checkbox in event management ...

Status: New Submitted by Active Participant on 01-16-2015 02:38 AM 5 Comment

Hello,

 

When you have to handle events, many times you have to use "defer panel updates"  fonctionnality, in order to make your front panel updates more fluent.

 

It could be nice to include a checkbox in the event configuration window, in order to ask (or not) an automatic defer panel Update.

 

If check box is checked :

 

  • At the begining of the event handler code execution : DeferPanelUpdate = TRue
  • Execution of the event code
  • At the end of the event handler code execution : DeferPanelUpdate = FALSE

DeferPanelUpdate for event handler.png

 

Manu.net

Labels:
View All (4)
60 Kudos
SteenSchmidt

Open VI reference without refees

Status: New Submitted by Trusted Enthusiast Trusted Enthusiast on 02-26-2013 04:10 PM 22 Comment

Hi,

 

I suggest an option added to the Open VI Reference primitive to open that VI reference without any refees. I suggest option bit 10, i.e. option 0x200h:

 

OpenWithNoRefees.png

 

The demand for this arises when you want to access methods and properties of VIs that may be broken, while on the other hand you don't have any need to run those VIs - for instance in one of my current tools (BatchEditor) where I'm tasked with investigating hundreds of VIs simultaneously of which some could be broken or missing dependencies. Other situations would be tools for traversing project trees for instance. Opening a large number of healthy VI references takes a while, and when something is broken in a VI, opening even a single reference could take 30 seconds to minutes.

 

Currently you can suppress the "loading" and "searching" dialogs by setting option 0x20h on the Open VI Reference primitive, but that only loads the refnum silently as far as that will get you. Opening the refnum takes the same amount of time as if you could see those dialogs, and you are rewarded with an explorer window if a dependency search fails. I just want a way to open a VI refnum without even starting to look for dependencies, thus very quickly and guaranteed silently.

 

The relevant people would know that this request isn't that hard to implement, as it is kind of already possibly using some ninja tricks. I'd like such an option to be public.

 

Cheers,

Steen

View All (8)
60 Kudos
P@Anand

Properly Insert "Delete from Array"

Status: New Submitted by Trusted Enthusiast on 04-19-2012 11:36 PM 7 Comment

When I Right click a wire and tried to insert a "Replace array subset" its getting inserted properly but the same doesn't work with the delete from array and I had lot of instances where I have to insert a "delete from array". I am proposing this after searching this forum but If already proposed then I'll try to give Kudos for that.

 

Replace array full.png

 

So without broken wire it would be nice to insert a "Delete from array" function.

Labels:
View All (4)
60 Kudos
GregFreeman

Greyed out default string in string controls

Status: New Submitted by Trusted Enthusiast Trusted Enthusiast on 04-04-2012 03:44 PM 7 Comment

I would like if there were a default value for string controls that would be greyed out, but the string value would still be a blank string. This could be useful in showing example text for text that should be entered in a specific format. I have shown an example of the (visual) functionality and the code that goes along with it. This code could be greatly reduced if there was a key focus event added, but even in this case, the string control value itself is still not an empty string. I could also see this being beneificial in listboxes, multicolumn listboxes, tables etc.

 

Labels:
60 Kudos
Matthias_H

"Insert Into Array" should be wired correctly when insert into an array wire

Status: New Submitted by Member on 02-02-2012 05:53 AM 3 Comment

If you right click on an array wire and choose "insert - array palette - inert into array" you geht this:

 

lv_arr_2.PNG

 

It would be better if this happens:

 

lv_arr_1.PNG

Labels:
View All (2)
60 Kudos
X.

"Function terminal not connected" detection (plus shameless plug for another pet-peeve of mine)

Status: New Submitted by Trusted Enthusiast on 01-31-2012 07:33 PM 27 Comment

Must have been discussed a zillion times, but just in case, there it goes:

 

what's wrong with this picture?

 

ScreenHunter_001.jpg

 

apparently nothing. If I grab the function and move it:

 

ScreenHunter_002.jpg

 

Note that LV must have "computed" something here to reroute the wires, etc.

But wait, what happens if I grab the wire and move it?

 

ScreenHunter_003.jpg

 

Oops! I did not connect the output of the function to the indicator. Instead, I inadvertently connected the input.

Needless to say, this is a F-ing nightmare to debug... unless you think of verifying that the value before the function and after the function actually gets incremented. Which you will, eventually, but not until after having wasted a lot of time thinking of all other possibilities elsewhere in the code.

 

Bottom line (this is only an example I just encountered for the umpteenth time a minute ago), LV does not provide much in terms of warning for this kind of potentially very damaging error. This is very much related to the discussion I started here with very limited success (man, am I an upbeat person!). 

 

Suggestion: not only allow to define VI outputs as REQUIRED but also add warnings when a function that has its only or most important output(s) unconnected.

 

And if not everybody is interested in this kind of sanity check (I am talking about functions), you could offer this "warning" as an option (in a warning definition panel in the Preferences).

Labels:
View All (1)
60 Kudos
mikemattball

Add a save file method to the configuration files object.

Status: New Submitted by Member on 03-18-2011 08:35 AM 5 Comment

Currently, the configuration file object only has access to save a file when you close the object.  I'd like to be able to save the file at any point in time and keep the object open.

 

 

 

View All (5)
60 Kudos
altenbach

Embedded labels for property and invoke nodes

Status: New Submitted by Knight of NI Knight of NI on 08-25-2010 04:02 PM 7 Comment

We've had a few recent discussions relating to labels of block diagram objects. I don't think the following came up yet, but I think it's one area where improvements are really needed.

 

If we create a property node or invoke node, it has a label indentical to the linked object. However, this label can be changed to anything we want, possibly leading to code that is very confusing! For example if we had two terminals labeled A and B, we could label the property node linked to A with "B" and vice versa, completely obfuscating the code!

 

(The beginner could also incorrectly assume that changing the label is the correct way to change the association to a different terminal)

 

These nodes should really have the label of the linked terminal hardwired to the corresponding terminal name, because anything else simply would not make a lot of sense.

 

My graphic is not as nice as Jack's here, but I think the idea is clear. It would certainly need a few tweaks from the art department. 😉

 

 

We might need an option to hide the label. Oversized labels should be truncated for display, only showing the full text when hovering.

Labels:
View All (1)
60 Kudos
Henrik_Volkers

Grouping blockdiagram objects

Status: New Submitted by Trusted Enthusiast on 03-01-2010 08:48 AM 9 Comment

Dear NI,

 

I can group frontpanel objects, but it's not possible in the blockdiagram. 

 

Sometimes I place graphics behind indicators and/or controls. Same I do in the blockdiagram for documentation and orientation .  In the frontpanel I can group (and even lock) these elements, but not in the diagram 😞

So with all these autostretch features my diagram graphic arrangement get disturbed 😞

 

I would like  to have a grouping option in the diagram.

 

 

Labels:
60 Kudos
JackDunaway

Data Probes Should Show At All Times

Status: New Submitted by Trusted Enthusiast on 12-09-2009 12:36 PM 6 Comment

It's very frustrating to have your floating probe windows disappear when a LV modal window is presented. Frame 1 below shows probes set up, and Frame 2 shows how they disappear when a modal window appears:

 

ModalWindowsEatProbes.png

 

Some of the most annoying modals that pop up while troubleshooting include: 

  1. "Save changes before closing?"
  2. "Waiting for Real Time Target to respond"
  3. Error windows

#2 and #3 modals windows recently made it impossible to use probes since I was trying to diagnose a problem that constantly would throw those modal windows.

 

Proposed Solution: Don't ever hide probe windows, regardless of what pops up.

Labels:
View All (1)
60 Kudos
Pnt

"Delete from Array" function should accept an array at index

Status: New Submitted by Active Participant on 11-05-2009 05:44 AM 14 Comment

Currently there is no way to delete multiple elements in an array, that are not in sequence.

This way elements 2,4,7 would be deleted in just one function.

 

Delete from Array.png

 

It is cleaner code and in big arrays can enhange performance (at least i think)

59 Kudos
CaseyM

Make the default behavior of opening a VI open ONLY the block diagram

Status: New Submitted by Active Participant Active Participant on 09-20-2023 11:51 PM 16 Comment

The following code will essentially do what I want, but I want this to be natively incorporated into the IDE as an option.

CaseyM_0-1695271655726.png

 

90%+ of the VIs that I write have a front panel that doesn't get shown to the end user, and yet, whenever you open a VI what does it show you? The front panel. I think the default behavior of opening a VI should be to show the block diagram ONLY. This would have several advantages for the developer:

  1. Fewer windows to manage - Even if you minimize the front panel, you can still accidentally restore the FP when you Alt-Tab or click in the taskbar which brings me to...
  2. Less clutter in the taskbar - Once you open more than a couple VIs, navigating to the block diagram of the VI you want in the taskbar becomes very unwieldy.
  3. You could more easily get to the BD of VIs running in a subpanel.
  4. It would be possible to get to the BD of a VI that has a custom run-time menu where Ctrl-E is disabled.

Ideally this would be an option in the Tools --> Options dialog (that I would always turn on).

 

This idea is similar to one posted almost 15 years ago, but I don't consider this a duplicate because this takes things a step further by not opening the FP at all.

Labels:
59 Kudos
approximately_whatever

FPGA timing functions with better labels

Status: New Submitted by Member on 05-13-2015 11:44 AM 2 Comment

When programming in FPGA, all the timing functions are polymorphic, meaning you have to configure it for either ticks, us or ms. If your not carefull, this can sometimes lead to unwanted error due to simply overlooking a wrong configuration, as in the following example picture:

 

How are the timing functions configured?

 

I propose a simple indicator or different icon to easily see the difference. Something like this, only maybe better looking:

Proposed solution

Labels:
59 Kudos
X.

Include longstanding "known issues" in the help file

Status: New Submitted by Trusted Enthusiast on 03-09-2015 01:17 PM 1 Comment

NI updater kindly informed me that LabVIEW 2014 SP1 was released (even though I uninstalled it shortly after I tried it last year) and out of curiosity, I took a look at the known issues list.

I learned a few interesting things I did not know about, and also that some problems had been reported as long ago as version 7.1.1. This type of stuff looks like bugs that won't be fixed, ever.

For instance, CAR #48016 states that there is a type casting bug in the Formula Node. It was reported in version 8 and the suggested workaround it to use a MathScript Node instead of a Formula Node (where is the "Replace Formula Node by a MathScript Node" contextual menu item?).

Problem: the MathScript RT Module is required. Even in my Professional Development System, this is not included by default. Does this really count as a workaround?

I read: we don't have the resources to fix that bug, or we don't want to break code that expected that bug.

In any case, this bug with most likely never be fixed.

The bottom line is, we can waste a lot of time as users, rediscovering bugs that have been known for a while and will probably never be fixed. As a user, I would really appreciate a courteous warning from NI that there are known traps and have a complete description handily available with the help file related to the affected function.

 

My suggestion: add a list of known issues (with link to their description) for all objects, properties, functions. VIs, etc, in the corresponding entry in the Help File.

View All (1)