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!
Top Kudoed Authors
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

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

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,...).

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.

 

 

It would be nice if the Strip Path function had a recursive option rather than having to string Strip Paths together or use an external loop.

 

 eg change from this:

strip_path.png

 

 

to this:

 

recursive_strip.png

 

 

regards

Ray

The default LabVIEW environment option should not show terminals as an icon. 

 

IconTerminals.png

I can't count the number of times I've seen this dialog :

 

remove.png

 

Of course I want to continue, that's why I right-clicked the structure and chose Remove [Structure]!  This dialog must be a holdover from pre-Undo days.  Do we pop-up a dialog when you select your whole diagram and press <Delete>?  What about when you press Ctrl-B?  These actions have the potential to remove just as much diagram content as Remove [Structure].

 

Please get rid of this dialog, and just let us Undo the operation if we need to, just like we do all the other potentially destructive diagram edit operations.

What if I had this:

 

idea1_1.PNG

Then I wanted to insert something with similar terminals:

 

idea1_2.PNG

 

I'd end up with this:

 

idea1_3.PNG

 

But the Error terminals aren't wired! So maybe I should be able to select both wires:

 

idea1_4.png

 

Then Right Click » Insert Write Node:

 

idea1_6.PNG

 

Then I'd have this:

 

idea1_5.PNG

 

How easy would that be!?

 

 

 

 

 

(Unless it's already changed in newer LV's, i'm on 2011 right now)

 

When opening the connector pattern, the current isn't marked in any way. If i'm after some extra connectors or a symmetrical one (why do people choose 3-1-1-1?) it'd be nice to quickly see where to start looking. A simple bold outline would suffice, maybe in blue?

 

ConnectorPane.png

 

/Y

Add new features, flexibility, and new controls to the Front Panel.  The only new controls I've seen were made by LabVIEW Customers, and although they were great, they were not resizeable without being distorted (bitmap).  I think it's time for NI to give more options and features for the Front Panel Controls.  I attached some suggestions.  They are there for example, so don't focus on the controls I've made, but the idea of improvements I am suggesting.  NI has done a great job on the Diagrams.  I should hope it's time NI improves the Front Panel.

 

Suggestions

For reasons outlined in detail in this idea, the the expression node should be redesigned. These vertical lines are too thick and the end arrows are pointless and too busy.

 

After all, the expression node is basically a [single line|single variable] formula node and for this reason it should look more similar to a formula node.

 

Here is my suggestion for the redesigned expression node (on the right). The current design is shown on the left for comparison.

 

 

 

Note that the grey left and right borders are exactly matched to the border design of the formula node, making things consistent and intuitive. (Top and bottom should remain single pixel to save diagram space). 

 

We've all seen it: The annoying 1-pixel bend when wiring between VIs with mismatched connector panes. Many ideas have been proposed to address this on a small scale... But I think it can easily be improved on a much larger scale.

 

IDEA:

Modify the way the 5335 connector pane is rendered so that the top and bottom terminals line up with those of the standard 4224 connector pane.

connectorpanes.png

 

In case the image doesn't say it all, all I'm proposing is that the top-left terminal of the 5335 connector is made 1-pixel larger by stealing 1-pixel from the terminal below. Likewise for the top-right, bottom-left and bottom-right.

 

The obvious benefit is that it becomes much neater to wire errors and references between mismatched VIs. Goodbye OCD! Smiley Very Happy

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

 

 

I need to adjust the sampling rate of a Waveform, TSA Resampling VI accomplishes this task but it does not keep t0 value since it creates a new waveform instead of adjusting the original one.

I think an additional feature should be added to keep the reference of the original waveform, or specify in the documentation that you will have to modify the VI in order to keep t0.

 

TSA.png

 

 

 

Self-explanatory screenshot with the requested new feature, please see below. More here: http://forums.ni.com/t5/LabVIEW/Save-as-with-quot-open-additional-copy-quot/m-p/3322789/highlight/tr...

 

save_as_new_feature.png

When using the Distributed System Manager to remove processes a dialog is shown confirming their removal, along with a list of the processes to be removed. Depending on display resolution and the number of processes to be removed, the dialog extends well past the bottom of the screen, making the Yes and No buttons largely unusable.

 

dsm_remove_process_dialog.PNG

Instead, the list of processes to be removed should be shown in a list box, table, or similar with a vertical scrollbar, and the confirmation dialog remain a sensible size.

 

(I know I can just hit Enter as Yes is the default option, or remove fewer processes at once, but that's beside the point!)

This is a very simple improvement, since the features are almost there. I want the block diagrams look like an electric diagram, that is: Controls aligned to the left, with the labels on the left of the control and the indicators moved to the right with the labels on the right, like this:

Wish.png

 

The problem is that in current LV versions the alignments occurs on the labels as well, making look the diagrams like this:

Current.png

 

Normally you should: 1) align labels relative to the object and 2) align the objects (without the labels) relative to the block diagram. This kind of cleaning up saves a lot of space and clutter.

 

Now I am pushing my luck, but it would even be better if I could have these settings on SubVI's only, because I usually don't want this in my main.

 

Good luck 

 

As outlined in this post, the current identical look of the Expression Node and Convert Unit can cause serious miscommunications, since their functions are completely different.

 

I suggest that they are made to look different so we can tell immediately what we have.

 

For example the two results below are very different, even though the code looks absolutely identical if the labels are hidden.

 

One possibility would be to make "convert unit" a different default background color (example shown below), but there are probably even better suggestions. How about rounded corners (not shown)?

 

 

When creating a control or indicator based on a subVI terminal or strict typedef, formatting (speicifically the radix) is preserved.  However, when creating a constant from the same source, the format is removed.  This can cause incorrect behavior to inadvertantly be implemented when dealing with components that use Octal or Hexadecimal, as incorrect values can be input under the assumption of the correct formatting.

 

 

radix.png

 

 

Instead, block diagram constants should display the same behavior as controls and indicators, and maintain the correct radix/formatting when created from an existing source.

 

 

 

This is not directly related to LabVIEW but I haven't found any other thread which seems like a better fit. I'm posting it on the Idea Exchange since this is the best place for other customers to potentially agree with me.

 

NI drivers/software are quite often large, and above 1 GB is not uncommon and sometimes above 3 GB. Having everything in a single file is in my opinion a good thing because I don't have to look for multiple driver parts and download packages, but the file size must be matched by the download speed. Waiting three-four hours or more to download a single driver is not a fun thing to do and quite often you need more than one driver.

 

Sometimes the speed is okay, but as a general rule I would say it's slow. I'm located in Sweden and of course this issue is dependent on a lot of links between where I am located and the server where NI host the files.

But, download speeds of 200-300 KByte/s from NI are not uncommon but I can run speedtests on for example http://www.speedtest.net/ and get download speeds at 50Mbps using American servers.

 

I don't know how NI host the files, if it's internal servers or something else but it would be nice if NI looked into the possibility of somehow making this faster.