NI Home > Community > NI Discussion Forums

LabVIEW Idea Exchange

Showing results for 
Search instead for 
Do you mean 
Announcements
We've turned on a search before post feature in the LabVIEW Idea Exchange. This new feature will help cut down on the number of duplicate ideas in this space!

The NI Idea Exchange is a product feedback forum where NI R&D and users work together to submit ideas, collaborate on their development, and vote for the ones they like best. View all of the NI Idea Exchanges to post an idea or add your opinion on an existing one today!
New Idea

Add "index past replacement" output(s) to "replace array subset".

Status: New
by Knight of NI Knight of NI ‎10-21-2013 03:17 PM - edited ‎10-21-2013 03:18 PM

After applying my own subjective intellisense (see also Smiley Wink), I noticed that "replace array subset" is almost invariably followed by a calculation of the "index past replacement". Most of the time this index is kept in a shift register for efficient in-place algorithm implementations (see example at the bottom of the picture copied from here).

 

I suggest new additional output terminals for "replace array subset". The new output should be aligned with the corresponding index input and outputs the "index past replacement" value. This would eliminate the need for external calculation of this typically needed value and would also eliminate the need for "wire tunneling" as in the example in the bottom right. (sure we can wire around as in the top right examples, but this is one of the cases where I always hide the wire to keep things aligned with the shift register).

 

If course the idea needs to be extended for multidimensional arrays. I am sure if can be all made consistent and intuitive. There should be no performance impact, because the compiler can remove the extra code if the new output is not wired.

 

Several String functions have an "offset past ..." output (e.g. "search and replace string", "match pattern", etc.) and I suggest to re-use the same glyph on the icon.

 

Here is how it could look like (left) after implementing the idea. equivalent legacy code is shown on the right.

 

 

 

Idea Summary: "Replace array subset" should have new outputs, one for each index input, that provides the "index past replacement" position.

 

 

 

 

Problem

When creating an installer for my built LabVIEW application, I really dislike having to choose between including the RTE installer (and having a 100+ MB installer for my application) or not including it (and requiring my users to download and install the RTE as a separate step).  Typically, I'll build two installers at the same time (with roughly duplicate build settings): a full installer w/ RTE and a light installer w/out the RTE.

 

Proposed Solution

What would be much nicer would be if my app's installer were able to download and install the RTE, if necesary.  Actually, this is common practice, these days, for users to download a small installer that then downloads larger installer files behind the scenes.

Conditional auto-indexing

Status: Completed
by Trusted Enthusiast on ‎06-02-2009 03:12 PM

Auto-indexing of arrays in for and while loops are a nice luxury in LabView.  One option that could save much time would be a menu option to turn on conditional indexing, this would expose a boolean terminal under the auto-index icon to select if the current itteration should add the itteration to the array or skip it.  From an execution standpoint there would only be a minor performance hit (could still preallocate max array size on for loops and automatically return used subset).  This could also work for autoindexed in but would have less use that the autoindeded out case.  I know I have built many conditional arrays inside of a for loop and it requires a case selection and a build array making the code less readable and requires time and thought.  It can also be less efficient than a compiler can do.

 

See the example below which would run a for loop and only build array of < 0.1

 

Conditional autoindex.jpg

Status: Completed
Available in LabVIEW 2012

Make Type Def. should launch the new type def.

Status: New
by Member CGMENG on ‎11-07-2013 06:54 PM

The shortcut menu should launch the new type def.'s front panel when 'Make Type Def.' is selected. You will need to save it anyway, and if you find the need to edit it right away, then it is already open and ready to go.

 

make type def.jpg

New 1D data container: Circular Buffer

Status: New
by Trusted Enthusiast Trusted Enthusiast on ‎01-02-2013 03:12 PM

There is a construct I am quite fond of in pointer-friendly languages, using iterator math to implement circular buffers of arbitrary data types.  They are a little bit slower to use than straight arrays, but they provide a nice syntax for fixed sized buffers and are helpful in cases where you will be prepending and appending elements.

 

I am pretty certain that queues are implemented as circular buffers under the hood, so much of the infrastructure is already in place, this is mostly adding a new API.  Added bonus:  the explicit circular buffer can be synchronous, unlike the queue, so for example you can put them in subroutine VIs.

 

It should be easy to convert 1D arrays to/from circular buffers.  Array->CB is basically free, the elements are in order in memory.  CB->Array requires two block copies (most of the time).  This can be strategically mananged, much like Reverse or Transpose operations.

 

Use cases:

 

You can implement most of  the following two ideas naturally:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Looping-Input-Tunnels/idi-p/2020406

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/New-modes-on-auto-indexed-input-array-tunnels-in-loops...

 

Circular buffers would auto-index and cycle the elements and not participate in setting 'N'.

 

You can do 95+% of what I wanted to do with negative indexing:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Negative-Values-in-Index-Array-or-Array-Subset/idi-p/9...

 

A lot of the classic divide and conquer algorithms become tractable in LV.  You can already use queues to implement your own stack and outperform native recursion.  A CB implementation of the stack would be amenable to subroutine priority and give a nice performance kick.  I have done it by hand for a few datatypes and the beauty and simplicity of  the recursive solution gets buried in the implementation of the stack.  A drop-in node or two would give you a cleaner look and high-octane performance.

 

Finally, perhaps the most practical reason yet:  simple XY Charts.

 

As for appearance I'd suggest a modified wire like the matrix data type.  Most if not all Array primitives should probably accept the CB.  A few new nodes are needed to get/set buffer size and number of elements and to do the conversions to/from 1D arrays. The control/indicator could have some superpowers:  set the first element, wraparound scrolling (the first element should be highlighted).

Pause on first Error - option for debugging.

Status: New
by Member AnishPrabuT on ‎10-25-2011 07:51 AM

It would help a lot if we have an option called pause on first Error. So that the VI at the node/primitive that generates the error and highlights that node so that user decides to continue or abort.

Variable Speed highlight execute

Status: New
by Trusted Enthusiast Trusted Enthusiast on ‎06-04-2009 05:38 PM
Title says it all. Have a slider or pull-down that increases or decreases the highlight execute rate.

In Place Auto Indexing

Status: New
by Member PCorcs_DMC on ‎08-06-2014 01:39 PM

Hello LabVIEW Users,

 

While working with a complex configuration application, I found myself heavily utilizing in place operations. Throughout the process of contstructing the code, I found myself commonly having to create an In Place Indexing structure (pictured below). I thought it would be really nice if you could mark an auto-indexed array for in place operation. As always, I am open to suggestions, but thought this might be a nice creature feature:

 

Capture.png

 

Cheers, and happy coding. 

LabVIEW for BeagleBoard

Status: New
by Active Participant vitoi on ‎07-17-2012 03:01 AM

 

 

 

The BeagleBoard xM is a 32 bit ARM based microcontroller board that is very popular. It would be great if we could programme it in LabVIEW. This product could leverage off the already available LabVIEW Embedded for ARM and the LabVIEW Microcontroller SDK (or other methods of getting LabVIEW to run on it).

 

The BeagleBoard xM is $149 and is open hardware. The BeagleBoard xM uses an ARM Cortex A8 running at 1,000 MHz resulting in 2,000 MIPS of performance. By way of comparison, the current LabVIEW Embedded for ARM Tier 1 (out-of-the-box experience) boards have only 60 MIPS of processing power. So, about 33 times the processing power!

 

Wouldn’t it be great to programme the BeagleBoard xM in LabVIEW?

"Almost Equal" functions for Float comparisons

Status: New
by Trusted Enthusiast Trusted Enthusiast on ‎02-09-2011 01:51 PM

It is time to put a dent in the floating point "problems" encountered by many in LV.  Due to the (not so?) well-known limitations of floating point representations, comparisons can often lead to surprising results.  I propose a new configuration for the comparison functions when floats are involved, call it "Compare Floats" or otherwise.  When selected, I suggest that Equals? becomes "Almost Equal?" and the icon changes to the approximately equal sign.  EqualToZero could be AlmostEqualToZero, again with appropriate icon changes.  GreaterThanorAlmostEqual, etc.

 

AlmostEqual.png

 

 

I do not think these need to be new functions on the palette, just a configuration option (Comparison Mode).  They should expose a couple of terminals for options so we can control what close means (# of sig figs, # digits, absolute difference, etc.) with reasonable defaults so most cases we do not have to worry about it.  We get all of the ease and polymorphism that comes with the built-in functions.

 

There are many ways to do this, I won't be so bold as to specify which way to go.  I am confident that any reasonable method would be a vast improvement over the current method which is hope that you are never bitten by Equals?.

Allow References to be Wired into Case Selectors to Check for Validity

Status: Declined
by Trusted Enthusiast Trusted Enthusiast on ‎11-14-2009 06:12 PM - last edited on ‎04-13-2011 03:03 PM by Active Participant Laura F.

I propose that Case Selectors should accept any type of reference, and the two cases generated are "Valid Ref" and "Invalid Ref". (This would be very similar to the current behavior of the Case Selector accepting errors with the two cases of "Error" and "No Error".)

 

The current behavior using "Not a Number/Path/Refnum" is very unintuitive. It requires the programmer to use Not Logic (i.e., do something if the reference is "not not valid").

 

ReferencesIntoCaseSelectors.png

 

 

Status: Declined

Event Structure (event data node)

Status: Duplicate
by Trusted Enthusiast on ‎04-22-2015 04:48 AM

  

                                The event data node does not retrurn "all elements"

 

             it would be nice and useful if "all elements" would be also available

 

 

2015-04-22_010606.png

 

 

                                                                                        like this;

 

 

result.png

The Report Generation Toolkit provides functions to set various Format aspects of Excel "areas", and Excel Graphs, but doesn't provide the complementary "Get" functions to return the current values.  For example, I wrote a LabVIEW function that will set the Font Color of a row of a WorkSheet to Red (using Excel Set Cell Font), but if I want to find the row with the Red font, there is no "Excel Get Cell Font" that can return the property to me.  Of course, I could cobble something together using ActiveX calls, perhaps, but these are poorly documented, and since NI is already doing the "heavy lifting" to provide the Set functions, it would seem "relatively simple" for them to also add the corresponding Get functions, as well.

 

Bob Schor  (using Excel as a "controller" for some experiments controlled by a LabVIEW Real-Time system)

Custom automatic error handling callback

Status: New
by Member JeffreyH Member on ‎04-21-2013 05:05 PM

I often have code in my apps where some error-out nodes are not wired, simply because the errors are generally not of interest to me or the error wiring would clutter up my block diagram. Typically this happens a lot in UI handling code where a lot of property nodes are used. For these parts I would rely on the automatic error handling for debugging purposes. One of the drawbacks of this method is that program execution is suspended when the automatic error handler kicks in. Even worse if this happens for code that is in a loop. You're only option then would be to abort the app, which e.g. is no good for your reference-based objects, etc.

 

I would love to have the ability to just specify my own 'Automatic Error Handler', enabling me to decide what to do with the unhandled errors. Just logging them is what first comes to mind, but maybe also do some special stuff depending on the type of error, just like a 'normal' error handler. I want to be in control!

 

Added values of this is that your application then has a catch-all error handler which enables you to at least log every error that occurs, even if not wired through. (Everyone forgets to wire some error-out that they actually did want to wire one time or another don't they? ;-))

 

Ofcourse the proposed setting in the image would ideally also be available programmatically by application property nodes.

 

21-4-2013 22-55-19.png

Sizable Element Gap in Arrays

Status: New
by Active Participant Broken_Arrow Active Participant on ‎10-28-2010 11:42 AM

I think the Array Element Gap should be sizable. This would facilitate lining up FP arrays with other items on the FP, or simply as a mechanism to add more apparent delineation between elements.

The size should be set in the Properties box, not by dragging the element gap with the mouse - that would add too much "cursor noise".

A new Property Node for this feature would complete Idea.

 

GapSize.png

The polymorphic "Continuous Random.vi" function

 

Screen Shot 2015-05-28 at 15.24.14.png

 

is a polymorphic VI with 18 instances.

The Help is at best sketchy as far as describing what the input parameters are, and to aggravate things, there seems to be no logic in the name given the inputs of the different instances of the function.

 

The Exponential distribution instance has for example two parameters, a and b:

 

Screen Shot 2015-05-28 at 15.28.00.png

 

Illuminating contextual Help if there was any, but the detailed help is about as useful:

 

Screen Shot 2015-05-28 at 15.29.34.png

 

Translation: the PDF of the variate is p(X) = 1/b * exp(-(X-a)/b), X > a; 0 otherwise.

I will not comment on the surrealistic definition of a Poisson process. 

 

I am not sure why the need to include parameter a, but I am sure that setting the default value of that parameter to 1 is non standard.

I suggest setting it to zero, disregarding any back-compatibility argument, as I suspect most users of the function have learned the hard way to set a = 0 after having stared incredulously at the first few results obtained using the default value.

 

Rotate String

Status: New
by Trusted Enthusiast on ‎03-19-2012 06:45 PM

 

                     this time, I hope this idea was not already proposed! Smiley Frustrated

 

 

original6.png

 


The Path Type function return a I16 and not a U16. 

This function should provide a U16 to compare with an Enum type without conversion (or why not an U8).

Now there is two type-conversion for just discuss one case :

conversion.PNG

Cdt.

 

I've encountered a programming situation where I may need to call 'Match Regular Expression' where the regex is selected at runtime, and where that regex may potentially have a variable number of submatches to return.  Unfortunately, right now, the submatch count is a compile-time decision based on how far out I grow the node.  I can grow the node to some maximum number of submatches ever expected, and thankfully the node doesn't throw a runtime error if there are fewer, or greater, submatch expressions in the regex.  I'm building the individual returns into a string array for further processing, but it would be much more versatile if the node could return the submatches with a properly-sized string array.

Change CLUSTER SIZE to a Wired Input

Status: New
by Active Participant Broken_Arrow Active Participant on ‎09-25-2009 11:07 AM

Cluster Size as a Wired Input:

 

  • Easier to see
  • More implicit
  • Nearly impossible to forget to set it (if it were a required input).

 Cluster Size.gif

Latest LabVIEW Idea Exchange Blog Posts
About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Top Kudoed Authors
Idea Statuses