LabVIEW Idea Exchange

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

Add field witch shows the size of the array.

 

new probe watch window

 

So simple but so helpful Smiley Happy

The function of "Compound Arithmetic" can be changed very quick and easy.

Why not use that concept for other items too?

 

Use cursor mode "Operate Value" to change function quickly.

Old: Click > Replace > Comparison Palette > Item

New: Click > Item

 

See concept screenshot for example:

Change Mode for all Items.png

 

The clicked item acts like an polymorph selector to choose from same palette or from similar items.

 

When you right-click on a String Constant or Path Constant and choose to Replace it with a Path Constant or String Constant (respectively), the value is lost.  Since strings and paths are somewhat interchangeable, it seems that the data should be preserved (coerced) during the Replace operation.

 

22030iFF96E5BF99C340BC

 

Note: It might be nice if there were a faster way to change a path to a string and vice versa, as suggested here.

Current behavior:

When saving a new .lvlib inside a .lvproj the save file dialog brings me to the last saved location which is often a different repo.

 

Desired behavior:

When saving a new .lvlib inside a .lvproj bring me to the root directory where the .lvproj is saved and not the last saved file location. i.e. implement the same behavior as when saving a VI inside a library or a class. This would solve the issue of VIs accidentally being miss-saved outside of the project folder and then getting lost.

Add functionality/property to allow a cluster to have a scroll bar.  This way, long clusters with many elements can be shrunk down to a manageable front panel size and a scroll bar would navigate through the cluster elements.

It would be nice, if the plot fill cold be set semi-transparent.

 

I have to plot minimum, maximum and average. It would give a better impression if the area between minimum and maximum is filled. Unfortunately the fill area hides the grid completely. It would enhance the plot if the fill was semi-transparent and the Grid would shine through.

 

I don't know how much effort it would take to implement a semi-transparent fill function in LV. If such a semi transparent fill function should be implemented could be implemented easily it should be done easily.

 

The picture shows a graph with   (A) normal fill,   (B) semi transparent fill (new idea)  , (C) no fill

wfg.png

 

Does anybody else miss such a semi-transparent fill option (B)?

When using LabVIEW in combination with other languages, it would be really nice for LabVIEW to be able to read from and write to the stdout and stderr streams. For example, when writing a dll in C that is to be used by LabVIEW, it would be really nice to be able to see the output and error streams from within LabVIEW. As it stands you have to jump through hoops in another IDE or create a log file or some other workaround if you want to see what might have happened inside the dll to cause it to crash.

The idea below demonstrates the ability to open a Typedef by right-clicking on a wire, but is also directly applicable to the ability of "Show Class Library" by right clicking on a class wire.

ShowClassLibraryFromWire

 

It's handy to be able to right click on a typedef constant, control, or terminal and have the "Open Type Def." option. However, oftentimes I only have a wire and not one of those three objects:

 

TypedefWire.png

 

In this case, the easiest way to access the typedef is by creating a constant or indicator, then using the context menu on your new "dummy". A big problem is that sometimes structures are exploded in the creation of the dummy.

 

        TypedefWire3.png

 

 

Instead of needing to create a dummy to access the typedef, I would like to be able to right click on the wire itself:

 

TypedefWire4.png

Instead of doing all this:

Captured1.png

I would like to be able to just drop a VI on the Start Asynchronous Call node, and get this:

Captured1.png

It would be helpful to have an array control property that fixed the number of elements in the array control to the specified size.  This would allow the developer to programmatically set the array control dimensions such that the user is unable to add new elements to the array.  This is specifically necessary when the number of elements in the array control may vary and may also be too large to display all of the elements.  If the scrollbar(s) are visible, then the user will always be able to add a new element add the bottom by editing the available empty element value.  This is undesireable if the developer wants to prevent the addition of new elements by the user.

   

Please see the discussion forum post below for the details of the issue and current workaround.

http://forums.ni.com/t5/LabVIEW/initialize-array-control-dimension/m-p/1221930#M520867

 

 

Thanks
Dan

I've already made a post on extending File I/O operations so I figured why not make a post on my most commonly used OpenG palette, the array palette.

 

There are so many good nuggets of Array manipulation code in OpenG.  This stuff isn't perfect, and could be optimized, but the convenience of it makes sense especially when you realize there is so many things you can do with arrays.  Lets start with the Index Array, one of the most commonly used functions.

 

index.png

 

Here we see the native function allows for an N dimensional array to be indexed.  The OpenG function only supports 1D and 2D arrays.  And when using a 2D array, the OpenG function must specify both a row and a column, you can't index an entire column or row.  Both of those are very useful features of the native index, but there is something the OpenG function does, that the native doesn't, and that is index multiple indices.  You can pass in an array of indices and pull them all out in the order defined.  This can be used as a reorder function that takes an array and scrambles it the way you like.  Adding this feature is already on the idea exchange.

 

Delete.png

 

Again when it comes to polymorphism the native function beats OpenG.  The native delete supports deleting from N dimensions where OpenG is just 1D or 2D.  But OpenG allows for deleting multiple indices from an array, and if it is a 2D array you can specify if you want to delete rows or columns.  This would be a nice addition to the native function.

 

cond index.png

 

A conditional auto index function doesn't exist natively in LabVIEW.  You can perform a similar function with the conditional auto index tunnel on a for loop but having a single function would be useful.  This idea is on the exchange in multiple places, Link 1, Link 2.

 

Remove filter.png

Ever need to remove duplicates from an array?  Or remove all zeros or NaNs from an array?  These two functions do just that and on the forums all the time are requests for functions like this with no direct replacement on the native palette.  A nice feature of the remove and filter are they output the indices that were removed.  Combined with the fact that the delete, and index accept multiple indices make these very useful.  Also the items to filter for the filter can be a scalar or array which is nice.

 

sort.png

Ever want to sort an array and know how it was sorted?  This OpenG function can do that along with specifying what order, ascending or descending to use.  The OpenG sort also supports 2D arrays where you can specify if you want to sort on rows, or on columns.

It would be nice to have the ability to use a Startup VI icon as the executable icon from the build specifications menu.

 

18641i46F31ADE0962A2F8

When wiring from inside a for loop to outside it, and the user lands the data on a singular data node (not an array or cluster), automatically set the tunnel mode to Last Value to prevent unnecessary code cleanup.

LabVIEW classes are how you create new data types in LabVIEW. But part of being a new LV data type is having a front panel representation. Although users can write XControls for displaying their classes, and they can put those XControls in the palettes, whenever a user of their class chooses "Create Control" or "Create Indicator" for the LabVIEW class terminal, they get the cube display. In order to really add a new data type to LabVIEW that behaves as well as, for example, the Timestampp or the Waveform, there needs to be some way to associate a class with an XControl and say, "This particular XControl should be used as this class' default control/indicator whenever one needs to be built."  (To prevent infinite recursion and load dependency problems, whenever you did Create Control/Indicator on a member VI of the class, users would still get the cube control/indicator.)

Estimate and show the Time Remaining during LabVIEW Installs, using selectable and realistic time units:

.

install.png

In LV 2011, an asynchronous Call By Reference feature was added to LV. This feature added two new nodes:

 

    • Start Asynchronous Call
    • Wait On Asynchronous Call

It would be nice if there was a way to use the LV event structure to wait for the results of an async call. For example:

EventStructureIntegration.png

 

I am not necessarily  proposing this is the way to integrate the ACBR with the event structure, it is just one suggestion. Instead, I hope this idea can gage the amount of interest in some sort of event structure integration. If anyone has any better ideas or suggestions, please say so in the comment.

I continually find myself fussing over the "configuration" of terminals. There are many permutations of icon/condensed view and label alignment, yet little consensus thus far for a standard.

 

My goal is to convince you this: Having different "flavors" of terminals does not make LabVIEW easier to understand or more "customized" to your preferences or learning style. Instead, it creates a source of confusion for new users to identify these Block Diagram components, and creates a hassle when it comes to formatting new or existing VIs to "your style". And no more label gymnastics trying to fit what should be a 22120iFF5D2D358A179035 into a 22124i47B01DC3554D8D28 or a 22122i534509B41D018E18.

 

Just a few Common Terminal Configurations:

22102iC18AB09CA35049A6

 

  1. Default Alignment - Not too bad, but not so great for stacking terminals vertically
  2. Block Diagram Cleanup Tool - Interesting choice of label alignment...
  3. CTRL+Space then CTRL+T - This is the "best" style, but it falls short in correctly aligning label in Icon View (arguably of inconsequence, since Icon View is not "best" style)
  4. The "Rogue Drag" alignment - Now where'd that label go?
  5. The "Monk" alignment - Everything has to be perfectly snapped to center
  6. The "There's a 'Size to Text'??" alignment - AKA - "This is what happens when I open your VI on my system" alignment
  7. The "Don't Stop - Believing - Hold on to that Feeeeling" label - I can't let go of LV 4.0 or Power Ballads
  8. The "But it takes up too much BD space - I'm'a remember what it's called" guy - or worse - "Neat, terminals can all have blank labels!!"
Oh yeah, and to add to the confusion of configuration permutations, we have some more ingredients:
22100i5704DD0516745EAB
 
Many Ideas - some very popular - have hinged around Terminal Configuration. Respectfully, I think they should all be supplanted by this Idea. The goal here is to eliminate even the need for a configuration:
  
  1. Default Option: Do NOT Place FP Terminal as Icon
  2. Separate label locations for Controls and Indicators
  3. Lable Position Options
  4. Add a setting to allow different label positions for controls and indicators
The prelim artwork is an attempt for an information-dense, easily-recognizable, same-footprint, attractive alternative to the current terminal configurations. It offers no display configuration, always showing the label for the sake of self-documentation. It was designed to complement the Improved Control References and the New LV2010 Local Variables. I would envision being able to double-click on the integrated label in order to rename the node.
 
22112i4F5D7F09801CC176
 
For completeness, here's what an array would look like. Or perhaps, one of the array alternatives on the Redesign Terminals Idea that focuses on the inability to clearly show array dimensions with the currently implemented terminal:
 
22114iE4253941BD5748E5
 
Finally, you're not voting for my artwork, you're voting for this concept: Standardize terminal configuration to make it non-configurable, robust against self-documentation SNAFUs, and universally recognizable. Just like the zero-config behavior of the Local Variable, we want a what-you-drop-is-what-you-get Terminal.

I am getting tired suggesting small ideas that could all be placed under one single umbrella:

 

Any right-click option should also be available from the properties dialog of the item!

 

Here are some recent example

 

 

 

But there are probably many more....

 

 

String functions accept array input.

 

Example:

StingFunctionWithArryInput.png

Benefits:

  1. Avoid placing For loop or Subvi with for loop
  2. Looping performance can be improved with better logic inside the function.
  3. Block diagram space saving without for loops

 

Thank you

Adarsh

CLA from 2014

When using extensive numbers of property and invoke nodes (for example, using the TestStand API) it's very common to end up with many references that need to be closed. This leads to structures like this:

 

closeref.PNG

 

It would be very convenient if we had a Compound Close References node that we could wire multiple references into. Since order often matters with closing references, the node could execute top-down once all references are available at the inputs. This would substantially clean up block diagrams and make API code a bit easier to follow. For example, the above code could just be replaced with:

 

compoundref.PNG