LabVIEW Idea Exchange

Community Browser
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!
cancel
Showing results for 
Search instead for 
Did you mean: 

Do you have an idea for LabVIEW NXG?


Use the in-product feedback feature to tell us what we’re doing well and what we can improve. NI R&D monitors feedback submissions and evaluates them for upcoming LabVIEW NXG releases. Tell us what you think!

Post an idea

This would be useful for variables whose value is not yet available at deployment time, and is filled later by some process.

 

Currently (LV2017.1f3), it is not even possible to input a non-numeric value in the inital value page in the variable editor. Attempting to do it programmatically like this:

LabVIEW_2018-11-18_12-48-49.png

produces a LabVIEW:  (Hex 0x8BBB0018) Invalid float value.

Whereas, blindly editing the lvlib file to 

 

<Property Name="Initial Value:Value" Type="Str">NaN</Property>

produces a "deployment failed (error: -1950678996, LabVIEW:  The variable configuration is invalid.  Edit the variable properties to correct the configuration.)." at deploy time.

 

It would help if the Error Ring had an error in.

Error Ring Error In.PNG

 

Now we always have to use a merge error (A).

 

This does hurt performance as well (B), as Error Cluster From Error code is always called (and isn't lightweight).

 

With an error in, no more merge errors (C)!

 

And performance gain (D) as a bonus.

 

Guess this input is deliberately not there? Can't wait to hear the arguments against it...

This is not directly a LabVIEW idea, but it is still an idea that impacts many LabVIEW programmers.

 

To keep my distribution small, I distribute my installers without run-time engine and instruct the users to download and install the relevant run-time engine. I provide a link to the run-time download page.

 

Note that these users are NOT NI customers and not interested in any NI products. They are my customers (well, my programs are free) and are only interested getting my programs to work on their PC. They don't even care what was used to develop the program. There is no extra hardware involved. If they already use NI hardware, chances are they already have a profile.

 

My users don't need a NI profile and don't need the follow-up phone call or e-mail from NI, etc.

 

Typical phone exchange yesterday:

 

me: "just click my installer and install the program"

him: "OK, done."

me: "now run it."

him: "OK, ...... error about 2013 run-time engine".

me: "OK, install the run-time engine using the link I sent you in the same e-mail".

him: "clicking the link to go to the run time engine page....

        (..30 second discussion to decide between downloader and direct download...)"

him: "click..(wait for it!)... .it wants me to register..."

me: "OK, let's forget about that. come down to the lab and I will do it for you."

 

End result: more delays (it was late Friday and I was ready to leave), more work for me, more hassle.

 

While gazillions (Smiley Very Happy) of registered users sounds good on paper for NI, these are false numbers because many profiles are one-time use and quickly forgotten.

 

I think downloading a run-time engine should NOT require a NI profile. Maybe it should still offer to log in or create a profile, but there should also be a bail-out option similar to "[] I don't want to register at this time, just download the run-time!".

 

 

Note that even better long term solutions have been proposed, but this idea could be implemented quickly and does not even need to involve any LabVIEW developers. Smiley Very Happy

Hi!

Maybe this has been already requested elsewhere and I'm missing it....

but it would be useful to have a Wait (ms) with connectors for error in and out.

This can help keeping the BD clean...

Marco

18613iCF039EA34765F743

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.

Currently if you right click on a subVI from the block diagram and choose properties, it brings up the Object Properties dialog.  The only options you can change there are label options, which can easily be changed in the "Visible Items" submenu.  I can't think of one time when this has ever been what I wanted out of this action.  Instead, I think this action should open up the VI Properties Window for the VI.  

 

properties1.png

The size of the Close Reference VI makes it impossible to draw a proper block diagram.

d.png

 

It is too big!  It does not match with the Property Node vi.

 

Therefore I would propose: --> Make the Close Reference VI smaller!

 

See the picture below for an example of (what I consider to be) a frustrating "feature".

Why delete the elements? Keep the elements and the element style types as is, just convert my cluster to the new style type.

Arrays also do this, but since we tend to spend more time designing clusters, it's far more frustrating than arrays.

 

 

 

ClusterReplace.png

I would like the ability to probe the loop iteration terminal ("i" in For and While Loops) without the need to wire it to something (indicator, edge of structure,...).

Bookmarks are great.

But why not bookmark on front panel? I think at least free label with hashtag on front panel shall be listed in the bookmark manager as well. Bookmark on the front panel can be used as reminder for coming back in future.

 

Kudos?

This drives me crazy...  I've noticed that if I have some code on my block diagram (or controls on my front panel) the scroll bars indicate that there is more stuff outside the view of the window that can't be seen.  It would be nice if the scroll bars only activated if there was actually code outside of the screen to be found.  Every time I see this, my OCD kicks in and makes me try to move my diagram to show the hidden code, only to realize that LabVIEW is just messing with me...

 

Of course an image is worth 1024 words..

 

gotcha.png

Many Real-Time Testing (RTT) systems require a mechanism to store data in one central location that can be accessed by the different parts of the application. The Buffered Variable Table (BVT) is a set of LabVIEW VIs that developers use to store and retrieve data asynchronously from different parts of an application.

 

Normally, when I program applications in RTT, I need store data in one central location that can be accessed by the different parts of the application, for this, I usually use "queue operations" with a fixed size.

 

But sometimes, I need to insert an element at the beginning of the queue, but if it is full, it is necessary to dequeue and queue again.

 

To solve this problem, I could use a code similar to the image, but the applications could become unstable.

lossy.png

 

For this reason, my proposal is that labview provides the function of "Lossy Enqueue Element At Opposite End".

 

I would be surprised if this is not a duplicate but I was unsuccessful finding it.

 

The subject says it all. Simply add a scrollbar to free text labels. I sometimes use a string constant for free labels simply because they can have a scrollbar.

 

scrollbar.png

Currently in LabVIEW if you build an installer you end up with a hierarchy of files that look like this:

 

singlefile1.png

 

If you want to distribute this installer via the web, you need to use a third party program to zip it up, or create a self-extracting zip file.  Since LabVIEW can already create zip files with no problem, I propose the ability for LabVIEW to create a single file installer that can easily be distributed, like this:

 

singlefile2.png

 

This can be as easy as a checkbox in the current installer Advanced page:

 

singlefile3.png

It would be nice, if the different kind of LabVIEW windows would have slighty different icons within the windows taskbar. It would be easier to quickly identify BD / FP / project / Ctrl / etc. windows in the taskbar.

 

This suggestion has also been made at

http://www.labviewforum.de/unterschiedliche-Symbole-fuer-Frontpanel-und-Blockdiagramm-in-der-Tasklei...

Here you can find two suggestions for FP & BD-icons.

Sometimes we have a need to do some mild synchronization between otherwise parallel tasks. Typically we would use a flat sequence (but there are also exceedingly fancy tools such as "Rendezvous"). Even a flat sequence is often overkill for the given situation: It is a 2D object with it's own diagram and input and output tunnels. We need to decide what should be inside and what should be outside.

 

I suggest to extend the idea to a 1D object: The "Synchronizer Bar". It is basically a flat sequence with zero frames, condensed to a single vertical line (Maybe we could even allow kinks in it???).

 

The function is very simple and immediately intuitive (as anything in LabVIEW should be!!) and can be described in a single sentence:

 

"No data can leave any of the tunnels until all tunnels in the structure have received data."

 

Ideally, we should be able to "free-hand draw" this structure interactively with the mouse and a tunnel will be automatically generated for each wire we cross.

 

Here is a dumb (but illustrative) example (ignore the code itself). That's how it could look like.

(At the moment I simply merged the edges of a flat sequence, but I am open for prettier suggestions Smiley Wink)

 

ZFF.png

 

 

Overall, it should be closely related to the flat sequence and include certain right-click actions (e.g. Add frame before/after, which would expand it into a flat sequence).

Digital display Misalignment.png

Digital display Misalignment solution.png

 

In the old days the digital display was automatically aligned with the plot legend (if I remember well). Now it is by default not.

It takes some manual alignment actions to get them right. But don't resize your chart!! You can start all over again.

 

I propose the option to align the digital display as shown in the last picture.

 

(BTW, looking for duplicates I found one comment in http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Assembly-of-the-graph-s-plots/idc-p/1085440)

 

I have used labview for a long time and avid user.  One issue I have been hitting lately is the "LabVIEW everywhere" slogan never really panned out, it has become LabVIEW everywhere NI allows it to be.  I am getting jealous of the Arduino and Rasberry Pi and hundreds of PICS and ARMs not avaliable to me (Yes I have the pro liscence but not embedded).  I wish Labview pro opened up the toolchain and started porting to many other platforms by default.  I am seeing jobs that labview is loosing ot to where it should be much more competetive like the embedded market. 

 

Essentially I am looking to see the Labview development environment easily work with toolchains for the most popular processors and also open up a simple standard to add targets to projects. 

 

Wouldnt it be nice to program a $25 ardunio dirrectly from labview (NO THIS IS NOT WHAT THE TOOLKIT IS DOING).  Add a Ardunio target file (maps the io memory to variables and throw down a loop, boolean shift register, a wait and a digital line variable, download to the micro and the blink led example is done.  Really open up the doors for LabVIEW everywhere.

 

 

My suggestion is that a Polymorphic VI should be able to contain Malleable VIs - as of LV 2018 this is not possible, and I don't think I've seen it suggested before.

 

The particular use case I have in mind is for a VIM which computes the average angle of an array of such angles, but changes a constant depending on whether angles are in degrees or radians.  The desired option is a polymorphic selector for Degrees/Radians which would then select the appropriate VIM.  The only available option currently is to add an Enum to the VIM. (A VIM is used to cope with representation and number of array dimensions).