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