From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

Home Community Idea Exchange LabVIEW Ideas

LabVIEW Idea Exchange

Community Browser
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
Post an idea
769 Kudos
JackDunaway

Allow a quick "Timing Probe" for Timing Metrics

Status: Declined Submitted by Trusted Enthusiast on 06-15-2009 07:00 PM 29 Comment

Typical question in development process: "How quickly does my code execute? What runs faster... Code A or Code B?" So, if you're like me, you throw in a quick sequence that looks like this:

 

TimingDuringDevelopment.png

 

AHHH! What a mess! It's so hard to fit it in, with FP real estate so packed these days!

 

We need this:

ProposedTimingDuringDevelopment.png

 Just like my other idea, and for simplicity's sake NI, I would be PERFECTLY happy even if you had to set up the probes during edit mode, and were not able to "probe" while running.

 

 As a bonus, this idea may be extrapolated into n timing probes, where you can find delta t between any two of the probes.

View All (7)
9 Kudos
Mathilde38

LabVIEW crashes when calling network functions under Linux

Status: Declined Submitted by Member on 04-28-2023 08:15 AM 5 Comment

LabVIEW crashes randomly when network functions are used on Linux. This problem appears especially when many connections or files are open.

R&D has identified the issue but is evaluating wheter or not the issue will be resolved in future releases.

 

All the details are here : 

https://forums.ni.com/t5/LabVIEW/TCP-Allow-files-descriptors-gt-1024/m-p/4297433#M1255356

 

An example is attached.

 

 

 

 

Download All
View All (5)
276 Kudos
Jim_Kring

Build Application Installer should download and install Run-Time Engine if necesary

Status: Declined Submitted by Trusted Enthusiast Trusted Enthusiast on 12-10-2009 08:08 PM 19 Comment

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.

View All (8)
196 Kudos
JackDunaway

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

Status: Declined Submitted by Trusted Enthusiast on 11-14-2009 06:12 PM 17 Comment

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

 

 

View All (7)
73 Kudos
JÞB

Promote Functions on Timing palatte

Status: Declined Submitted by Knight of NI on 08-16-2011 03:50 PM 15 Comment

The Timing palatte is looking bad with all thes gaps.  A simple fix would be to fill these holes with useful functions. I'm proposing 3 and attaching 2 from my re-use code. (I may re-create the third later)

timing2.PNG

 

Time to XL.vi (Attached): and its inverse, XL to Time.vi

12:00:00.0 AM Jan 0, 1900 is a pretty common epoch (Base Date) for external programs and converting from LabVIEW epoch shows up several times a year on the forums. and Time to excel has a few solutions to threads under its belt.   Moreover for analisys against external data from other enviornments you are often using Access, Excel, Lotus... All share the same epoch (and Leap year bug) in their date/time formats.  These vi.s have been pretty useful to me although the names may change to avoid (tm) infringements

 

Time to Time of Day.vi (Attached) has also been in my arsenal and proves both valuable and get on a few threads per year on the forum.

 

The gaps in the palatte make it a perfect fit

timing.PNG

Download All
10 Kudos
billko

Idea Exchange for NXG!

Status: Declined Submitted by Proven Zealot on 05-09-2020 12:40 PM 8 Comment

NXG needs an Idea Exchange.  The feedback button is a lame excuse for a replacement.  Why?

 

  • I can't tell if my idea has been suggested before.  (And maybe someone else's suggestion is BETTER and I want to sign onto it, instead.)
  • NI has to slog through bunches of similar feedback submissions to determine whether or not they are the same thing.
  • Many ideas start out as unfocused concepts that are honed razor sharp by the community.
  • This is an open loop feedback system.

Let's make an Idea Exchange for NXG!

View All (2)
43 Kudos
Intaris

LTS (Long-term support) vewrsion of LabVIEW

Status: Declined Submitted by Proven Zealot Proven Zealot on 03-18-2010 03:33 PM 21 Comment

I want to be able to work on STABLE versions of LV.

 

The last great stable version I remember was 6.1 (I never had 7.1).

 

2009 and 8.5.1 were not bad but please give us a feature-fixed long-term support version of LabVIEW.

 

For anyone unfamiliar with the idea, many Linux distributions offer the same:  Here's a link to the Ubuntu webpage outlining THEIR LTS strategy.

 

Shane.

View All (2)
32 Kudos
SteveChandler

Add Support for Array of Array

Status: Declined Submitted by Trusted Enthusiast on 02-13-2012 05:42 PM 20 Comment

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.

41 Kudos
Jim_Kring

Asyncronous Call By Reference

Status: Declined Submitted by Trusted Enthusiast Trusted Enthusiast on 06-10-2009 10:13 AM 16 Comment
Here is an idea that I have wanted to make happen for a while. It is the Asyncronous Call By Reference. Basically, it is just a Call By Reference, but split in half so that the call is not syncronous (blocking), and return data can be obtained from multiple locations.  Plus, there should be ways to check the status of the asynchronous call and kill it.  I've even implemented this, to some degree, here http://forums.openg.org/index.php?showtopic=88
 
 
Message Edited by Jim Kring on 06-10-2009 08:14 AM
View All (2)
29 Kudos
Intaris

Allow for ABSTRACT classes/functions in LVOOP

Status: Declined Submitted by Proven Zealot Proven Zealot on 06-08-2009 05:23 AM 23 Comment

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.

View All (2)
25 Kudos
AristosQueue (NI)

Both disable structures should have less effect on diagram synchronization

Status: Declined Submitted by on 06-17-2009 11:57 AM 26 Comment

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

16 Kudos
Intaris

Fix XControls

Status: Declined Submitted by Proven Zealot Proven Zealot on 07-02-2012 01:36 AM 5 Comment

Ok I'm going to try again.

 

I've already posted ideas on XControls before HERE and HERE but here's another try.

 

My feeling is that XControls COULD be a wonderful addition to the LabVIEW universe.  However....

 

1. XControls are kind of weird.  The implementation is kind of unusual and I finf the help available being not overly helpful.  I HAVE implemented XControls but I find myself having to re-scratch my head every time I take on such a proposal.  I would love a more intuitive way to work with XControls.  Even a state diagram showing what's called when would help.

2. XControls are buggy.  I've reported on these before but NI seems to not take this seriously.  There are two issues which make XControls unusable for me (I'm willing to overlook the complexity).

2a. Synchronicity.  Updating a value to an XControl terminal will return control to the calling code IMMEDIATELY event hough the XControl may require some time to process tha data.  This is completely inconsistent with existing LabVIEW behaviour.

2b. Dynamic events don't work properly with XControls.  If I register for a dynamic event in an XControl, firing the event will not "awaken" the XControl but the events will queue up until a valid event DOES happen at which point all the backlogged events get processed in a hurry.

 

If points 2a and 2sb w2ere addresses, 99% of my problems would go away but at the moment, XControls are just not worth the effort for most applications I could otherwise use them for.

 

Come on NI, you can do better.

 

Shane.

14 Kudos
ouadji

conditional shift register

Status: Declined Submitted by Trusted Enthusiast on 03-29-2013 12:14 PM 25 Comment

SR1.png

17 Kudos
Ali-Amin

Execution Highlighting with Auto Scrolling

Status: Declined Submitted by on 06-06-2011 02:52 AM 8 Comment

While using Highlight Execution for debugging, we end up scrolling the code to know which part of the code is currently executing, and loose context of the code due to scrolling. We could avoid this by letting 'Execution Highlighting' do the scrolling for us. Execution Highlighting with Auto Scrolling can be invoked on demand. The default behavior of the Highlight Execution will not Scroll. We should provide mechanism for users to disable or enable this while executing the code.

 

Also in case of state machine,

  • Current Behavior - If one highlights in the middle of execution and when a sub VI is executing, then the highlight will reach the case only after the control returns to top level VI.
  • This feature should also address the above mentioned behavior by switching to the case(state) in which the sub VI is executing.
View All (2)
16 Kudos
rex1030

Implement More than 14 User Ideas in the Next Version of Labview

Status: Declined Submitted by Active Participant on 09-21-2010 11:26 AM 4 Comment

According to this document only 14 ideas from the idea exchange were implemented in LabView 2010.This is a fantastic start.

 

There are at least 100 more great ideas on the Idea Exchange that should be implemented in the next version of LabView. Keep listening to the users. Keep improving LabView in every way.

 

Smiley Happy

14 Kudos
TroyK

Cancel during application or installer build that actually works

Status: Declined Submitted by Active Participant on 03-23-2011 12:08 AM 7 Comment

There is a button at the bottom right hand side of the 'Build status' dialog labeled 'Cancel'.

 

Clicking it does absolutely nothing other than grey out the cancel button.

 

I would like to suggest a working cancel function.

 

http://forums.ni.com/t5/LabVIEW/Cancel-part-way-through-building-installer-Does-nothing-LabVIEW/m-p/1495770

 

Forum post from 3 years ago...

http://forums.ni.com/t5/Real-Time-Measurement-and/Canceling-a-build/m-p/700231

 

View All (5)
13 Kudos
tadders

XControl classes

Status: Declined Submitted by Member on 05-23-2011 02:57 AM 1 Comment

How about allowing the creation of XControl classes?

 

Families of XControl classes would allow the Publish / Subscribe paradigm I'm struggling with as discussed here: http://forums.ni.com/t5/LabVIEW/XControl-publish-subscribe/m-p/1568958

 

Being derived from a common ancestor client, XControls could be managed in a collection (array) and the publisher could call a common or overidden class method for each XControl client in the list.

 

XControl classes would also allow an elegant implementation of the Model View Controller paradigm used extensively by other object oriented languages.

 

You should also allow XControls to be members of an existing class.  That way the XControl would gain access to the member variables of the class without resorting to cumbersome accessor vi's.

 

XControls sub-classes of a class should also be allowed, then methods in the parent could be overidden in the XControl.  Mediator objects can then call class methods without caring if the instance is a XControl View, Model, Controller or some other object.

 

Phill

15 Kudos
Marc Blumentritt

New property of Method to indicate, if an input of a sub-VI is connected to some source inside the calling VI

Status: Declined Submitted by Member on 06-15-2009 06:31 AM 8 Comment

If you write a multi-purpose sub-VI, it is sometimes desirable to know during run-time, if an input of the sub-VI is connected to some source inside the calling VI or not. E.g. if you have two inputs and you want to do a certain action whichs depends on which input is connected, you have to write a polymorphic VI. Therefore you have to write at least 3 VIs: one VI for each input and the polymorphic VI. With a new control property or method, which tells you if the input got it's data from some source, you could do this with just one VI. There are of course other scenarios where this new feature could be useful.

 

Regards,

Marc

14 Kudos
JackDunaway

Maintain Consistent Datatype for Property Nodes on Numerics

Status: Declined Submitted by Trusted Enthusiast on 02-08-2010 01:41 PM 3 Comment

I have noticed that Property Nodes for certain numerics do not properly store Range Properties as the native datatype of the control, but rather stores them as DBLs. I have attached the screenshot to illustrate my point:

 

PropNodeDatatype.png

 

Notice the first Numeric's datatype is a DBL, and therefore you see no coercion dots for the Range Properties or the Value Property. The bottom two examples show I32 numerics, which have the proper datatype for the Value Property, but have the wrong DBL datatype for the Range Properties.

 

I propose that the Range Properties should reflect the datatype of the Numeric, just as the Value Property does!

 

(This may affect other Property/Invoke Nodes besides Range... please list any other datatype inconsistencies you may find in the comments.)

View All (7)
14 Kudos
gb119

XControl volatile state

Status: Declined Submitted by Member on 01-27-2010 10:39 AM 2 Comment

It would be nice if XControls could maintain arbitrary state information akin to display state but was volatile and so not preserved when the XControl was saved and (importantly) did not set the VI modified flag when it was changed.

 

An XControl's display state is the natural place to store all state information about the XControl that you might want to access via property or method nodes as well as via user activity on the facade.  However, anytime the State Changed ? flag is set in the facade, then container vi is marked as having unsaved changes. This is obviously sensible if the state change is meant to persist - e.g.. control resize, but not if the state change is volatile and can bee discarded after each run.

 

There are various alternative methods that can currently be employed, but they are not satisfactory:

1) Additional shift registers on the facade - are not available within property or methods

2) Storing volatile state data in LV2 style globals - unfortunately the same global is shared between instances of the XControl. This is still the best solution as the Container refnum can be used to generate a per-instance unique identifier to enable the global to manage the state data for all instances of the XControl.

3) Storing volatile state data in a 1 element queue. There are two problems - firstly some daemon process needs to be able to keep the queue reference alive but this adds complexity in making sure the dameon process shuts down cleanly. Secondly, there is still a problem of ensuring separate data storage between instances of the XControl.

4) Storing volatile state with the data. This works where the data type supports attributes I.e.. variants and waveforms but not for the general case.

5) Storing volatile data in a tag of the container refnum. This requires scripting and private methods and only works in the development environment.

 

A better solution would be an additional ability type def that is provided for volatile state, presented as a control/indicator pair for properties and methods and prepare to save, wired through on a shift register for the facade and presented as an indicator to init and as a control to uninit.

View All (2)