LabVIEW Idea Exchange

Post an idea

When I have large projects with lots of classes, Labview's edit time environment slows down to a painful crawl. Almost every meaningful action triggers a recompile that gives me a busy cursor for 3-10 seconds. My productivity falls off a cliff and I avoid making important changes in favor of the cheap hack. (The dev environment has high viscosity.)

I often wish there were a way to turn off the compiler while I make a set of changes. I'm not interested in the errors at every single intermediate state of the code while I'm making the changes. I *know* the code will be broken after I delete some nodes or wires. Let me turn the compiler off, make my changes, and then turn it back on for error checking.

I'm sure there are lots of different solutions to address this problem. My preference would be to make compiling faster so it is unnoticable. I doubt NI will ship me a new computer with the next release. My second choice would be to stop loading all of the class' member vis when any single vi is loaded. I vaguely remember a discussion about that some time ago and it wasn't practical to do that. That leaves me my third choice--more control over what automatically compiles when I make edits.

It could be something as simple as Ctrl-Shift clicking the run arrow to toggle auto-compiling at the vi level. Or it could be a right click option in the project window that controls auto-compiling for an entire library or virtual folder. Either would be okay; both would be nice.

(For that matter, it would probably be a lot cheaper if NI just shipped me a new computer...)

View All (2)

I find myself constantly switching between Quick Drop and palette surfing for the functions I need. Sometimes I close the palettes just because they are in the way of where I want to drop a function. But I immediately need to reopen them to find my next function.

Can there be a setting in the palette options to hide or minimize the palete once I've selected a function from the control/function palette and once I've placed the item on my front panel/block diagram it will reopen to the same palette and spot?

View All (2)

I typically load LabVIEW by double clicking the project file in windows explorer. If I do this after a LabVIEW crash, when LabVIEW has files it wants to auto-recover, LabVIEW will go through the entire load of my project and then prompt me to recover my files. If I cancel this I then have to wait for my project to load all over again.

I propose that the auto-recovery happens BEFORE the project is loaded. I know I could just run LabVIEW and then load my project through the start screen, but with any program it is a lot easier to just double click the file and let the program load.

The current VISA read and write primatives do not have the ability to abort early. Under many circumstances if the timeout values are short this is not an issue but it can be an issue if a long timeout is required. The current work around is to use a short timeout value and loop continually ignoring the individual timeouts until a threshold has passed and then pass the timeout error out. This apporach requires the extra code to "monitor" the process of the communication. It also requires shift registers and associated logic to maintain the data. It would be desireable to simply set the timeout for the desired value and have a separate VISA property that can be set cause the current operation to abort.

This functionality is inspired by Microsoft Excel's hide/unhide functionality.

Suppose we have a code like this:

User should be able to select the portion of code he needs to hide, and be able to add a comment on that, something like this:

After he enters the comment, the block diagram would be shown something like this:

Similar option should be there for "Unhide".

The advantage of this would be the user can group a huge block diagram (for example having a flat coding structure) according to the functionality it does, without adding SubVIs to the project.

Regards,

FraggerFox

View All (1)

Many times, we are working on a LabVIEW code developed by someone else and hence we are not totally familiar with the front panel grouping, unless we try one at a time. Let me know if there is some special trick to understand the groupings.

If you try to delete an item belonging to Front Panel group from the Block Diagram, nothing happens.

It will be nice to at least get a dialog about it which will not keep the user wondering about the behavior.

It will be really nice if it is possible to delete the selected item of a Front Panel group from the block diagram.

I would like to be able to obtain the IP Address of an application instance.

Here is one scenario:

Plug in architecture.

Host machine loads plugin VIs that monitor several targets via VI Server.

The main VI opens the connection to one of the targets' application and sends the application reference to the plugin so this VI knows what target is communicating with.

It would be nice to be able to obtain the IP address from the Application Reference via a VI or a property node.

Now, I know I could be sending the IP Address instead of the application reference, but if I know I am going to be calling several VIs in the same target, why do I need to open an application reference for each VI, when all could share the same application reference.

Another scnerario for this was posted here: http://lavag.org/topic/6861-address-of-an-application-instance/

View All (6)

I'm trying to manage the properties of my LVLIB, and it's annoying....

Normally, for a VI I would open the VI, and then right click the icon and choose VI properties.

Well, LVLIBs don't have an icon in the upper right corner to do that with (they probably should have one -- the default icon template that I configure in the properties -- why should editing the icon template require me to go through some other weird location -- I already know the icon is the upper right corner of the UI).

So since I can't right click the icon and choose VILIB properties, I go to File -> VI Properties. ##$%$%^#$% That doesn't work either

This doesn't work no matter what is selected in the LVLIB (selecting a VI or the parent LVLIB element, or nothing).

Strike two for doing something I know to find the properties of the LVLIB.

Finally I found you can right click on the parent item of the LVLIB and find a properties selection

So I can get my job done, but why is this so hidden. It doesn't follow any of the other ways I've learned to find the properties, and to boot the properties window looks totally different between the LVLIB and the VI's

LVLIB:

and for a VI:

So How about this as a suggestion:

1) make the properties screens be similar (I realize they won't have exactly the same options or settings, but having two very different looking UI's for doing the same thing is confusing). I kinda like the LVLIB one better than the VI one...

2) support File -> properties when you are in a LVLIB to open the properties dialog

3) Since LVLIBs really have Icons (as evidenced by being able to edit their icon template for children) how about having that in the normal location (upper right corner of the UI) we expect from VI's, and being able to click on it and get similar menus.

In LabVIEW 2009 we have the ability to ask LabVIEW to clean up the code of a selected part of the diagram. Unfortunately though the developers of this feature allowed themselves to do something the user would not expect at all - namely to adjust the surrounding code as well during this operation....One might say that instead of taking the selection as an absolute border - they feather the selection...This will typically produce effects that the user did not want...in fact, if he did - he would have selected that extended area of the code in the first place.

Let's say that I have made a perfectly layed out code...but in the middle of the data flow there is one case structure that is messy. So - I select the case structure and expect this to leave the surrounding code absolutely untouched...but what happens? It allows the "interface" between the selected code and the rest of the code to be modified, and messes up what was already good code - that was not marked for clean-up(!). A very bad behaviour.

Please rewrite this so that it keeps the interface to the rest of the code fixed.

PS. This was initally added as a comment to the original idea for a selectable clean-up area that I submitted in 2009*, but on request I've subitted this here as a new idea... (*NI probably came up with that idea by themselves before that though, but at the time it was not known to the public).

Message Edited by Mads on 06-03-2010 08:50 AM

If I build an executable that incorporates any kind of .NET, such as the Simplicity AI PDF Toolkit, it obviously requires.NET on the target computer to work. If .NET is absent, the VI will load as a broken VI and an awful error message is displayed to the operator, typically along the lines of:

It would be great if we could place all our .NET code inside a Conditional Disable structure that accepts something like ".NET == True" as a parameter, thus allowing .NET code to run on a machine with .NET installed, but not resulting in a broken VI should it be absent. This would also give developers the opportunity to place something useful into the other case, such as a popup message stating ".NET is required for PDF generation." for example, or even some other replacement code if they so wish.

Therefore I would like to see the list of Conditional Disable structure pre-defined symbols include a new one for "Windows .NET"

View All (4)

I would like to see new Read and Write VIs for TCP and UDP connections that worked the same way the Read From Binary File and Write To Binary File work. These file VIs are polymorphic and allow you to specify the format of the data being written or read. With only the current Read and Write VIs available for the TCP and UDP connections we must always include typecasts or other data parsing. LabVIEW obviously has the means to do this since it exists for files. Extend that capability to the newtrok connections as well.

View All (3)

View All (6)

Removing the selected Ctrl-Key Shortcuts by pressing one button would be much easier and comfortable then the current solution.

Right now, you have to delete the appropriate VIs from the directory National Instruments\LabVIEW xxx\resource\dialog\QuickDrop\plugins. Additionally, you have to delete the shortcut entry in the LabVIEW ini file within the key name QuickDropKeyboardShortcutMappings. Otherwise the shortcut is blocked for further use (see picture below).

With the Remove button you have the possibility to delete everything (Shortcut and all corresponding VIs) or just the Shortcut without the VIs remaining in the LabVIEW directory (Therefore, the Shortcut has to be deleted from the VI description).

View All (2)

View All (9)

Whilst pondering Chris Relf's presentation on LVOOP based error handling for NI Week, it occured to me that it would be really nice if it was possible to define LVOOP methods that would be called automatically when LabVIEW needed to convert a class to a different (eg built in) type.

For example, imagine I have a class for handling errors - the obvious thing to do is to wire that class wire into a case structure selector and provide cases for error/no error. Of course that won't work, but if I could define a method that takes my class in and outputs an error cluster and was somehow appropriately marked so that LV would automatically call it, then the case structure could automatically do 'the right thing'.

The inverse functions that build a class from another type would be a form of constructor for the class that might be useful - e.g. I have a class that represents a measurement, wiring a path control into the class terminal causes LabVIEW to run a method that I have defined and appropriately marked that loads the measurement from disc and initialises the class.

There are a few problems I can immediately see - if one defines two possible conversion methods (e.g. class to error cluster and class to enum) one needs to have a way of defining which one is used (right click on terminal of node would seem the most obvious to me) and you'd probably want a specially covered coercion node as well....

View All (2)

What do you need our team of experts to assist you with?

Request a quote Find the right product Place an order Get support on a product

How can we help?

Please enter your information below and we'll be intouch soon.

This field is required

Preferred communication method

Email Phone call

What do you need our team of experts to assist you with?

Request a quote Find the right product Place an order Get support on a product

LabVIEW Idea Exchange

PID in base version. $1000 for PID?!!!!!

Text formatting ribbon within the toolbar (word style)

Selectively disable auto compiling

XY Intensity Graph

Autohide palette upon function/control selection

On recovery after a crash, check for recovery BEFORE loading project

Add an "Abort" event to VISA reads and writes

Allow Hide/Unhide of code inside Block Diagram, without using SubVI

Deleting item of a Front Panel group from the Block Diagram

Obtain the IP address from the Application Reference

LVLIB properties are too hard to get to

Fully restrict partial clean-ups to the selected area

Conditional Disable Structure to recognise .NET installations

Proper Smith Chart

New Read/Write VIs for TCP and UDP connections

Consider simplifying access to references to classes

Add Remove button to tab "Ctrl-Key Shortcuts" in Quick Drop Shortcuts menu

Make Sync.vim extendable

User defineable automatic LVOOP class conversion functions

add version tag to installer messages