Cleanup diagram is not much used (Personally I allign the diagram myself manually). But if we have few improvements with the tool we can use it atleast in sub vis more often.
At present the Cleanup diagram tool introduces unncessary wire bends eventhough it can be avoided. So it would be great if this is taken care properly and unncessary wire bends are removed.
Manually alligned without wire bends
Wire bends are introduced once the Cleanup diagram is done.
How about a feature in DETT that allows users to generate a plot of the memory allocations over time? This would be useful to diagnose memory leaks that occur over a period of days or even weeks? Currently it is difficult to draw conclusions from the details column unless the data is copied into a program that can generate plots.
In Write to Spreadsheet File.vi when we try to create control for the Delimiter, the control gets overlayed over the VI itself. The same is not happening in the case of Read from Spreadsheet.vi file, so this need attention. Please ignore if it is already suggested.
Delete From Array Function - Output should be renamed as "Edited Array" instead of the current name "array w/ subset deleted", as the 'w/' often confuses new users (and users like me as well sometimes), whether it means 'array with subset deleted' or 'array without subset deleted'.
Instead of this, the name "edited array" as mentioned in the Help itself would suffice, and is much more clear.
Help - "Returns the edited array in array w/ subset deleted and the deleted element or subarray in deleted portion."
Add a description of inputs and outputs relative the the chosen polymorphic instance of the VI.
Current documentation is Axis 1, Axis 2, Axis 3 and there is no description e.g. how those names correlate to the polar coordinates Phi, Theta and length!
I had to figure it out by trying - please just add tose few lines to the Labview help!
See the snapshot for a visual clue.
Most often we need to browse to the palette of the base data type (in this case Bool, and not only the datatype of the wire (Array)), to search/insert/replace a function while coding. Here I wanted to bring the And Array Elements function from the Boolean palette by clicking the Equal To function's output, but it gives me an option only to the Comparison & Array palettes. I'd prefer the Boolean palette to be shown up in the options.
This suggestion should be considered in a very generic & more inclusive manner for all the use cases.
P.S.:- I did not see any option for BD category, so labeling under UI & Usability (since the BD is an User Interface for me as an App Developer using LabVIEW. )
In the same way that mouse clicks, key presses etc can be filtered or modified before being accepted, having a Value Change? event option would allow tighter control over input data than possible using the Data Entry tab, and without needing to wire to a Value property node or local variable as AQ suggests here.
While this idea in itself probably doesn't make much difference, it would be very useful if such an event could be "bound" to a .ctl (a sort-of mini-XControl) in an enhanced version of what the Data Entry tab currently does.
The VI "VISA Lock async.vi" should be reentrant to allow locking a connection while waiting for another connection.
Imagine COM1 is locked and for its lock is waited with "VISA Lock async.vi". While waiting, COM2 shold be locked (from somewhere else, with "VISA Lock async.vi"). Because the lock VI is not reentrant, this call is blocked until COM1 call finishes (because of success or failure). This is independent if COM2 is locked or not.
LV Versions with this behaviour: from at least 8.6 to 14
Recently, I discovered an annoying "feature" of LabVIEW: if you limit the data entry of a floating point numeric to a maximum value with coercion enabled, entering NaN to that numeric will be coerced to the maximum that you set in the data entry dialog.
I already reported that as an unexpected behaviour, but after some more thinking, I dare to go even further and propse:
allow the blocking of NaN in floating point numeric data entry
The logic needed should not be much more than a finger exercise, as string controls already allay to discard CR/LF with the "limit to single line" property.
During implementation of code, the algorithm and its implementation has to be tested and debugged in most cases many times. For debugging, probes are a very useful tool. But probes can only be created on existing wires.
If, for any reason, the developer wants to probe values which are not on a wire already (e.g. iterator of a loop), he has to create an indicator (or tunnel) in order to have a wire. Once the debugging is done, the terminal/tunnel and the wire should be deleted.
I find it would be much easier, if i could right-click the data output and select Create >> Debug Terminal. This terminal is part of the code, but once i close the probe, the items created by this option (terminal and wire with probe on it) are removed automatically.
PS: I know that there was a suggestion specifically for the iterator of a loop. I understand the reason why it was declined, but i find that using VI Scripting, the above mentioned functionality could be provided. As i WANT to have the information of that wire during debugging, i require that terminal/wire in any case. Using some automated tool would ease the debugging process with the hope to decrease time required to identify the software anomaly.
Many of the VIs or projects that I create are just a learning experiment to get things in the right direction. My startup screen is overflowing with junk files that I never need to see again. I would like a "right click --> remove item" when you hover over junk files in the right pane of the LabVIEW startup splash screen.
Logical shift in LabVIEW discards the shifted out bit. Logical shift functions in assembly labguage settings shift that value to an overflow bit register allowing the bit in question to be tested and program flow to be altered.
This kind of function is useful when dealing with low level protocols at the bit level, or dealing with digital devices that have a parallel interface.
I suggest the logical shift function have an additional output that contains the boolean value of the bit just shifted out of the number.
Logical shift should be able to output a single boolean, or an array of boolean. For the single case, the value would be the last bit shifted out with other bits being lost. For the array output, all bits would be captured with the first bit shifted out being the 0th index of the array.
I just updated from LabVIEW 2012 to 2014, and somewhere along the way it seems the "Key Navigation" mechanism has changed.
When running a VI, sometimes it's very convenient to adjust the value of a control using the keyboard arrows (moving the caret left/right to select a digit and incrementing/decrementing using up/down). During this, I frequently need to toggle other controls, for which I've configured the "Key Navigation" settings such that I can do so without needing to switch over to the mouse.
In 2012, the caret navigation would stay active (i.e. focused/locked) on a given control while I toggled other controls through "Key Navigation".
In 2014, if the caret is active in a numeric control and I toggle another control through "Key Navigation", the focus is lost and I have to use the mouse to place the caret back where it was.
I should note that this doesn't seem to happen with the "Increment" or "Decrement" modes of "Key Navigation", just with "Toggle".
Not sure why this was changed, but having to switch between the keyboard and mouse frequently slows down workflow considerably.
Here's an idea to make better use of front panel pixels and printer paper.
1) Too much data to show on one screen using regular controls, instead of tabs, Show at-a-glace highlightable data in a configurable cluster format. Before LabVIEW 2014 the typedef table inside a typedef cluster would do thes fairly well.
2) Use same panel as print format since it is at-a-glance and one panel, WYSiWYG printing made easy
3) LabVIEW2014 crashes when table typedef is nested in a cluster typedef - this suggestion is improvement, not just workaround.
Suggestion: Bring back super space efficient (flat plain) controls and indicators, so I don’t need to worry about NI dropping support for the classic plain text one. This will allow me to make my own table like displays using individual fields in a typdef cluster. I could just format a big string control and write code to fill it in by row-column position, but that looks so DOS. How about marketing it as a report builder cluster like panel builders available in many text based languages?
1) Add space efficient flat controlls and indicators to current palette, similar to flat string control in classic palette.
2) Allow these to be placed into a flat cluster that can be typedef
3) Provide a fast way to lookup controls contained in this cluster by name, similar to get array of references and loop through for name match.
4) If desired make an Express VI to build a GUI / Report cluster similar to the way text baased programs do it.
5) Provide for setting printable paramters - shape designed for portrait or landscape and with about the right number of pixels so it fits easily into the printer (no extreme zoom in or out to fit, no half of the printed page left blank, etc..), using this shape as a starting point, nice printable panels will be easier to make.
(Unless it's been added in newer versions, i mostly work in 2011)
Allow Switcheroo on Select terminals, just like on Add, Subtract and others.
Ofcourse the Selector is excempt from the switch, it's just the terminals that should swap.
(In case you didn't know, ctrl-click on Add terminals switches their place)
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.
The sampling probe (FPGA simulation mode) is extremely handy for quick testing of FPGA algorithms. It's clunky though and needs some enhancements.
1. Align signal names to waveforms under all circumstances. Currently, the alignment is all over the place, especially when zooming.
2. Fix the zoom feature! Currently, the zoom in and out behave in random ways. Sometimes zooming vertically, sometimes only horizontally.
3. Merge the zoom in/out buttons into a single "Horizontal zoom" where the shift or ctrl keys alter the in/out.
4. Add a dedicated vertical zoom button which will also zoom the space between signal names so alignment is assured.
5. Increase the highlite effect on the selected waveform. It's hard to see.
6. Add the ability to save probe configuration so the probe doesn't have to be rebuilt every time. I've often found myself adding upwards of 20 signals and hate having to re-add those (In the same order) whenever the window gets closed.