Home > Community > 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

Rotate Block Diagram Icons

Status: New
by Member JoshuaZ on ‎04-29-2010 03:17 PM
I would like a way to rotate the block diagram icons (like +, X, etc.). right now LabView forces me to build programs from left to right. I don't always want to make a bunch of subVIs just to make it easy to fit on one screen view. If it was possible to rotate block diagram stuff 90 degrees (45 deg. not necessary) I could then connect my loop counters (i) easily to a sink that is controlled by what loop I'm on and other applications wouldn't become so large (left to right).

FXP conversion should accept arrays

Status: Duplicate
by Active Participant dan_u ‎07-19-2012 06:25 AM - edited ‎07-19-2012 06:28 AM

Basically all numeric conversions accept arrays or other data types like clusters, but "to Fixed-Point" conversion doesn't.

Strangely enough, implicit conversion (wiring a DBL array to a FXP array indicator for instance) works.

 

See image.

 

FXP-Conversion.png

 

"To Fixed-Point" should be more polymorphic, it should accept arrays (1D, 2D, nD).

 

Distribute objects according to the size of the FP

Status: New
by Active Participant ramses64 ‎08-05-2011 12:50 AM - edited ‎08-05-2011 12:51 AM

Hi all,

In a perfect world,it sould be possible to distribute items on the front panel according to the height//width of the front panel !

 

Today, when I create a dialog box, I place the controls on the front panel, close an eye move away from my screen, then watch if my buttons are well centered.

 

Tomorrow, wen I'll create a dialog box, I will place my controls on the front pannel, horizontally distribute them, and click on the new NI button to dispatch them accordingly to the current FP size !

 

 

Close build window when done

Status: New
by Trusted Enthusiast on ‎01-14-2015 08:43 AM

In building an Executable from a Project, there should be an option to close the Build Window when successful (as there is in the Deploy window, which has a "Close on successful completion" check box).  This would be a convenience, especially when doing a "Build All".

The current behavior of the LabView development system is to raise all its open windows (VI Front panel and Block diagrams that are not minimized) when one of them attains mouse focus. This issue has be discussed previously here

http://forums.ni.com/t5/LabVIEW/How-to-make-only-one-LabVIEW-window-active-amongst-other/m-p/499418?...

and here

http://forums.ni.com/t5/LabVIEW/Disabling-raise-on-focus/m-p/929970#M417655

 

The issue becomes much worse if the "focus follows mouse" mode of the operating system is activated. In this mode try to work on a non-LabView window on top of some LabView windows. As soon as you accidentally hit one of the LabView windows with the mouse, all of them pop to the foreground, eventually hiding the non-LabView window totally. This is neither necessary nor convenient!

Moreover, all suggested solution in the above links are inaceptable (e.g. minimze most VIs). I need to have open many VIs at the same time and I need to look at them, while e.g. writing documentation in MS word.

 

Now I hope I'm not the only person who learned to love the "focus follows mouse" mode during years of using linux.

So, to cut a long story short, I suggest to introduce a config option like "raise on focus" that toggles the behavior for all open LabView windows. I do not even ask to treat individual LabView windows differently, since I understand that this is not possible due to the internal window handling of LabView.

 

Thank you for reading this,

jqu

 

[FORUM: The below message is a copy of what I submitted on NI's feature request page, but I figured I would see if people here think its a good idea?!!]

Hi!

I would like something similar to this:

In Multisim I can drop a "comment" on the schematic block diagram. This will allow me to type in a (lengthy) comment and when I click ok it drops a pin icon on the schematic page.

To show the comment, mouse over it or right click the pin and select "show" which will display comment field regardless of mouse-over status.

This feature would be great to drop in comments in dense sections of complicated code, such as nested loops where the inner loop/case might take up very little screen area, but it would allow me to do this without taking up much diagram space (except for when the comment is being displayed, at which point it should behave as a "on top/front" text field, covering code below it.).

I for one would use this A LOT when writing code, but I can hardly claim that it is more than a trivial necessity....?

Add empty reference containers to the front panel

Status: New
by Active Participant Daklu Active Participant on ‎09-19-2010 01:10 PM

When working on a front panel you can drop a typeless array and add or remove data types from it.  If the array isn't typed, the vi won't compile.  (Broken run arrow.)

 

I'd like to see this behavior extended to other constructs that contain type information:  queues, notifiers, user events, and DVRs come to mind immediately but there may be others.  For me the lack of this ability is most noticable when I'm creating new classes.  I'll be trying to set up the class definition (.ctl) but if it contains any of those data types I have to open a block diagram, drop the create prim, and create a control on the output terminal.  It's inconvenient to have to do this with any vi, but moreso with ctl files since they don't have a block diagram associated with them.

 

The property node will be executed in top to bottom sequence. Changing the sequence of the property node is difficult now. In the example shown, reordering from Available sequence to expected sequence will more steps.
Proposed Idea: There should be an option of reordering the sequence on the right click menu of property node as we have in case structure (rearrange cases) 

 

The property node will be executed in top to bottom sequence. Changing the sequence of the property node is difficult now. In the example shown, reordering from Available sequence to expected sequence will more steps.

 

24278i34BF0287468F2376

 

 

 


Proposed Idea: There should be an option of reordering the sequence on the right click menu of property node as we have in case structure (rearrange cases) 

 

Attached the images also.

In Range and Coerce should be more forgiving

Status: New
by Knight of NI Knight of NI ‎08-19-2013 06:56 AM - edited ‎08-19-2013 07:00 AM

I just spent way too much time debugging a really stupid issue (it actually took that long because it was manifested in a specific location and there were some red herrings).

 

Essentially, I had code like this and I couldn't figure out why it was returning false:

 

Why.png

 

The answer was simple, once I realized the problem was there - I wired the lower value (option 1) to the "upper limit" input, which means the function will forever return false.

 

I suggest that the "In Range and Coerce" function should function correctly regardless of which input we wire the value into (maybe by including a simple Max & Min call inside it) and that the names of the inputs will be changed accordingly.

 

Possible problems:

  1. It's an extra comparison and possibly some pointer reshuffling, so it will hurt performance. The function already does comparisons, and it's relatively minor, so I think it's worth it.
  2. It might break old code of people who did rely on this behavior. I personally can't think of a good use case for relying on this behavior. Can anyone else think of one?

 

File dependent persistent file paths

Status: New
by Member CarstenPXI on ‎09-15-2010 09:48 AM

Currently, LabVIEW uses standard Windows "last path" mechanism to create the default persistent path when loading or saving files.

 

I would like to have this be made more user friendly, by having file specific persistent paths remembered by LabVIEW.  For example, individual persistent paths for Projects, VI's, Controls, etc.  This saves time navigating the file hiearchy when the file type has changed. 

 

Yes Windows has a Recent Documents folder in the file dialog, but it often is sluggish loading.  In one application that we write, we have six different persistent paths to make life easier for the end user.

 

Carsten Thomsen

Modification of vertical scroll bar behavior on string controls

Status: Duplicate
by Member eximo on ‎01-13-2012 12:34 PM - last edited on ‎01-13-2012 05:22 PM by Active Participant JordanG

New propety node or modfication of the existing property nodes for strings.

 

Enable a Vertical slider to stay locked at the bottom of a string as it grows, for instance when dumping data into a growing string as part of a loop, however if the user wants to scroll to review something they can.  Currently the easy way to make a slider stay at the bottom is to wire a very large number (inf, or -1) to the property node for slider position but this doesn't allow the user to go and review previous data, as the slider fights each loop iteration to return to the end.

I've just run into a "feature" of the LV2009 Parallel For Loops which is a bit of a nuisance!  The number of loop instances is determined by two values: 1) the number of instances in the Configure Iteration Parallelism dialog, and 2) the number wired to the P terminal of the loop.  It turns out that the number of instances created is the smaller of these two.

The nuisance is that if I wire the number of processors from CPU Information to P (as recommended) then when my new 16-core machine arrives (I wish!) I don't get that benefit unless the dialog value is also >= 16.  And the 64-core machine that arrives next requires the dialog value to be reset in every Parallel For Loop - or I set it to be some unreasonably large number now, and therefore it's pretty much meaningless.

 

My suggestion is that the default number of instances set in the dialog is "Maximum" - i.e. it will use the maximum number of processors available.  It should still be able to be set lower should the programmer wish to restrict the number below that.  Then the default case works transparently as the programmer would usually want without needing to wire from CPU Information, and there are no surprises down the track when loops don't speed up on a new machine as expected.

Terminal read event in XControl

Status: New
by Member Karin_Hellqvist on ‎08-15-2013 02:51 PM

I would like to have the terminal read event available in an XControl. If the event occurs when the data has been read by the terminal I can handle resetting the data, and get a behavior like the latch mechanical action for a boolean.

 

I found this old thread on the topic:

http://forums.ni.com/t5/LabVIEW/Latch-boolean-mechanical-action-in-an-XControl/td-p/414082

Array Reshape on the In Place Element Structure

Status: New
by Active Participant GregS on ‎04-13-2010 09:40 PM

There are many array functions that don't need to depend on the dimensionality of the array - for example most of those in the "Probability & Statistics" menu (Mean, Median, Std Deviation etc) and some in the Signal Operation (like Scale, Normalize).  But if I want to use one on a 3D array, I must first make a copy by reshaping to a 1D array, which can be very memory-expensive.  I'd like a node on the "In Place Element Structure" which accepts an array of any dimension, and makes the data available as a 1D array of that type.

 

I've suggested a similar idea before here, but perhaps I made it too complicated to receive any comments!  I keep running into this problem, so lets try again.  Smiley Happy

 

Combine the event structure and the timed loop

Status: New
by Active Participant StephenB on ‎02-10-2011 10:21 AM

From the developers perspective... events are interrupts and timing sources are interrupts. Do we need two separate way to pragmatically creating these (event registration refnum and timing source string) and reacting to these (structures)?

 

I realize there are features one has and the other one doesn't... but there is so much overlap and so much potential if combined.

I thought a little bit about how this suggestion should be called.  I also feel that NI HAS improved in this area a bit in the last few years but regardless....

 

We all know that NI sells LV as being "Easy to use" or that people can "rapidly and cost-effectively interface with measurement and control hardware, analyze data, share results, and distribute systems" "regardless of experience".

 

What I (And I think many others) miss is that there's a serious side to using LV which can only be harnessed by experienced programmers.  I feel that NI should focus more on this "experience scaleability" of LabVIEW which makes it easy to learn but very difficult to master due to the incredible breadth of features and possibilities LV offers.  I'm not a marketing guy, so pelase don't ask me how to do this, but I think that maybe highlighting the software engineering side of LV development would help.  How about pushing examples of the classic software architectures or demonstrating some more advanced features which don't work "regardless of experience".

 

LabVIEW grows with any user's knowledge of software engineering and I just feel that this should be focussed on a bit more.

 

I'm interested to hear people's opinions.....

Since I got the proverbial hook on the pervious progress terminal for a FOR loop, I thought I would take another stab at it.  Should the N Terminal be sliding along the front border of the structure?  And even though it fell flat, I still like my progress terminal, albeit with a more appropriate symbol.

 

23162iD83AF4B6706A414B

trim whitespace

Status: New
by Member stbe on ‎09-02-2010 08:56 AM

The current version of Trim Whitespace.vi uses regular expressions that are quite slow, but not needed since only simple search and a substring function is desired.

Therefore, I suggest to throw out the regex functions and replace them with G code looking for the same whitespaces (or even extend the selection to the openG variant).

I use the presented version within all my string processing functions, but many shipped VIs (especially the NI_LVConfig.lvlib) uses the trimming functions a lot. Since I do a lot of config files, this starts to be the bottleneck of the total LV code.

 

23008iC728CE59C53E9B3C

 

left-trim sub-VI:

23006iC444DD465E2506D4

 

right-trim sub-VI:

23010i7E67AC14F8028ECC

 

Performance metrics suggest speedup of about a factor of 15 for short strings and even more (>35) for longer strings.

if a control definition is missing we can replace the new control by coping the new control to clip board and pasting on top of the control. This preserves the wiring of the control on the connecter pane.

 

Similarly we can have the option to replace the missing VIs (?) by coping the new VIs in the clipboard and pasting it or

add an option on in the replace menu like replace from clipboard, and it will preserves the connections.  

Often when using the rounding functions and other numeric functions you need to convert to a particular data representation.  it would be nice if this was built in:

 

Smart Round

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