LabVIEW Idea Exchange

Community Browser
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

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.

Hello everybody,

 

(as suggested I will separate my idea Expand the functionality of Event structures into four seperate ideas to allow giving kudos separately.)

 

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.

 

Regards

Marc

Add the possibility to enable or disable the indexing for a string at the entry of any loop.

The result would be only one char by one char, and would be really usefull !

 

Of course, the same possibility at the exit would create ("build") the string from a char or a string...

String in Char.PNG

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:

 

  1. Performance (I think it will make a major difference if the Picture Control would use OpenGL Hardware acceleration for instance).
  2. Support for alpha transparency.
  3. 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): 

 NativeLoopWait.png
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).

By default, the mouse scroll wheel scrolls the block diagram or front panel vertically, CTRL+SCROLL scrolls through cases/events/sequences and adding the SHIFT modifer to either accelerates the scroll. In order to scroll horizontally, however, the mouse has to be hovering over the horizontal scrollbar. Because of the predominant left-to-right, top-to-bottom style of diagram organization, it would be excellent to have a more accessible way to scroll horizontally.

 

I haven't found anywhere ALT+SCROLL is used - I think horizontal scrolling is a good candidate to fill that spot.

 

 

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.

 PlusAndMinus.png

The venerable Array Size function should just resize itself for the number of dimensions on the input array and have each dimension's size emitted with a separate scalar output.

Having the possibility to hide a pane at run time. For example if you want to hide a Button Palette, a status bar, Tree View or helper pane as specified in this snapshot:

 

 HidePane

Message Edited by Support on 06-02-2009 12:35 PM

Dany (below) requested support for alpha channel in picture control (I strongly agree with that). I also want support for drawing antialiased object (line, rectangle, circle, arc, ...).

Additionally, improve the performance of the picture control rendering will be greatly appreciated.

 

PJM

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.

Add support to transparency in picture control. When you load a PNG file to the picture control consider the Alpha Channel instead of a threshold.

A pop-up that appears when a user hovers over a buffer allocation dot would be very useful.

 

Data to display:

1) size of allocation in bytes

2) expected longevity (freed when vi quits vs. USR)

3) frequency of allocation (once at first run, each loop, etc.)

 

I know some of the data can only be a best guess but whatever additional data we can get

will be an improvement, especially when dealing with large data sets.

 

Thanks.

 

Matt

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:

 

 

Resizing action                      example of tip strip


 

Resize a 1D array:                  [5 elements visible]

Resize a 2D array:                  [6 rows x 5 columns]

Resize "built array" node:          [7 inputs]

Resize "index array" node:          [5 outputs] 

Resize "initialize array" node:     [3 dimensions]

Resize "replace array subset" node: [8 elements/subarrays]

Resize "compound arithmetic" node:  [4 inputs]

Resize a graph:                     [Overall size: 400x600, plot area: 380x500]

...

...

 

It should of course apply equally for front panel and diagram objects. For example the suggestion for the arrays would apply to an array control, array indicator, or array diagram constants. 

 

Of course there are many more possible objects, each with it's on set of useful size parameters. This is just a small collection. Please go over the palettes and make other suggestions!

 

 

Message Edited by Support on 06-02-2009 12:36 PM