If I want to act on a Library, obviously I can just open a Member VI and get a reference to the Parent Library to do this.
However, I feel it would be more natural to Quick Drop on the Library in the Project itself!!
I also feel that it would be faster...
...And isn't that what Quick Drop was invented for?
I don't know if native options would ever exist, I am looking to call my own shortcuts - but there is alot of scope to implement custom plugins.
I have only given one example above.
We can right click and insert a VI using a right click. However it would be nice if we could hover over a wire and use Ctrl-V to paste a VI and have it get wired automatically. Granted it may not be able to wire everything but it could be fairly intelligent and wire up what it can.
A few special functions are incorrectly named in the LabVIEW documentation.
- the incomplete gamma function VI returns the regularized lower incomplete gamma function (as is the case in LabWindows/CVI).
- the incomplete beta function VI returns the regularized incomplete beta function.
Suggestion: change the description (and name) of these VIs to reflect their common mathematical definition.
Valid at least until LabVIEW 2013 SP1.
As described here, LabVIEW will call certain event callback VIs when certain things happen such as LabVIEW startup or shutdown, creating a new VI, or calling Edit > Create SubVI. The only problem is that there can only be one Callback VI per LabVIEW installation. My suggestion is to allow more than one callback VI to be called when the events happen. This can be useful if LabVIEW add-ons would like to implement the functionality without interfering with existing callback VIs.
This is similar to my previous idea, but generalized for all the callback VIs.
I would like a better way to clear the list of recent files and recent projects in LabView. It is often disireable to clear the history when changing to a different project or a different user. Currently the user must close LV, edit the .ini file and restart LV. I would like to see menu selections added to allow the list of recent files and/or recent projects to be cleared.
The addition (in 2013) of the ability to use tags in the directory names of the builders struck me as really useful - normally I build to a ...\MYPROJ\... set of directories (each of the ) then rename ..\MYPROJ\... to ...\MYPROJ x.x.x.x\.... as required. When I read of the ability to use [VersionNumber] and [ProductVersion] tags I thought wahooh - at last an automated mechanism. However when I played with the tags it became clear that each builder (app; Installer; Source) used its own version and did not have access to any other builds' version info. Hence I could not use a single version in all builders. Especially as the Product version is one digit shorter than the others.
Given the principle that the builds now accept tags (akin to macros in my opinion) it would be really useful to have a global version tag (that could be set automatically or manually as present versions) accessible from all builders in a project for use in directory name creation and ---- to go even further ---- to have this global version available from inside the project VIs so I can use it in my window titles and About boxes (I currently use App Info VIs to get a version, date etc to do this).
Would it be good, on the Graph Properties page, Plot tag, one can set up the Y-scale to left or right? Good idea? Give this idea a Kudos!
At present, one can achieve a two Y plot by: right click the Y axis, Duplicate Scale, Swap Side, and often confused with which plot is associated with which data set. A cleaver package like LabVIEW should not need to do this. Just look at what Mathcad does.
I see that LV 2012 uses the original text font/size/style when pasting text from the clipboard.
LV 2011 and earlier didn't. They just pasted the text using the font/etc of the object it is pasted into.
Is there a way to disable this "feature" or should I report it as a bug?
I didn't turn up anything when I searched for this.
Wen LabVIEW starts it tries to not do everything immediately so that the startup can be as fast as possible, this is great.
However, one of the things it appears to lazy-load is the shortcut (i.e. right-click) menu. Very often I will have had LabVIEW open for some reasonable period of time (minutes, hours etc) and then I will need to do an operation that is easiest via the shortcut menu. Currently this causes LabVIEW to load all the relevant menu options the first time, and it can take a few seconds even on a fast PC. Subsequent operations are virtually instantaneous.
I propose that the short-cut menu options get loaded in the background automatically some time after LabVIEW has started. This could be something like a minute or so and I would probably never notice it.
Note I use the word "load", I do not really know what is going on behind the scenes, but from the sluggish nature I presume there is some disk access going on the first time it is created. Substitute the word "load" word with whatever feels more appropriate (initialise?).
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)
Attached the images also.
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 !
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.
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.
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.
"To Fixed-Point" should be more polymorphic, it should accept arrays (1D, 2D, nD).
Add "Change to Array" feature on Right Click for a control or constant.
So many times I have to select the control (or constant), then select an array, then place the control into the array.
On a right click, the panel with a 'Change to Array' selection would be a real time saver.
I didn't find anything that listed this feature, but I figure this would have already been a feature if it had been posted.
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.
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.....