While replacing the Property nodes with Invoke node, Call by Reference, Start Asynchronous call and Wait on Asynchronus call, the primitives are shifting the origin disturbing the wires. So a cleanup is reaquired all the time whenever the items are replaced. It would be very helpful and infact time saving if this is corrected.
Place a Property Node in BD with the Error in and Out connected
Replace the Porperty Node with an Invoke Node
Repeat the same with other primitives
The same behaviour is not found when the Call by Reference, Start Asynchronous call and Wait on Asynchronus call primitives are replaced with one another.
As shown in below image we can see that, if I index numeric array and wire it with any of the node from numeric function it gives un-aligned wire whereas as same process if I use Boolean function at output of index it gives well aligned wire.
So due to this numeric function node wire to index out terminal makes our code with full of wire bends which is not as per NI LabVIEW coding standards also.
So here, I want to draw attention for NI, to do some correction to specific numeric function nodes so we can make neat and clean code in LabVIEW.
(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?
We all know the limitation that the "Data Operations"-->"Make Current Value Default" operation when right clicking controls is limited to edit-time only.
I often find myself writing code to save the last value that a user has entered in some sort of ini file (ini, xml, .dat, etc...) so that the next time the code starts up, the last values are reloaded to those controls. I have written some generic code that handles this functionality by wiring in control references. It then monitors those controls for changes and it saves the values to "VI Name"+"_Last.ini". Upon startup it loads the last values from that .ini file. The two attached VI's show this functionality. One VI is a Daemon that spawns the main process asynchronously so that the coder doesn't have to handle it themselves.
It would be nice if this could be handled intrinsically in LabVIEW. What I'm envisioning is a checkbox for every control that, if checked, would function similarly to how the above code works: it would save the control value in a .ini file associated with the owning VI. Since this is built-in it should also have accompanying properties for the control property node so that it could be accessed pragmatically and fired programmatically with the "Value Signaling" property. That would be awesome!
In many cases where I use file path constant instead of control. For selecting a path either we can right click and select browse for path or paste a copied path into the constant.
So it would be a nice and handy option to have a browse button along with the constant as the control has. This button won't respond when the code is executing or while the BD is in run mode similar to the other Enum/Ring constants. This button can be enabled or disabled or made always to be enabled or whatever may be the best approach. This button may be disabled when "invalid path" is selected.
I have modified the Path constant suggestion and now I feel its not going to take more space.
Mouse turns to select pointed when hovering over the button.
Upon clicking the button the browse window appears
I recently found out that LabVIEW uses the Wichmann-Hill (1984) random number generator.
...which in some fields is completely unacceptable for not being random enough (cycle length of 6.9536e12?)
A much better (and arguably a much more currently standard one) would be Mersenne Twister (cycle length of 2e19937−1).
"In Range and Coerce" function should have swap terminal option. The upper and lower limit shall get swaped.
So recently I learned of another feature that the In Place Element structure has, that the native functions it represents doesn't. The IPE structure support splitting arrays, and it can split multidimension arrays like 2D and 3D arrays. In doing so you can also specify the dimension that it can be split along by right clicking and choosing Split Dimension. So is there a reason why the native Split 1D array function can be made into the Split Array function with the same features as the IPE?
Attached is a snippet showing the current method of splitting an array with IPE and the primative for a 2D array.
There are numerous ideas floating around about where the color box constant and control should be located in the palettes. How about if there wasn't a distinction between a color box and its numeric representation? Like the "View As Icon" option on terminals and clusters, I suggest a "View As Color Box" on numeric constants and controls/indicators:
I'm undecided on if this options should be available for all numeric data types, integers only, or U32 only, and what should happen to the Representation options when the numeric is a color box. I see at least these options (ordered after my preference - I prefer 1) the most):
1) The "View As Color Box" option is available for all numeric data types, but when selected the data type changes into U32. If you change Representation to anything else but U32, the "View As Color Box" option is automatically deselected.
2) The "View As Color Box" option is available only when the numeric is U32.
3) The "View As Color Box" option is available for all numeric data types, and coercion happens between the selected "color value" (U32) and the true Representation of the numeric.
I like to collapse long string and path constants to consolidate diagrams. Showing the string or path value in the tip strip is useful but tedious to update.
I suggest an appearance property that would automatically display the current value in a tip strip for string and path constants.
This property would be most useful if the Block Diagram Options page was also modified to allow a global setting.
"Find Items with No Callers" could be a useful function on the project, but currently most items it reports are in Dependencies. Why is an item even under Dependencies if there is no caller? It seems if I call one function from an .lvlib the whole library is in dependencies, and all other functions have no callers. This floods my "Find Items with No Callers" window with useless entries.
Suggestion: add option to hide items from dependencies in the "Find Items with No Callers" window (or even hide them by default).
One of the things that sometimes bugs me when using LabVIEW is that if you have a front panel or block diagram in a small window, many of the menu options and toolbar options are inaccessible without having to resize the window first. You have to have a minimum window size to be able to access all of the toolbar functions.
Still don't get it?
This is how big I want my SubVI window to be:
Problems with the above:
To be able to access the entire toolbar, the windows has to be at least one of the following wide:
Why is this a problem?
Please make it so that the menu and toolbar are accessible regardless of window size. One solution would be to have a button that allows you to 'scroll' the toolbar or have a pop-up dialogue that shows the missing toolbar buttons as per the image below.
MS Paint skills (icon lifted from Chrome's bookmarks bar):
As an aside, MS Word manages it fairly well (even though it isn't that readable), and it has a LOT of toolbar buttons:
Please consider my idea (or Kudos it) for future versions of LabVIEW - it will improve usability of the IDE.
Looking at all my body of work, I use tables exclusively as indicators. They are well suited to display formatted results in tabular form, but much less suited for user input, because they only allow strings. If we need to enter numbers, there is no input validation (as we have e.g. for numeric controls), so they are pretty useless for that.
It is thus a bit confusing that the tables in the palettes currently exist as controls. In fact, the modern, classic and system tables are even labeled "Table Control" (seems redundant!), while "Table" alone would have been sufficient (this has already been corrected for the silver controls ).
It would be much more appropriate if tables are indicators by default. We can always change them to controls in the rare case where this is needed.
VI hierarchy should allow hiding shared variables (just like it can hide type defs, globals, etc...). Using hierarchy view for any project with comact I/O compact RIO etc... is not practical since all those shared I/O nodes hide the useful interconnection information.
I am taking advantage of the recent FileVersionInfo to pull up the Version Number of the Executable at Run Time and display it for the User (who can then call me and say "Version 188.8.131.5234 crashed", and I can figure out which source this was). I take advantage of the Pre-Build Action to create the Version Number, taking the "Build" part from the Revision Number of the Project itself (since the Pre-Build Action gives me the path to the Project, this is fairly straight-forward).
However, in order to get the correct Build to appear in my Executable, I must build twice. The reason for this is that LabVIEW apparently reads the Version information before executing the Pre-Build Action, so my attempt to set it to the "correct" value is ignored until the subsequent Build.
Personally, I think it is illogical to have a "build Action" that silently takes place before the user-specified "Pre-Build Action", though there may well be a hidden "good reason" for this. I would like to request, therefore, that LabVIEW include a "Feature" that specifically allows the Pre-Build Action to include not only setting the Version Information (which it currently does) but allowing this updated Version Information to be used in the current Build. True, the work-around of "Build Twice, Use Once" works for me, but why should we need to jump through this particular (unpublished and unexpected) hoop?
Digital controls on the front panel can be set to coerce user-entered values to specified minimum and maximum values using a property panel. This is very convenient. However, there's no obvious visual indication that this property has been modified from "Use Default Limits". A colleague inherited a SubVI where some front panel control values were being coerced through code on the block diagram. What he didn't know was that the control properties were also set to coerce, and to different values. It took him a while to figure out what was going on.
What if block diagram terminals had some visual indication that their control no longer has the "Use Default Limits" property set? For example, see attached sketch.