LabVIEW Idea Exchange

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

When we try to copy and paste a element in the cluster constant its not replacing its added as the new element.but it working well in the control and indicator

 

The figure explains the problem

Replace elements in cluster constant.png

(A while ago I suggested to post this idea, but it has not happened so I do it. :D)

 

The Akima Spline (For example explained here) seems to have some desirable features compared to all the interpolation and fitting algorithms available. It should be added to the LabVIEW functions, at least to interpolate 1D

Virtually ALL of my more complex typedefs have multiple datatypes wrapped in a cluster. The result? A pink wire. I have fat, pink wires all over my code.

 

Allow us to choose different patterns and colors for wires on a typedef. Increases the ability to spot a typedef, and allows for distinction between two complex datatypes.

 

(Note: I am not condoning making a new wire for every typedef... that would be a point of confusion when collaborating. I would just like to add distinction to some of my more distinct typedefs).

 

CustomWiresForTypedefs.png

 

 

As mentioned by Daklu over here, we have to change a VI to edit mode to be able to copy items from its front panel or block diagram - we don't actually want to edit it.

Currently, you are unable to highlight and copy text from the context help.  It would be nice to allow this functionality for LabVIEW users to be able to copy certain terms from the context help.

Hi,

So in VI Properties, you have the Window Appearence tab with "Same as VI name" tickbox.

Wouldn't it be great/better if this automatic name skipped the file extension?

 

Settings.vi -> Settings

OneButtonDialog.vi -> OneButtonDialog

and so on.

 

/Y

Element of Set? returns whether a single element is a member of a set. In order to check multiple elements, we currently have to place multiple nodes on the block diagram, which is rather redundant:

 

Current Situation.png

 

I would like to be able to connect multiple elements to a single node and check all elements at once:

 

Desired Behavior.png

 

As an example, I need to check if either of two elements is part of a set. If one of them is, add the other, otherwise do nothing:

 

Example.png

This is certainly not a deal breaker, but in my opinion it makes sense to allow multiple elements to be connected to this node, especially considering that it is read-only.

This has been brought up long ago, but I thing it deseves to be discussed here in the Idea exchange.

 

There are situations where it might be beneficial if we could have a string datatype that has a defined length. Arrays of such string would be stored flat in memory.

 

Application would include:

  • Typecasting a long string to a string array where the element is fixed length would slice up the string into an array of equal length strings.
  • Reading a binary file as an array of fixed strings would do the same.
  • ...

 

The default value would be a string of the defined lenght filled with \00. Shorter inputs would get padded with \00

Of course certain operations would drop the length, e.g. when concatenating such strings, the length would get dropped from the result, turning it into a plain string.

I have just noticed a difference of 2 pixels in the width of the input fields of the Label and Caption.

 

Spoiler
Although they don't look like, in below example, the label and caption are the same.

 

Label_Caption Width.jpg

Currently, if you create an indicator from the loop iteration terminal of a for or while loop, the indicator is by default called "Numeric."  However with every other control or indicator in LabVIEW, the default name of the control or indicator is called by whatever it was spawned from.  (For example, when you create a control from the stop terminal, the control is called "stop").  I believe the loop iteration indicator should follow in this pattern.

Probes are useful for seeing when a piece of code has executed for the first time after clicking 'run' as well as to see real-time values on wires.

 

Currently probes retain their values when the top VI stops, which is useful, but less usefully, keep their values indefinitely, even when the VI is restarted.

 

I'd like them to reset to 'Not Executed' when you click 'Run' again, otherwise I have to delete and recreate each probe in order so that I can tell when they have executed for the first time (unlike the lightbulb which slows everything down, breakpoints which pause the code or adding indicators which may not be convenient on a front panel (and require initialisation code)).

 

If this could be implemented (or could be an option for all probes or for any individually by right-clicking on them) I would find it really useful!

 

 

 

Another request from my carpal tunnels here.  When you Right-Click and Create Indicator, you get the indicator wired to the terminal you selected.  When I right-click a reference and Create Property For... or Create Method For... I would like to get the PN/IN wired to the reference.  Right now it gets placed on the cursor when you select the property or method, and if you are unlucky, that can be a considerable distance from the terminal.  Now you have to drag it back into position, hope for autowiring to catch, or wire it up yourself.  I would much rather have it placed and wired automatically.

 

CreatePropertyForFromReference.PNG

The pane properties dialog is rather limited:

24116i402FDA4F25C800F2

 

It only shows 4 options:

-Label

-Label Visibility

-Background

-Background alignment

 

It could also show the following dialog:

So it adds the following properties:

-Origin

-Scroll bar visibility

-Minimum pane size

 

Currently you have to create some special code to set these options.

 

Ton

 

By default, when you build an application, the front panels of all VIs are removed.

 

Of course, this would make applications completely unusable, so there are certain changes which cause LV to keep the front panel in, such as setting the front panel to open when the VI is called. This gives LV a clear indication you want the front panel and these changes are generally enough for most of the VIs which people use.

 

There are, however, times when you want a VI to keep the panel, but it's a VI which usually (or sometimes even never) won't be displayed. Today there are several ways to handle this case.

 

 

The official way is too flimsy:

 

Keep_FP_AB.png

 

 

It's limited to specific build specs and it's too easy to break (e.g. remove the VI from the project and add it back).

 

 

 

 

The automatic way relies on additional changes you're likely to make if you intend to show the VI, but is also too easy to break:

 

Keep_FP_Property.png

 

Someone could just unset the property and then it's gone.

 

 

 

 

What I usually today is something like this:

 

Keep_FP.png

 

The static property node ensures the FP will remain and the comment makes it less likely that someone will remove it.

 

 

 

 

What I want to see, however, is something more explicit, possibly in the shape of a new VI property:

 

Keep_FP_New_Property.png

I'd love to see an option for the label of structures to be visible by default, similar to the already existing "Subdiagram labels visible by default" option.

 

structure labels visible by default.png

When you move files around in the directroy structure (not renamed), you get prompted with this Resolve Load Conflicts message box.

For every VI file used something that has moved you must choose if you want to:

 

a) load with the file found in the new location.

b) load the file that can no longer be found.

 

I proposed having a way to automatically load the newly located file with the alternative cannot be found

OR

having a "Resolve All Conflicts" button for this case.

 

 ResolveConflicts.jpg

 

ResolveConflicts2.jpg

 

 

It could be useful to have the possibility to set the Runtime Menu of a control by specify the .rtm file

 

RuntimeMenuPathForControlClass.png

Dany

We currently have an API to edit it

 

MenuAPI.png  

 

What I propose is to extend it with a couple of new function:

 

Open/Create Menu File : Open/Create Menu File return reference to the menu.

Open_Create_Menu.png

 

Write Menu File: From a reference save the file to disk

WriteMenu.png

 

Close Menu File: Close the reference to the menu file

CloseMenu.png 

 

Dany

untitled.PNG

 

OK, so what happens to the index displays if you click the top buttons, the ones with the arrows pointing up?

Spoiler
the Ring and enum indicies DECREMENT

 

I would propose to make the behavior consitant so that UP increments and DOWN decrements

I would like to propose the use of a stacked parallel execution structure.  Especially in FPGA applications, this will solve the problem of diagrams running off the screen.  All execution pages will run simultaneously as if independent while loops were scattered across the BD.  This idea potentially leads into a 3 dimensional visuallization of coding LabVIEW. Note: In the image, the pages are offset but should look similar to a stacked sequence structure.

 

 

Parallel Execution Structure 3.JPG