Like it or loathe it, Microsoft Excel is heavily used for storing, recording and analysing lots of data and many LabVIEW programmers must find they need to get data into or out of Excel. However LabVIEW lacks the ability to read and write Excel files directly. It is possible to exchange data with Excel via ActiveX automation, but this:
requires Excel to be installed on the same computer as the LabVIEW application
is not cross platform
is complicated to do
does not appear to work reliably across different versions of Excel
The Report Generation Toolkit allows creation of Excel files but this costs extra and is not cross platform.
Many software packages can read data directly from Excel .xls files (e.g. Umetrics SIMCA-P) and presumably it is therefore also straightforward to write data out in Excel .xls format. Native LabVIEW functions for reading and writing .xls files - for example, into string arrays - would be very useful. It would not be necessary to support formatting, charts etc - although some kind of basic formatting support might be useful.
Of course it is possible to exchange data with Excel via delimited files (comma- or tab-separated values) but the .csv format requires characters such as quote marks, commas and carriage returns in a string to be escaped so that they are not incorrectly interpreted as part of the file structure. Tab-separated files suffer less from this problem but on Windows at least, files with a .tsv extension are not automatically associated with Excel whereas .csv files are. It would be helpful if LabVIEW also had native functions for reading and writing .csv files with correct escaping for Excel.
Make it possibly to dynamically register references like tcp/ip, visa, queues, etc. for Event structures. Possible events are "new bytes at tcp/ip", "new bytes at seriel port", or "connection closed". In the case of queues it could be the same function as "Dequeue Element" or "Queue referenced closed". There are certainly a lot more of similar references, which could be registered for catching events, which up to now we have to poll regularly or use other event functions (as in the case of visa -> new bytes at seriel port). Benefits are: no more regular polling of changes, better integration of several functions (like using queues to communicate with GUIs instead of dynamic user events), and in my opinion just better code.
In the world of robotics, underwater vehicles, autonomous systems and more...there's a need for a few more UI controls that turn into quite a hack with the current picture control implementation. To quote a few of my new friend (Philbot and PJM_JKI)...
We need 1) A Compass (see attached image), 2) A way of displaying Pitch and Roll (like an artificial horizon) 3) A way of displaying thruster control (usually tie to the Pilot joystick)
...quoting PJM_JKI directly..."If there are no new native controls added, I would request improving the Picture Control (this would, in general, be a very good thing for LabVIEW). For instance one can create their own control using the picture control (see attached image of the compass we put together using this technique), but there are several limitations that requires a lot of work to overcome.
Picture control improvements:
Performance (I think it will make a major difference if the Picture Control would use OpenGL Hardware acceleration for instance).
Support for alpha transparency.
Support for drawing antialiased object (such as lines, rectangle, circle, arc, ....)."
Something as cool as this is possible...but with a lot of work (from PMJ_JKI):
If unwired it would default to 0, and at least let thread switching occur. You could maybe right click on the loop and remove the wait node to make it run as fast as possible (like it is now), but it should be there by default... Maybe also right-click on it and get to choose between "Wait (ms)" and "Wait until Next ma Multiple"?
(PS: I know that you can do this using timed loops, but I'd like to see it in all of them - I've seen too many "programmers" complain that their CPU is at 100% because their loops are going nuts).
Having a native polymorphic PlusAndMinus function would clean up so many of my diagrams. Anything where you are programmatically resizing and centering front panel objects or objects in the picture control toolkit would benefit the most, but there are plenty of other uses.
Sometimes I like to have the Context Help window viewable to my users so they can hover over FP elements and get some quick pointers on their respective functionalities. I'd like to be able to control the position and size of the window, and also choose programmatically when it's floating/not floating, so I can have it blend into my user interface more intuatively. It'd be great to be able to embed it into a subpanel too.
This goes a bit with Christian's suggestion to separate edit time and run time front panel sizes.
While I do appreciate the alignment grid on the front panel I find it insufficient a lot of the times. What I would like to see is some alignment helpers similar to the ones that are provided in the form editor of MS Visual Studio:
When you move a control close to another control, it automatically displays a standard distance "helper" that you can snap to.
When you move the edge of one control close to the edge (in one dimension) of another control a vertical or horizontal line is drawn from that other control to which you can snap, regardless of whether it happens to sit on a grid line or not.
When you move a control close to the edge of the front panel a standard distance "helper" is displayed that you can snap to.
All of these features should be available for a move as well as for a resize of the controls.
You can find screen shots of what I am talking about here and here.
IMO, the Diagram Disable Structure causes bugs, because the output tunnels of the Diagram Disable Structure are set to "Use Default if Unwired", and the default values are very often not desireable, as can be seen in the screenshot, below:
When we read the "cursor index" property of a cursor from an intensity graph, we only get a single number. This is insufficient and inconsistent.
Since the graph data is a 2D array, we should get an array with two elements, one for the x-index and one for the y-index. Two indices are required to translate the cursor position to the corresponding array element.
(This change would make it more consistent. Have a look at the output of e.g. "array size" and "array min&Max" when the input is a 2D array. Same thing!)
Since very early LabVIEW versions, we always had the small sizing tip strip at the bottom that showed the current size in pixels when resizing an object on the front panel or diagram.
This is maybe OK for simple decorations, but for most other objects it is very inadequate and not helpful at all. For example if I resize an "index array" node to show more outputs, the node size in pixels is probably the least interesting information! It would be much more useful to indicate the number of outputs instead.
Now if we resize an "index array" node for 8 outputs, we simply resize until the tip strip shows [8 outputs]. Without this, we need to guess the size, count, resize again, etc. A slow, tedious, and error prone process, especially for larger sizes.
Of course the "resize tip strip" should adapt depending on the object that is being resized to always show the most useful values(s). Here are some possible examples: