LabVIEW Idea Exchange

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

I seem to spend a lot of my time in the LabVIEW IDE waiting. Waiting for LabVIEW to load dependencies, or do this or process that. For some projects with FPGA and CompactRIO I've calculated that I spend about 80% of my time just waiting for LabVIEW development environment to catch up.

 

Given LabVIEW's multi-core nature, it seems embarassing that I can create code to run blisteringly fast on a massively multi-core number-cruncher, yet the IDE itself is painstakingly slow. I wonder how much of these delays could be mitigated by a multi-core capable development environment? LabVIEW currently runs on just one processor, and with the increasing prevalence of multi-core CPUs as opposed to faster indivudal core speeds, I wonder if the chaps at NI are thinking of taking the plunge into a multi-core integrated development environment? I seriously hope so.

Sometimes I do dumb things. One example is that I often forget to stop running an executable before attempting to rebuild it. The AppBuilder eventually fails because the file is locked--it can't delete & recreate the *.exe file if it is actively running--but sometimes it takes several minutes before the AppBuilder gets around to checking that. It would be nice if it did the file permissions check earlier in the process, so my foolishness doesn't slow me down excessively.

 

Also, since the "cancel" button for builds doesn't actually do anything, even if I notice it immediately, I'm still stuck twiddling my thumbs for a few minutes until the AppBuilder *realizes* it can't complete the process....

Unlike the capability to swap diagrams in regular case structures, the conditional case structure CANNOT swap diagrams. It would be nice if the conditional case structure could swap diagrams to avoid pulling out code from one case into another.

The Undo (Ctrl-z) menu option is not available in stand alone applications built in LabVIEW.

 

The LabVIEW help confirms this: http://zone.ni.com/reference/en-XX/help/371361G-01/lvdialog/application_item_tag s/ 

Look where it says: "Items followed by two asterisks (**) are available in stand-alone applications you build in LabVIEW."

Then look for Undo and Redo in the Edit menu and you will see that they are not followed by the (**).

 

I posted the code that I created to implement Undo for exes: http://decibel.ni.com/content/docs/DOC-14805, but I believe we should be able to use the "Application Tags" instead of having to create code for something that is already implemented in the Development environment.

We use NIRG a lot, and I'd like to move away from what looks like random free text on the block diagram to a text block that's instantly recognizable as a requirement.  Kind-of related to this idea, but specific to NIRG.

 

be able to choice the "minus sign" for the negative non-decimal numbers

 

            i'm only talking about the way that an indicator can display a number.

 

                                                  like this,

 

                     demo.png

 

minus.png

HI

In installer creation, provision should be available for executing any third party installer/executable before starting the LabVIEW application installation.

 

And

 

After installing any application developed in LabVIEW, we can see that in Start > Program > <application>, is there any way we can get uninstall option in same menu (Start > Program > <Application uninstall>. (so it remove all the components were installer with the application)

I am guessing this idea won't go anywhere, but sometimes it would be really nice to have more than one i terminal in a loop. I cross a lot of wires in ugly ways to get that iteration number to different places and sometimes its hard to track down when i move it around the loop to avoid wire crossing. It would be great if you could right click on loop and say "Add iteration terminal" and then have access to the value multiple places. and maybe another right click option for "Find iteration terminal". Then you could also delete the extras.

 

Even if you could add something like a local variable for it or something that would be great. I know it would be tricky as it can only belong to that loop and so it has to be treated special. But it would be so convenient.   

And let people delete them all if they are not using it. 

While working with index array (or similar primitives) we have to use the index element as I32 format only which is really a question when using them in FPGA code. In most of cases I know the amount of elements in the array I am going to handle. So it would be a better option to make the Index terminal as polymorphic and it accomodates Integer values (I8, I16 and I32).

CustomIndex-old.png

CustomIndexValue.png

This idea is not only for FPGA, and also it applies to all the array primitives which uses index terminals.

Download All

I am posting this idea because when you select "View > Tools Palette", you should see the tools palette!

 

The following knowledge base:  http://digital.ni.com/public.nsf/allkb/84FCD62020BF074186256569008375E2  does not work or does not work all the time or does not work in my situation.

 

The issue is discussed here.

 

A brief description of the issue is when more than one person works on a remote station and one individual has a screen ;arger than the screen from the remote station and of the other person developing software remotely, the person with the widest and most resolution can bring the tools palette (and maybe other palettes) to a section of the screen which is not accessible by anyone else.  As a result, the tools palette I can no longer be used, until the person with the widest screen brings back the palette into view.

 

We cannot depend on a parameter within the  LabVIEW.ini file, as it is not always listed in the initialization file.

example:  toolPaletteLoc=400,1499,551,1577

 

The recommended idea is that when selecting "View > Tools Palette", either bring the palette to the center of the screen or implement an intelligent routine that determines the size of the screen and bring the palette within a viewable area.  Since others must also develop on remote stations, bringing the palette to the center of the screen would be the better option as their development screen may be of a different size than that of the remote screen.  Furthermore, it will make it easier to find the tools palette when requesting to view it.

 

Thanks!

Now LabVIEW is not able to handle .net DLL generic datatypes like lists.

Would be very useful if next generations could handle this.

 

Thanks. 

Background

The LabVIEW project window has two tabs: (1) Items (2) Files. The "Files" view is very useful to me as a quick check to make sure all subVIs are loaded from expected locations.

 

I am not aware of an equivalent view into the current Vi hierarchy if we don't use a LabVIEW Project. Maybe I haven't found it yet. 😉

 

Idea

My Idea is to have an optional window that show the current VI hierarchy in a layout very similar to the "Files" view of the LabVIEW project, even if we currently don't use a project.

 


 

(Image for illustration stolen from this article)

I sometimes want the first result from a tunnel on a loop. I end up using a auto indexing tunnel and then just indexing off the 0th value. Not a huge deal, unless the data type is something huge or I am doing tons of iterations and then I am just wasting memory. I guess I could put in a last value and make it conditional on i=0 but that is extra mess. You would probably want to make the tunnel icon look different so its obvious whats happening. maybe something like

tshurtz_0-1587680626172.png

 

My idea is to provide references to parts of complex objects (this is already done in a few places but needs to be a general policy). For example, on a table there is a lot that coud be done with the column and row labels (like text rotation) if I could get a reference to just that part of the object.

 

Mike...

I don't like that controls, type defs and strict type defs all have the same file extension: "*.ctl".  I'd like to see something like:

 

  • Standard control: *.lvctl
  • Type definition: *.lvtypedef

(I don't think there needs to be two extenstions to distinguish between type defs and strict type defs).

When you drop a VI on the block diagram it's becomes statically linked to the calling VI. If instead you wanted to call the same VI dynamically (without creating an edit-time dependency by using a Static VI Reference) you'd have to change the code to, instead, open the sub VI's ref by path, create a type specifier and then wire the reference to a Call by Reference node.

 

Why not instead just provide the option to call a given sub VI dynamically by right clicking on the sub VI itself? I'm picturing a right-click menu that has two options:

  • Static Call (default)
  • Dynamic Call

If "Dynamic Call" were selected, all the steps to convert the call to dynamic would be handled would be handled by the IDE/compiler without the developer having to actively modify the block diagram. The IDE has 90% the information to make this happen, right? And the missing information could be provided by an options dialog if necessary (e.g. synchronous vs asynchronous call, run as sub VI vs top-level).

 

There should probably be some sort of visual indicator on the BD that the sub VI is being called statically vs dynamically.

When performing some scripting I found it handy at times to create the block diagram objects, use a Cut Selection method on the selection objects, and then I would have the image of the objects in my clipboard.  The cases when I needed this I also needed to delete the scripted objects so this one method performed the delete, and allowed me to have an image of the scripted code.

 

When doing the same operations on the front panel I noticed there isn't a Cut Selection method on either the panel or pane classes and made a post about it.

 

http://forums.ni.com/t5/LabVIEW/Missing-Cut-Selection-Front-Panel-Method/m-p/3190560

 

This idea is to create the Cut Selection method on either the pane or panel class (or both I don't really care) which operates like like the Copy Selection, and Delete would today.

The new icon editor is a big step forward compared to the old one, but there's still room for improvement.

One big issue is using anti aliased/sub pixeled text, like Tahoma.

 

As the picture shows, text written in text fields are AA'd towards white, not the actual color (top row), but when writing the text directly in the picture it gets AA'd towards the background, making it alot prettier and easier to read (2nd row).

 

All text should ofcourse be AA'd towards the color shown, i guess it's an issue with the merging of the icon.

 

regards

/Albert

Have a property node function that can set the aspect ratio of the gridlines in a Graph based on the data. Similar to the 'asp = #' function in r

Find items with no callers contextual menu on class and library root nodes like available in a projects.