From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW Idea Exchange

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

Right now when you bring up the icon editor for a VI, you get something like this

 

icon_now.jpg

 

Which doesn't tell you anything about what VI you are actually editing the icon for.  Which is a little confusing if you have multiple VI's open, go get a cup of coffee and come back and forget what was going on.

 

I think it would be much nicer if we add the name of the vi to the Icon Editor titlebar (just like it is for the block diagram and front panel) so it looks more like this:

icon_future.jpg

It would be nice if the Error Ring would accept enums.

Enum in Error Ring.PNG

So the Error Ring does not accept an enum (A). Format Into String does (B). So now we need the extra step of putting a Format Into String before the Error Ring (C).

 

This would be more convenient in for instance state machines (D) or functional globals with a function enum.

 

While on it %s on FIS also accepts Booleans. Nice to have the error ring accept them as well, just for completeness.

I have a large library of general purpose functions and I do a lot of OOP in LabVIEW, and as a result my preferred workflow involves dragging a lot of functions from the project explorer window onto the block diagram. This workflow is slowed down, however by the fact that the project explorer window is regularly hidden by other windows when I click on them.

 

What I would like to see is something like most development IDEs have, e.g. Visual Studio, where I can have the project explorer always visible in a fixed position on the screen. I suggest this would be an option, so would not affect those who like things the way they currently are.

This is minor one but it bugs me every time.

 

I create a new control and forget to change the type from "Control" to "Type Def.".

 

If I'm lucky I spot it after I drop it for the first time on the BD but sometimes I have to replace quite a few instances after I spot the error.

 

While there might be usecases for a custom control without it being a type def I think that most users want to use type defs when using custom controls.

 

Therefore please make the default type of new controls "Type Def."

It's got to be a duplicate, but I could not find it...

A significant number of vi.lib VIs are still outputing error codes (I32) instead of an error cluster.

For instance, the famous Ramp.vi:

 

ScreenHunter_002.jpg

 

returns an error -20006 if you ask for zero samples. Type in this value in the "Explain Error..." window of the Help menu and you get:

 

ScreenHunter_003.jpg

 

So it's not that the error code is mysterious and cannot be interpreted (I must say I was a bit puzzled by this discussion on error codes).

NI has to fight with this problem themselves. For instance, here is the code you find in the NI_AALPro.lvlib:AAL Resample Filter Prototype Design.vi:

 

ScreenHunter_004.jpg

 

What is that "?!+Magnifier" VI , you'll ask (AAL Error Information.vi, in the same library mentioned above)? I am probably supposed not to post it, but I will nonetheless, considering what it REALLY does:

 

ScreenHunter_005.jpg

 

Yep, it simply returns the same numeric error code value (again) and the call chain for the VI generating the error (but it won't tell you that the real source is the DLL called in the "Kaiser" VI above). I assume (but I can't prove) that the codes returned by the analysis library are among those recognized by the Explain Error VI.

 

It is not only an annoyance to not be able simply connect VIs using an error cluster wire, it does not make error handling particularly easy (basically, the way I read the answers of Aristos Queue and Norbert_B in the thread I quoted above is: "reverse engineer our VIs if you really want to 1) get the complete list of error codes it can output, 2) understand their cause").

 

My suggestion: Hire a couple of interns to sift through NI's VI librairies and change error code outputs into error cluster outputs with proper messages.

 

Obviously, for compatibility reasons, open previous code with an added unbundle primitive which will return the old error code (with a list of warning after the first compilation). You've done that before and we have survived.

 

 

Custom probes are great, however unlike the default probes you do not always have them with you...so why not just make the default probes just a tad smarter? 

 

- The array probe e.g. should not just show a single cell - it should by default show at least some of them (1*10 for 1D, 10*10 if 2D etc. e.g.), have it's scrollbars visible and be resizable?

 You could add some core information about the array, like it's size e.g. in an indicator on the top as well....and perhaps have a pull-down menu for the display format. Keep it general and simple of course, but a bit more convenient than today's probe.

 

 

- The string probe should also be resizable and have a control that let's you switch the display format.

 

- etc.

 

 

It is currently possible to add space to the block diagram by drawing an area or line with the cursor while holding down Ctrl+Shift.

 

I often wish there was an equivalent opposite shortcut;  where you could draw how much you want the diagram to contract instead...

Message Edited by Mads on 07-03-2009 08:31 AM

While replacing the Property nodes with Invoke node, Call by Reference, Start Asynchronous call and Wait on Asynchronus call, the primitives are shifting the origin disturbing the wires. So a cleanup is reaquired all the time whenever the items are replaced. It would be very helpful and infact time saving if this is corrected.

 

Place a Property Node in BD with the Error in and Out connected

 

PN-IN-Replace-1.PNG

Replace the Porperty Node with an Invoke Node

PN-IN-Replace-2.PNG

Repeat the same with other primitives

PN-IN-Replace-3.PNG

PN-IN-Replace-4.PNG

PN-IN-Replace-5.PNG

PN-IN-Replace-6.PNG

PN-IN-Replace-7.PNG

The same behaviour is not found when the Call by Reference, Start Asynchronous call and Wait on Asynchronus call primitives are replaced with one another.

 

Consider the following scenario:

 

You have a front panel with a fixed size and all controls are placed exactly as you want them.

Now you click a wire on the diagram and select “Create Control” or “Create Indicator”. In my experience this new control is created outside of the front panels bounds in 90% of all cases…

 

Now you need to resize the front panel, find the control, move it to the desired position, and resize the front panel back to its original size. And if you’re really lucky you also need to scroll around the front panel and set the origin back to its original position...


I’m aware that I could set the front panel and window bounds properties at the start of the program to set the size and origin of the FP, but that doesn’t help me much when I’m editing. I would need to start the VI once to set these properties.

 

Life would be so much easier if the control would just be placed in the center of the front panel…

I've often produced VIs with non-array controls and indicators only to find that by changing them to arrays I can increase the power and functionality of my VI. When this happens you have to create the array element, drop in your control and then if it is connected to a VI input or output pin, rewire the pin.

What would be nice is to simply have the Add Dimension capability available for a non-array control to instantly convert it to an array and conversely the Remove Dimension to convert a 1D array control back to a non-arrayed control.

 

Add Dimension.jpg

Currently, the VariantDataType  are buried deep in VI lib but they are very useful when trying to program based on datatype. Can we bring some of those functions into the light?

 

http://forums.ni.com/t5/LabVIEW/Darren-s-Weekly-Nugget-10-05-2009/m-p/996866

http://forums.ni.com/t5/LabVIEW/Darren-s-Occasional-Nugget-03-25-2014/m-p/2791974

 

Get items from enum

The installer build spec dialog should analyze the components being installed and suggest what additional installers will be needed to allow the EXE (or what ever else is being installed) to function on the target machine.

Also, the 'Additional Installers' catagory screen should have detailed help explaining what each installer is for and why you might want to include it.  Just looking at the names is not obvious enough.  A good example are the following installer from the list:

 

LV Web Services

NI LV Web Services Runtime

NI LabVIEW Run-Time Engine Web Server 

NI LabVIEW Web Server

 

Can you tell me which one(s) of these is needed to support the RESTful web services on a target machine?  I cannot find this documented anywhere and when I called NI application support they could not either. 

I've long wished Labview had native support for Interfaces.  Recently I ran across an article describing Traits as a better alternative to Interfaces, Mixins, Multiple Inheritance, etc.  Traits are (as near as I can tell) similar to Interfaces with the main difference being Traits can define a method implementation while Interfaces can only define a signature.

 

I'd like to see Traits implemented in G instead of Interfaces.

 

(Cross posted to LAVA.)

 

 

Event Sources can be time consuming in finding when you have lots of FP objects.

Like the idea with Right Click menu option on terminal to add Event Case if it is applicable. (Event Structure must exist)

 

Also it would be useful if we have option to search Event Sources in Edit Event Dialog Box. As you type the name of the terminal it sorts it self and display only names of event sources that matches.

Properties of a numeric control or indicator is using a scroll box to set the Type (see dump below). A closer look reveals that this dialog is poorly laid out - there is plenty of room to display all the contained information without having to resort to a scoll box. This issue appears to be specific to LV2012. In LV2011sp1 it is nicely done.

 

This is a very simple and low risk thing to correct and improves usability at virtually no cost. It may appear as an insignificant thing, but a top notch tool like LabVIEW should take care of all such small details.

 

Here is a dump of before and after the improvements...

Display type scroll box.png

When I don't know a VI too well or am not really sure what I am looking for it would be nice to have context help display information for the items in the Quick Drop window.  For example I was looking for a noise VI and wanted to see the inputs and outputs of the VI's listed in the quick drop, but you first must choose a VI to get this information. 

 

 

In addition to displaying the names of all palette items, Quick Drop will also display the names of all VIs, classes, typedefs, etc., that are present in all currently-open projects. It has been suggested to me that we should provide a configuration option in Quick Drop to only display project items from the currently "active" project, to avoid potential cross-linking issues that can stem from accidentally dropping an object from one project into a VI that is open under another project.

I often need to interpret JSON formated Strings.

Until now I use regular expressions.

 

A JSON-Parser (like the LabVIEW-XML-Parser) should simplify the expense for me drastically.

On downloading a file from internet and if the file already exists (file with the same name), it automatically appends an auto-incrementing number to the file name, wouldn't be it nice to have the similar feature (may be optional) with Open/Create/Replace File Function.

 

Append with auto incrementing number in the file name

 

 

Consider the scenario, you've enabled this option ('append number if file already exists' as shown in above figure) while using Open/Create/Replace File Function and operation input is 'create' and name of the file is MyFile.txt, which already exists then this fuction should create a new file with name MyFile (1).txt (or may be MyFile (2).txt if MyFile (1).txt also exists and so on).