LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

probe transaction log

a transaction log of all docked probe window activity, in a human readable format if possible. it should include probe position declaration, timestamp, data and conditional probe result. the transaction log is 'dumped' in a separate window, and optionally saved to disk. it is meant to work a bit like dbgview, which displays information sent via OS outputdebugstring() or debugprintf() on windows. maybe something like this already is implemented in the desktop execution trace toolkit 'DETT', but this idea is only for data of probes and is native to IDE. if gives a migrate path to DETT to see more info about execution behaviour...

View All (2)

I just downloaded a library and a project it was developed in. I tested it, and everything works fine. Then I copied the library (.lvlib, all .vi files and preserving folder structure) to a new project, but when I open it I get a conflict saying that the same library is defined twice? A conflict that cannot be resolved BTW.

I spent 30 minutes just getting out of the mess this puts me in. The result, project2 is now OK, but project1 now complains that it has duplicate code. Come on! I know I have two copies of the same library! I want to have two copies of the same library! Why can't LabView just use the "local" version and not complicate my life with something that happens to lie on the disk somewhere and has absolutely no connection to the current project?

View All (2)

View All (13)

I often use strict type definitions to change data between SubVIs. The wires of the type definitions are always pink and this is sometimes a little color chaos.

Strings are pink, clusters are pink, ...

It would be nice to have the feature like in the LabVIEW classes. There you can definie the look of the private variables wire (form and color).

We all (should) check if an array is empty before passing through a For Loop, if we are indexing it and any references or values pass through the For Loop so that we pass null references or default values for the data type.

Most people use either an "Array Size" primitive for selecting "0" or "Default" or an "Empty Array?" primitive for selecting "True" or "False" in a case structure around the For Loop.

If we could just wire the array to the Case Selector and have it automatically create two cases "Empty" and "Has Data" or something, it will make the diagram cleaner and easier to read, while saving a few second for every instance of use.

View All (1)

Using the LabVIEW 2009 Build Spec (as an example) allows you to add a Destination to a Library which is very handy, as it means you can namespace VIs at build-time.

I would like to take this a step forward and then be able to set that new Library as a Sub-Library of another Library that already exists in the Project.

I would then want to be able to set the scope of this Sub-Library as well (relative to its now, Parent).

This combined with my Locking State Idea would allow be create a Distribution that would hide and protect a Support VI Library

As the Sub-Library would be Private Scoped (from above) and the Parent Library would be set Locked (does not show Private Members).

I currently can implement this using Scripting but it would be nice to have it native.

Cheers

-JG

View All (11)

Hello!

What I really would like to se implemented as a future feature is a 'Search 1D Array.vi' with the option to do a case insensitive search.

Usually I just plug a "to upper case" vi on both array and search string inputs. It would be nice to be able to select it right on the vi instead.

The functionality should work as with the case insensitive match in the case structure.

Cheers!

//Beckman

Use Current Value If Unwired

It would be beneficial if nodes had the ability to retain data from their previous execution. Along with "Use Default If Unwired" it would save memory allocation and coding time if there was a "Use Current Value If Unwired" selection which would retain the node's value and pass the last executed value.

This figure illustrates one application where "Use Current Value If Unwired" would save memory and increase performance instead of using multiple property nodes or local variables for retaining the output data. It would also eliminate extra wiring in every case this node is not used.

View All (6)

Hi,

in LV2009 a new set of VIs have been published for working with configuration VIs. They are now part of config.lvlib. But some VIs of config.lvlib are marked private, therefore I cannot use these VIs as Sub-VIs, if the calling VI is not part of config.lvlib. This is bad (at least for me), since I have written some tools to load a configuration directly from a string and not from a file. To do this in LV2009, I need these private VIs, which I cannot use without changing config.lvlib.

Therefore I suggest to make all VIs of config.lvlib public. In fact, is there a good reason, why these are private in the first place?

Regards,

Marc

When developing LabVIEW automation tools, I miss a way to list the controls connected to a VI's connector pane. That would make it possible for the user to better select which controls to set before calling a VI (dynamic VI call).

An "IsOnConnector" property on a control reference would be very useful. Or better; a property returning an enum with one of the four values: "NotConnected", "Optional", "Recommended" and "Required".

Another solution could be a property like the Controls property on a Panel reference, but only listing the controls on the connector.

MAX - Historical Data Viewer

In the LabVIEW development environment it is possible to separate the shared variables via virtual folders. In cases with more than 100 variables it is very difficult to keep a structure at runtime. Therefore it would be a great improvement for us to implement a new hierarchical level (name of the virtual folder) to ensure a well-arranged structure also in the runtime. This structure should be kept in the Shared Variable Engine and also in the Citadel Database.

View All (2)

I would like to see and option to use our development system that is enabled by a hardware key. That way, you can put it on any machine you want for development without worrying about licensing. A lot of LabVIEW applications are one of a kind systems, complex systems. The programmer does not always have time to add a lot of code for all the errors you can encounter. With the debugging tools in the development system, debugging would be much easier than trying to debug a built application. This would enable the owner of the software to load his system on a target machine and when he is done developing the application, he can build it as normal. It would be desirable to also be able to use you key for connecting to a remote site, using remote desktop, pachyderm, etc. This would greatly help for field support of application. It would also make it easier to support previous versions of LabVIEW, as the project and software would be on the target machine. Changes that could take days could now be done in minutes.

If you use the NI proposed way of creating Sub-VIs for functions (which is good), debugging soon becomes a nightmare with every VI opening two windows, one of which is mostly not needed (the front panel). It would be great if LV gave us an option saying "Do not open front panels when debugging", which would only open the block diagram. Instead of the front panel you could only offer a list of all input/output controls (and maybe their values), and you could put this list in the same window for all open VIs (in some organized way - maybe similar to probe window). That way all front panels would only take up one window instead of many.

Allow multi-line comments

View All (1)

Disable Maximize Button

View All (4)

LabVIEW Idea Exchange

probe transaction log

Make libraries and VIs less environment aware

Add Option to Collapse (Shrink) Control on Front Panel to Smaller Icon

Individual wire color for type definitions

scrollbars for block diagram structures

Wire Array directly to case structure to check for empty array

auto populate icon with text from vi name

Option to Add LabVIEW Project Library To Parent Library and Set Scope in Source Distribution Build Spec

Array string search case insensitive

Use Current Value If Unwired

Make all VIs in config.lvlib public

Property indicating whether a control is on the connector pane

MAX - Historical Data Viewer

Shared Variable Library - Separation

Hardware Key for development systems

Reduce window clutter in debug mode

Allow multi-line comments

Reinitialize stacked shift register.

Disable Maximize Button

Do not loose focus after pressing enter