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

Conditional Disable LabVIEW Run-Time Versions

Status: New
by Trusted Enthusiast ‎03-27-2014 11:58 AM - edited ‎03-27-2014 12:08 PM

Right now we can make a conditional disable structure that behaves one way if we the VI is running in the Run-Time engine or not.  What I think would be useful is if we could also decide on performing one case or another based on the version of the Run-Time/Development of LabVIEW.

 

Say I develop some neat little reuse VI that relies on getting the name of the label of data type passed in.  OpenG has a functional already that does this called Get Data Name.  NI has a version as well in vi.lib called GetTypeInfo.vi.  The problem is in 2011 the OpenG method is about 10 times faster, but in the 2013 version the NI version is 10 times faster.

 

Wouldn't it be nice if a conditional disable structure could choose to do one thing over another, based on the version of LabVIEW it was being run in?  This way reuse code could be written to perform best in what ever version it was running in.

 

There are many situations were one code written using some function either runs slower or faster in different versions of LabVIEW and using this we could choose the best option for that environment.

 

Of course there is a work around and that is to read the App.VersionYear property, put that into a case statement and perform different code for one version or another but this has added over head, and is called every time it is needed.

 

EDIT: Also the App.VersionYear can't be used in inlined VIs because it is a property node which a conditional disable can be used.

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?

Custom automatic error handling callback

Status: New
by Member JeffreyH 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

Cleanup Diagram with option for symmetric terminals

Status: New
by Active Participant sth on ‎07-04-2014 03:06 PM

Diagram cleanup has become my friend lately.  It doesn't do a great job but it is adequate to make th code readable and moving each terminal to remove as many kinks as possible just gets too time consuming.

 

However, I do a diagram clenup, look at the results and then go around option-clicking to swap terminals on symmetric inputs and then cleanup again.  The diagram cleanup code should consider this option and optimize the terminal inputs.

 

By symmetric terminals I mean the whole host of primitives where the input order does not matter, addition, multiplication, Max/Min, Equals?, Not Equal?.  This would remove a whole bunch of wire crossings that are very annoying and make code hard to read.  Even "Bundle by name" would be amenable to this cleanup optimization.

 

If you really want a challenge, this could also be applied to the Compound arithmetic node but the "negate this input" would move as the input is reassigned.

 

(If this has been impelemented post LV 12, "never mind" as Emily Litella used to say)

Display the path of the missing VI

Status: Completed
by Trusted Enthusiast on ‎07-03-2013 07:33 AM

After 2011 we have the option to ignore all the missing vi's which are missing. But after loading the project if a vi is loaded and if it has a missing vi then there is no way to check from where it has to be loaded (Expected path of the missing vi). So it would be a good option to check the Expected path of the missing vi after loading its caller (May be in the properties of the missing vi).

Status: Completed

Implemented in LabVIEW 2014

Enhance Loop Conditional Terminal

Status: New
by Member okubik on ‎11-13-2013 11:08 AM

Hi,

I want to start discussion about how to enhance Loop Conditional Terminals in LabVIEW. Generally my idea is to have an easy way how to monitor Conditional Terminal of user-defined "primary" loop. Under the hood there can be for instance notification triggered from the "primary" loop and one or more "slave" loop(s) equipped with "Wait for notification" (with timeout = 0) with predefined logical operation on the terminal input.
So this allows you to have one STOP source loop and one or more listeners.

 

sopping loops.png


Anyone wants to expand this idea?

Variable Speed highlight execute

Status: New
by 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.

Let's get rid of the For-loop, the While-loop, and the Timed loop

Status: New
by Active Participant SteenSchmidt ‎03-08-2013 06:17 PM - edited ‎03-08-2013 06:20 PM

Hello (again),

 

Well, this idea has haunted me for a couple of years, and now I think it's time to break it. I feel the For-loop, the While-loop, and the Timed loop are so similar that they are begging for a merger. It would simplify, and with a little thought strengthen, the API, to have a single configurable Loop Structure instead. What's the difference between a While-loop and a For-loop with a conditional terminal anyway? Have you ever wished for iteration timing information being available inside your For-loop (I know I have)? "Oh but those structures have been around forever, we can't touch those"... Well, what happened with the stacked sequence structure? Please read on for a minute or two and tell me if I'm losing my marbles here. And please chip in with your own modifiers, since LabVIEW is growing in (sometimes unnecessary) complexity. Thus:

 

CrossedOutLoops.png

 

Instead I propose the Loop Structure which when initially drawn looks like this:

 

NewLoop_Infinite.png

 

The above is basically a loop running forever (don't worry, you can stop it), but it can be modified to do many many other things, just be patient :smileyhappy:. One feature of the loop structure is the box in the upper left corner, which is quite similar to what we have in a For-loop today. This will, no matter the configuration of the loop structure, always show the current iteration setting of the structure. By default that is never-ending, but if you drag in a conditinal terminal you change the loop behavior to a While-loop (note that I suggest a simpler way to get to the terminal than via the right-click context menu):

 

NewLoop_While.png

 

Arrays can be wired to the structure border as usual to give a For-loop like behavior. The count terminal changes from "Inf" to an "N" to indicate that it's a finite albeit at edit-time unknown number of iterations:

 

NewLoop_Unknown.png

 

You can wire out of the count terminal inside the loop structure as usual to get the count at run-time of course. If the iteration count can be deducted at edit-time a number will appear instead of the "N":

 

NewLoop_42.png

 

This number is blue to indicate that it is automatically calculated. You can just type in a new number if you wish to run a different number of iterations, in which case all the usual ideas on this Idea Exchange about what should happen to auto-indexed tunnels apply. If you override the count manually the number will be in black text:

 

NewLoop_50.png

 

You can of course combine different exit conditions, in this case a fixed number of iterations with a conditional terminal wired as well for possible early exit:

 

NewLoop_42_Conditional.png

 

The automatically calculated count terminal aids in determining if the loop actually runs the desired number of times:

 

NewLoop_MultipleArrays.png

 

All the usual stuff about tunnels, shift registers and so on apply to this structure as well, but on top of that it can also be configured as you're only used to within a timed loop. Consider how valuable some of these parameters and settings could be for ordinary loops, for error handling and for timing for instance. But the main feat is that this is still the same loop structure - it will simplify the palette a lot:

 

NewLoop_Timed.png

 

And now an additional feature that ties some of the parameters from the timed structure together with ordinary loops: this loop structure is event-enabled! I propose stuff like this (we're only scratching the surface with this image):

 

NewLoop_Events.png

 

It's late where I am now, so I'll stop now, but all of the above makes it extremely easy to do things you simply can't do today - what about a Priority Structure?:

 

NewLoop_PriorityStructure.png

 

So, is it time to consolidate the ever-evolving loop code of LabVIEW into one structure to rule them all? :smileyvery-happy:

 

Cheers,

Steen

Rotate String

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

 

                     this time, I hope this idea was not already proposed! :smileyfrustrated:

 

 

original6.png

 


"Almost Equal" functions for Float comparisons

Status: New
by 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 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

After fighting an increasingly slow IDE for a while I found the reason editing my libraries and classes was slow: Lengthy and large mutation history.  I'd like to see an easy option to clear that history so I'm not burdened with the edit-time slowness when I don't have to be:

DelMut.png

If I was smart with right-click-frameworky stuff I guess I could make it work myself, but for any so inclined:

DelMutCode.png

Sizable Element Gap in Arrays

Status: New
by Active Participant Broken_Arrow 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

Currently, the only native way to display a JPEG in memory on a 2D picture control in LabVIEW is to

  1. save to disk
  2. read from disk
  3. display

See: 

Screen Shot 2014-02-18 at 11.09.39 AM.png

This is not only silly, but slow: on a reasonable fast machine with an SSD, this takes almost a second!

A simple request: A VI that can go straight from JPEG binary data (other formats would be nice) to a 2D picture control. This is very useful for applications that download images from a server - a pretty common thing to do.

An altermative to the "Format into string" tool.

Status: New
by Member oyester on ‎03-05-2012 05:16 PM

Format into text is very useful but can become hard to edit when it has a lot of inputs. I propose, instead of one huge format string, that the programmer be allowed to put the required format next to the corresponding input. Also, the user should be allowed to enter constant strings, e.g.. \n, \t, or "Comment", and have the corresponding input field automatically grayed out.

 

FORMAT INTO TEXT IDEA

timeout control with occurrences

Status: New
by Trusted Enthusiast on ‎01-24-2013 03:31 AM

How about having a timeout occurrence as an input for functions which support timeouts?

 

I am illustrating a single use case with queues (and a notifier) but I would see this as being beneficial to nearly ALL functions with timeout inputs.

 

Sometimes we'd like to wait for one of a few different functions (an example of mine which springs to mind is the Dequeue primitive).  At the moment we must essentially poll each primitive with a relatively short timeout, see if one responded and then handle accordingly.  This is (for me at least) ugly to look at and introduces polling which I generally don't like.  I'm an events man.

 

Occurrence timeout.png

 

What I propose would be that instead of simply defining a timeout in milliseconds we can define both a timeout (in milliseconds AND an occurrence for the timeout).  If we wire this data to several primitives (all sharing the same occurrence) the first primitive to receive data triggers the occurrence so that the others waiting in parallel return also.

 

In the case where no data arrives, each function waits the defined amount of time but upon timeout DOES NOT fire the occurrence.  This would cover corner cases where you may want different parallel processes to have different timeouts (Yes there are cases although they may be rare).  It is possible to change the "priorities" of the incoming queues in thie way.

 

Background info: One example where I could use this is for RT communication.  Here we multiplex many different commands over TCP or UDP.  On the API side it would be beneficial to be able to work with several strictly-typed queues to inject data into this communication pipe while still maintining maximum throughput.  I don't like using variants or flattened strings to achieve this multiplexing.

 

Being forced to poll means the code must decide between efficiency (low CPU usage) OR response time (setting a very low timeout).  Although the CPU load for polling may be low, it's not something I personally like implementing and I think it's generally to be avoided.

 

There IS a LVOOP solution to this particular problem but not everyone can use LVOOP in their projects (for various reasons).  I can envisage other use cases where interrupting a timeout would be desireable (Event structure, wait on ms, VISA read and so on and so forth).

 

Shane.

Change CLUSTER SIZE to a Wired Input

Status: New
by Active Participant Broken_Arrow 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

Array to Spreadsheet String - Corrections required

Status: New
by Trusted Enthusiast ‎01-11-2013 07:54 AM - edited ‎01-11-2013 07:56 AM

I am extensively using the Array to Spreadsheet string Primitive and most of the time I never used the Format string input (Use to wire an empty string constant) and still I am getting the right result what I expect. So I think it would be better if the Required Terminal is changed to an Optional Terminal.

 

It is known that the Array to Spreadsheet string is Polymorphic, but when we wire an array of I32 and DBL the output string is DBL format only. It would be good if the output String adapts the data type that is wired unless otherwise specified by the Format string.

 

Changes needed for Array to Spreadsheet String.png

Open VI reference without refees

Status: New
by Active Participant SteenSchmidt on ‎02-26-2013 04:10 PM - last edited on ‎02-28-2013 08:43 AM by Member MaryH

Hi,

 

I suggest an option added to the Open VI Reference primitive to open that VI reference without any refees. I suggest option bit 10, i.e. option 0x200h:

 

OpenWithNoRefees.png

 

The demand for this arises when you want to access methods and properties of VIs that may be broken, while on the other hand you don't have any need to run those VIs - for instance in one of my current tools (BatchEditor) where I'm tasked with investigating hundreds of VIs simultaneously of which some could be broken or missing dependencies. Other situations would be tools for traversing project trees for instance. Opening a large number of healthy VI references takes a while, and when something is broken in a VI, opening even a single reference could take 30 seconds to minutes.

 

Currently you can suppress the "loading" and "searching" dialogs by setting option 0x20h on the Open VI Reference primitive, but that only loads the refnum silently as far as that will get you. Opening the refnum takes the same amount of time as if you could see those dialogs, and you are rewarded with an explorer window if a dependency search fails. I just want a way to open a VI refnum without even starting to look for dependencies, thus very quickly and guaranteed silently.

 

The relevant people would know that this request isn't that hard to implement, as it is kind of already possibly using some ninja tricks. I'd like such an option to be public.

 

Cheers,

Steen

LabVIEW should break VIs which have hidden code

Status: New
by Knight of NI on ‎11-21-2012 08:43 AM

There is something wrong with this VI, although you wouldn't know it unless you ran it (and I should warn you that it will annoy you if you run it):

 

AnnoyingVI.png

 

 

What's wrong with it is that auto grow has been disabled and there's some annoying code hidden there beyond the loop boundary. This is one of my least favorite things about LV - it allows us to hide code completely and get away with it. I don't think it should.

 

LV already has auto grow enabled by default to handle some of the cases which cause this issue, but I know that many many people don't like it when LV automatically plays with their BD layout (and rightly so) and auto grow only covers some of the cases, so I think we need something more encompassing and less obtrusive, and I would suggest breaking the VI if it has hidden code.

 

I also know that LV has warnings and VI Analyzer has tests for this, but I think this needs to be something which doesn't let you get away with it.

 

I think LV should break any VI which has any of the following:

 

  • Objects beyond the visible boundaries of structures (including wires and constants).
  • Objects behind other objects (possibly not including wires).
  • Overlapping tunnels on structures (or maybe just not allow them to overlap at all)?
  • Anything else?
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