LabVIEW Idea Exchange

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

I just finished installing LV15 (and device drivers) on a new PC and I think the installer window could use an upgrade.

When expanding the different features you can install beyond 2-3 levels, they disappear out of the narrow tree-area. 

 

It would be awesome if I could then just resize the entire installer and it would grow the tree (and description) so I didn't have to use the little horizontal scrollbar

 

installer with 3 levels expandedinstaller scrolled to the right

I'm making Icon Templates out of the styles of icons I use most, and discovered it would be very useful if I could create a template and change one glyph layer for each template.

In the example below, I could load the Q Ref template, quickly remove the Q Ref layer and replace it with another control glyph.

I do realise I could just select the pink box and delete, but not all glyphs are nice easy to selct shapes and sizes

 

3.png

 

The templates with layers should be seen with the other templates, but when selected, recreate the individual layers in the layers tab

 

4.png

I think it would enhance the usability of XControls if it is possible to define events that an XControl can generate and that can be statically linked to just like other control type-specific events.

 

Earlier discussions on this topic has been done on LAVA and LAVA.

 

Ton

If you have a local variable and you either rename it's control/indicator, or you click it to change it to refer to a different variable, all local instances resize based on a centre justified behaviour, which can have undesireable layout issues.


For example here is a what happens when it's made longer next to the bounds of a case structure.
(The Boolean is provided to show how it's aligned, and also to show it resized the case structure).

 

 Screenshot

If the local variable were Left justified as a 'Write' type (expands to the right when changed) or Right justified when a 'Read' type (expands to the left when changed) it wouldn't make such a mess of things!

 

The error ring control is awesome having its parameterized input strings which supprots things like %s, %d, and %f to customize your error string.  This is not supported by the error ring when you are defining the string in an external project erorr code file however, and that is a problem since you then can't localize for multi language from external files.

 

This idea is to add parametrized inputs to the error ring for ALL errors, custom or loaded from project resource files.

 

see screenshot below.

error ring.jpg

What you get when you place a radio button group:

 

Example_VI_FP.png 

 

What you do 99.99% of the time:

 

Example_VI_FP2.png

In LabVIEW it is not possible to have an array of arrays. Something that gets you close is a 2D array but each row must be the same size. You can have an array of clusters of arrays to get around this limitation. Many languages do support arrays of arrays.

Originally suggested by RavensFan.

 

LabVIEW scripting makes it possible to automate repetitive tasks in LabVIEW, but it is often difficult to find the properties and invoke nodes to accomplish the task. It would be great to have a recording feature that watches what you do in LabVIEW, and then generates the corresponding code for it. I'm sure the engineers at NI could design it much better than any more specific ideas I could throw out, so I will leave the rest up to them. 

It should be nice to be abble to add Custom events to Xcontrol ...

 

I know that it is already possible ... but in a not user friendly way !

 

I would like to be abble to add a custom event like adding a new property or a new method.

And this "Xcontrol user event" could be seen automaticaly in the "Add new event" of an event structure, when an instance of this XControl has been drop on a front panel.

 

So what i would like is ...

 

  • Adding a custom event to a Xcontrol, as a property
  • That this Event appears automatically in the event structure configurator. (Like events of standards controls and indicators)

 

My need is to add custom event different from "Value changed", in order to build powerfull XControl. 

And be abble to use these events without having to regiter them manually. (But like standards controls and indicators)

 

When I want to select a given index of an Enum (Index, not String value) then it can be cumbersome.

I can make the digital display visible for the constant or control, but when the drop-down list appears.... yeah.

Enum drop-down.png

Can't we include the Index on the left side of the drop-down list (Spot my numbering error)?

Enum drop-down with index.png

It's not too hard here because they're sequentially ordered (more or less) but we have some enums with over 100 elements which are not so nicely ordered. Sometimes we just need to find out which element corresponds to a given index, or to select a given index directly. This is not so easy manually. I know we can enter the value for a constant in the DigitalDisplay area to select that element, but I still feel it would be nice to include the index when showing the selection list.

 

This is useful anywhere there is an Integer to Enum conversion (or the opposite).

I want to easily see what my Call Library Function Nodes are calling. How about a "Details" selection in addition to the Label? The Details will show the DLL and the Function Name.

 

19981i38EF0257C2D74016

Inspired by this idea... Changing the fill colour of thermometer according to the temperature

 

You want to customize the behavior of a LabVIEW control or indicator. The normal answer is to create an XControl. The problem is that you want to the XControl to have the same properties and methods as the base control. You have to recreate all the methods and properties yourself and then handle them all in your facade.

 

It would be nice to be able to create an XControl from a base control with all of it's properties and methods created for you. The you could then extend a base control instead of recreating one from scratch.

I would like to make a small workind change on another suggestion found HERE.

 

I would like to be able to declare LVOOP classes as ABSTRACT.

 

One example is a spectrometer class I have developed which provides much of the needed functionality but which is not designed to actually DO anything (Get name, Set Name, GET calibration coefficients, SET calibration Coefficients and so on).  At the moment I can instantiate an object of this class as with any "VALID" class which then just returns an error at run-time because the functionality is not complete.

 

By preventing users from (either willfully or accidentally) dropping what is essentially an abstract class onto the BD of a program we could prevent some awkward bugs.

 

Shane.

How about a "Restart LabVIEW" menu item?

Capture.PNG

 

When developing C# add-ons for LabVIEW I sometimes need to restart LabVIEW just to get the current loaded .NET assembly out of the LabVIEW AppDomain. It would be nice if there would be a "Restart LabVIEW" menu item so I don't have to exit and restart manually.

 

Cheers,

Christian

Currently the lvsound2 library -- the Sound Input and Sound Output VIs supported by lvsound2.llb and lvsound2.dll -- updates the audio device list from the operating system only when first being loaded into memory. If you change the device list (e.g.., pair/unpair a Bluetooth headset) the device IDs will not reflect the new configuration until all the lvsound2-dependent VIs have been unloaded from memory. After adding or removing a device, the VIs will generate error 4803 ("The sound driver or card does not support the desired operation.") for device IDs related to the new/removed device,  even if the ID is still actually valid and points to something else. This is extraordinarily inconvenient for test systems focused on audio device testing, but understandably a niche issue, which may be why it hasn't been caught before now.

 

In the interim, the workaround is to dynamically call any of the VIs you're interested in to force them to load/unload as necessary. There are two appropriate solutions I can think of:

 

1) Update the Sound X VIs to implement the dynamic call workaround (preferably directly around lvsound2.dll calls so we can still borrow other VIs in the LLB).

2) Update the DLL to support on-the-fly changes.

 

The latter solution is ideal, particularly for performance. This reads both as a suggestion and a bug report so that anyone else who has this problem can find a public forum documenting the issue.

Does this idea need any more explanation? If someone swipes the box out of a mail slot at work and installs it at home, that becomes the "at home" installation. 

 

I realize Ideas with pictures do better, so here's a Golden Retriever puppy...

 

 

Message Edited by Broken Arrow on 06-11-2010 07:40 AM

Can somebody explain to me why the Colour box control is on the Numeric Palette as a control but as a constant it's on the Dialog & User Interface Palette???

 

 

CB Control.PNG CB Constant.PNG

 

It doesn't matter HOW many times I look for the Colour box constant on the Numeric palette and then move to the Dialog & User Interface palette, I NEVER learn.

 

Please please move the constant to the Numeric palette where it belongs.

 

Shane.

 

 

Both the diagram disable structure and the conditional disable structure are intended to allow easy enabling or disabling of blocks of code. These nodes ought to have no effect on a diagram except to remove or add sections of diagram. But they currently have the side effect of formalizing the blocks of code they surround, as if they were a sequence structure. There are two cases where this is undesirable.

 

1. Without the disable structure, these two loops would run in parallel. 

 conddis_unwantedsync.png

2. This VI arguably ought to terminate because that wire dependency from the loop to the Stop primitive is only created because whatever is in the disabled frame needs the result of the loop, but the code in the enabled frame does not. But because the disable structure acts as part of the code, this loop runs forever.

 conddis_shouldterminate.png

To be able to use 3rd party version control tools such as Git effectively, you need to be able to have a program that merges files and can compare files. Unfortunately LVdiff and LVmerge are only available in the professional labview version, but being able to use a VC system of your choice is such a basic need that it should be available for everyone. That way  you would be able to use the basic VC features, better integration with labview could still be integrated in the professional package.

When creating a SubVI by selecting a piece of code from your block diagram, the "error out" indicator created is not the standard indicator with grey background as available in the controls palette.

On the contrary, it is similar to the standard "error in" control with white background controls.

To me it results  on a poor style and readability, and I use to replace it manually with the palette indicator.

 

I suggest using the default error indicator when creating a new subVI (and anywhere else if possible).Capture.PNG