LabVIEW Idea Exchange

Community Browser
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

For all the years programming LabVIEW this is something that has always bothered me. My development system has a monitor much higher resolution than the monitors on our ATE stations and it is very easy to end up with a panel that is too big for the target machines. 

 

While I can set a MINIMUM panel size it would be nice to set a MAXIMUM panel size or be able to turn off the "Auto grow" on front panels. 

 

Also related to this being able to turn off scrolling and "Auto Scroll" on front panels in the IDE.

 

Once I get a front panel set, I want to be able to "lock it" and have it NOT MOVE up, down, left, right or grow for any reason.

This one's pretty simple...  Multicolumn listboxes have a "Moveable Column Seperators" property that's available from the menu at edit time:

_carl_0-1598023462090.png

But this property isn't exposed through property nodes.  I'm currently in a situation where I really wish it was!

 

I'm not the only one who's encountered this:

https://forums.ni.com/t5/LabVIEW/Moveable-Column-Seperators-Property/td-p/2217334

I often open a subvi while the calling vi's are open.  I make a few changes.  I try the changed code and decide I prefer original.  If I try to close the vi without saving it is not possible.  I must select "defer decision" to save.  Then when I later close the main vi, I am asked to decide whether to save the subvi or not.  By then I may have forgotten that I did not want the revisions saved or simply use the apply decision to all by mistake.  Allowing a close without saving at anytime would be most welcome.

Add an "Explain Error" pop-up menu on the conditional error probe.

The Generic Probe has this, why not the Conditional Probe?

 

Generic Probe:

10-9-2009 5-24-12 PM.png

 

Conditional Probe: 

 

10-9-2009 5-20-20 PM.png 

Message Edited by Michael Aivaliotis on 10-09-2009 05:27 PM

When I duplicate a VI inside a library or class using Save As... and check the option to add the duplicated VI to the class/library I would like the new VI to be placed in the same virtual folder as the original.  I will settle for what I asked for in the title, an additional option to perform the same.

 

SaveAsOption.png

 

                Align the upper terminal of "Swap Values"

 

SR2.png

CVI has this feature, almost every other UI library has it, too.

Only LabVIEW is missing the simple option to limit the number of characters that can be entered into a string control.

 

I know, it is possible to do this programmatically. But this is always a piece of extra effort I have to undertake, while the solution never looks really satisfactory.

Usually all I can do is react to the value change event of a control and cut what's too much. But this means the user sees some flickering, since the character is first drawn and the corrected version is drawn at a later time.

 

Side notes on how I think this should be integrated:

This should be an additional property for all string controls. For existing controls from older versions, the value should be set to it's default (-1), which means unlimited.

If activated, this feature should also cut the strings in VI input terminals to avoid "special behaviours" in this case.

Today, when you create a case structure and wire a string to it, the case structure becomes case sensitive. This may have been relevant in the 1970s, when every bit was important, but these days I'm guessing that in at least 95% of the cases the structure should be case insensitive, although most people are probably not even aware that you can change it.

 

So, why not make the structure default to being case insensitive instead of case sensitive?

 

Actually, I would possibly even suggest removing the case sensitive option altogether, but this is probably required for some things and would break existing code which relies on this.

Message Edited by tst on 20.04.2010 04:43 PM

 

If code is running and one happens to leave a modal VI open, or opens a modal VI in the middle of a running piece of code, then the LabVIEW environment freezes-up and dis-allows any interaction with the code. It will be great to have a set of Key Strokes to re-set the code if this happens. The only way that I know of now is to hit [ALT + CTL + DEL] and killing the LabVIEW process. This ends up loosing unsaved work and requires a restart of LabVIEW.

 

Regards

 

Anthony L.

The configuration panel of express VIs has the [X] disabled in the upper right, but contains standard [OK], [Cancel] and [help] buttons.

 

Every computer users is familiar with the function of the window close button [X], and for convenience it should be enabled unless there is a very good reason to disable it. Such a reason does not exist for express VI panels. Pressing the [X] should act indentically to pressing the [Cancel] button. Note that even the <esc> key is already bound to the cancel button as it should!

 

So why is [X] disabled? This is unecessary micromanagement of the user! Do it like this, not like that!!! (slap on the hand!)

 

Users should have all intuitive and typical methods available to cancel out of an express dialog:

 

  • [X] (currenty not allowed for no good reason at all!)
  • [Cancel]  (already mplemented!)
  • pressing <esc> (already implemented!)

 

Idea summary:

The configuration panel of express VIs should have the windows "close" button ([X] in the upper right) enabled and when pressed, it should act identically to the [Cancel] button on the panel.

 

IdeaCloseExpress.PNG

 

 

I tried to use In Range And Coerce with a Waveform.

 

Unfortunatly this is not possible so I came up with the following alternative:

CoerceWaveform.png

 

Please make the following code possible:

CoerceWaveform2.png

For as long as I've been using LabVIEW, I've often turned to the LabVIEW Help file (which is a compiled HTML file) and found very little help.  I'll search for something simple like "For Loop" and receive 500 (literally, try it for yourself) possible topics, including the Cohen-Coon Autotuning Method, Control in NI-DAQmx, Limit Specification VI, and so on.  These have nothing to do with For Loops.

 

I'm proposing that the LabVIEW Help be turned into something that is ACTUALLY helpful.  I'm not sure about the best way to do this.  I think that it should still be portable and shouldn't require any Internet access to use (as lots of us cannot access the Internet on our development machines).  I would really enjoy a tool that would allow me to search for something like "For Loop" and receive like 5 topics that all have to do with using a For Loop in LabVIEW.

I find it always a hassle to create an asynchronous call with the need of the "Open VI Reference" block. A strict static VI reference should be sufficient. Options should be either available in the properties via context menu, via property node or as input of the "Start Asynchronous Call Node".

 

I didn't go through the effort to create a property menu example, but here is an a graphic showing the help example and what I would wish for:

 

Call Options Example.png

Really, athe end of the building process it would be nice to know how long the building process lasted.

 

One of the benefit would be to make build duration comparison between different LabVIEW versions much easier 😮

 

Clipboard01.jpg

How many splitter bars does this VI have?

 

 

 

The answer is three, but they might not be where you think:

 

 

It would be useful if LV showed the splitter bars more clearly in edit mode. Switching to run mode would display them "correctly".

 

 

 

This idea is similar to Show hidden controls as "ghosts" in edit mode and the same basic concept can be extended further. If anyone has anything else which is difficult to see and can be shown more clearly in edit mode, why not add it as a comment?

This idea is an extension of the idea given here How about a Front Panel Cleanup?. We could have a more generic front panel clean up which doesn’t really worry about the connector pane patterns (and if needed automatically connects the connector pane as well)
Here is the idea->
Often while writing a VI we create controls and indicators from the block diagram itself rather than going to the FP and creating it. Also we copy Control and Indicator terminals from other VIs and type defs and directly drop it on the block diagram than the FP because BD is what we are usually working on. Once BD is complete we look at the FP just to make sure everything’s visible and is in a good shape. Often we find that many controls and indicators are missing from the view and are badly organized. It is painful to search for controls and move them into view. Instead an FP cleanup could put things into the visible space and organize them in a simple way (controls to the left, indicators to the right, similar controls and indicators on the same level, error cluster in the bottom etc). For most cases this might be sufficient. If not it could be used as a starting point to organize your FP. Also at the same time we could automatically connect these items to the connector pane as well. If you already have organized some items on your FP and you don’t want that to be disturbed, you could select such objects and exclude it from your FP clean up.
Example->
Let’s say you are working on a block diagram creating controls and copying some from other VIs.

working area.JPG

Now you look at the front panel and see all the controls and indicators scattered.

before 1.JPG

Also many of them are not even visible in the FP area.

before 2.JPG

Simple FP clean up with connector pane connection will put it into this state.

after 1.JPG

Note the connector pane as well. The user can either use the VI in its current state or use it as a starting point to organize his FP.

As already partially mentioned in a very old discussion here, the integer display formats should have more typical defaults:

 

  • If I change an integer to hexadecimal, octal, or binary format, I want it padded with zeroes on the left and the default number of digits corresponding to the data type (e.g. U8: 8 digits for binary (%08b) and 2 digits for hex (%02x), U32: 32 digits for binary (%032b), etc. ).

 

These formats should appear whenever I switch formats from decimal and I can immediately change them to anything else if desired. If the current format is not decimal and is at the default for the current datatype, the format should adapt (e.g. more or less digits shown) if the datatype (e.g. U8>>I32) is changed.

 

When you do a search for something in the hierarchy and you have a password protected VI, you get this dialog:

 

 

 

 

Often (for example in this case) we don't have the password for the VI and never will because it was developed by someone else. So why not allow us not to see this in the first place?

 

  • First idea - Don't display this at all for VIs in vi.lib. Just skip them.
    Presumably before LabVIEW ships the VIs aren't locked anyway, so the LabVIEW developers shouldn't have a problem, and if they do, let them do a programmatic unlock. The users shouldn't be the ones to suffer.
  • Second idea - Generalize it a bit more. Allow us to have a configurable list of folders where the search won't bother to try and unlock VIs (so that if we have locked code from other vendors, we can discard it as well). The default folder for the list should be vi.lib.

I'm looking at a clone. I don't see why I would have to ctrl-M to get an editable version to do such things as:

 

- get the contextual menu up on the VI's icon to 'find all instances'

 

- get help on a VI that's on the clone's block diagram

 

- open or find all instances of a typedef via its contextual menu (the typedef being on the clone's front panel or back panel)

Reading this or that, I think I'm not the only one to want XControl accept multiple data types.

One of my use case is an XControl using "XYGraph Data type" as Data. "XYGraph Data type" can be Cluster or Array of cluster.

I believe there are much more use case where polymorphic Xcontrol could be useful.