LabVIEW Idea Exchange

Right now, if you happen to use the right colors, LabVIEW will change the text color on a Boolean.  But, if you don't pick the right colors, LabVIEW keeps a single text color.

This would probably be fine IF LabVIEW allowed you to have multiple text colors, but you can only choose one:

But, as you can see, LV only supports one text color.  I propose that LV support two text colors (ON and OFF).  Obviously LabVIEW has the ability to change the color already since it will do it in the right circumstances, but it would be nice if LV gave us control over it.

In my use case at the moment, I am trying to make a custom illuminated button which the text on the button should be grey went off, and yellow when on.

Current it is very hard to reliably manipulate decorations using VI server.

LabVIEW need to be able to create explicit decoration references (like it is possible to do on other objects through right click Create>>Reference).

Note: Thanks to TonP for the idea.

Some very useful properties for UI manipulation on graphs and charts do not exist. This makes it impossible to make very dynamic UI's with variable number of plots or dynamic resizing in panels.

It is possible to set Legend.number of plots and Legend position. It is not possible to set:

Graph palette, scale legend or cursor legend position. This makes resizing graphs very limiting.   

Further, it is possible to programmatically create a custom legend.  However it is not possible with cursors because there is no property available to get the current cursor values. Please can we have cursor.values[] and cursor.legend.number of rows

Currently if you flush an event queue that data is lost. Flushing and destroying and event queue should have the same interface as flushing/destroying a normal queue. Return the Data! I want the option to batch process the events, The code below would have to handle 1000 separate events to get the data out.

Idea
Flush Event Queue.vi should return remaining event data.
Destroy User Event.vi should return any unhandled events.

It would be useful to have a node that could be fed any wire and return the size (in bytes) of the data on that wire. In other words, the node would return the number of bytes that the wire occupies in memory.

For example, the node would return a value of:

• 1 byte when fed a U8 wire
• 2 bytes when fed a U16
• 4 bytes when fed a I32
• 8 bytes when fed a DBL
• 800 bytes when fed a 1D array that contains 100 DBL elements
• 9 bytes when fed a cluster that contains a DBL and a U8
• 9 bytes when fed an object that contains a DBL and a U8
• 18 bytes when fed an object that contains two other objects that occupy 9 bytes each
• and so on

Notes

• The node would would enhance LabVIEW programmers' ability to monitor and audit memory usage.
• The node may serve as an additional tool to detect memory leaks (by repeatedly calling the VI on the same wire and checking whether the size is going up).
• The node would simply be interesting to programmers interested in performance and would enable programmers to learn more about LabVIEW internals.
• The node would be useful especially to query the size of complex data structures, such as objects that contains other objects that themselves contain objects, or clusters that contain arrays, or arrays that contain clusters, or objects that contain DVRs.
• I would be happy if the node had a second input named "Mode" (or similar). This input may be a typedef enum with items named "Shallow Measurement" and "Deep Measurement" (or similar). This input could be required, recommended, or optional.
  • When "Shallow Measurement" mode is selected, the node would return the size of all the by-value data fields in the main input wire, but would not add up the size of data referenced by DVRs or other references. For example, a wire that contains a cluster that contains a DBL, a U8, and a DVR would return perhaps 13 bytes (8 + 1 + presumably 4 bytes for the DVR reference itself). It would not add to the result the size of the data referenced by the DVR.
  • When "Deep Measurement" is selected, the node would recursively scan all data structures, including DVRs and other references.
• In both "Shallow Measurement" and "Deep Measurement" modes there should be no limit to the scanning depth. In other words, if a cluster contains a cluster that contains a cluster and so on, they should all be measured regardless of the nesting depth. Similarly, if "Deep Measurement" is selected, and a DVR contains a DVR that contains a DVR and so on, the data behind all these DVRs should be added to the total.
• When in "Deep Measurement" mode and fed a Queue reference wire, the node could perhaps return the size of all the data in the queue. In other words, the size of all the elements present in the queue.
• Perhaps the LabVIEW compiler already uses a "Get Data Size" function internally? If such a function already exists, perhaps it would be relatively straight forward to expose it as a node in the palettes?
• Perhaps the best location for this node would be in the Programming >> Application Control >> Memory Control palette.

Thanks!

The web format wars are over, and the plug-ins have lost.  Microsoft has relented and will support HTML5 and SVG in IE9, and has admitted that Silverlight's role will change to that of a Windows phone development platform.  Silverlight support on iPhone/iPad/Andoid/Chrome OS will likely never be fully formed, and will wither on the vine. 

New javascript/ecmascript engines that are much faster, and make use of multicore environments have arrived and work well.  The addiition of WebSockets means your browser can now open a tcp/ip socket.  I have done this, as I am sure others have, as well.  Drop an old-fashioned tcp/ip listener into your diagram, return the WebSocket handshake, and presto: you can now stream data directly to/from your browser.  WebSockets provides an "onmessage" event handler function which you can define.  Combine this with the SVG DOM, and you can transform SVG elements until your heart is content.  Two-way streaming of data between your browser and plain-old tcp/ip?  Goodbye web services, we knew you well. Good riddance, plugins.

I have built my own SVG UI objects using Inkscape (free), and wrote a script (notepad/Inkscape script editor, also free) to handle WebSockets communication without a gateway.  I have a simple LV class built on the TCP/IP functions that will stream data to/from a browser which is pointing to an SVG "webpanel" that I also built using Inkscape.  So far I have a simple waveform graph, buttons, LED's, progress bars, etc.  I have tested my Inkscape webpanels in Firefox 4.0 Beta and Google Chrome 9 and it works like a champ, and is very fast.  The old-fashioned LV webserver will serve up SVG files with the addition of a mime type. 

An alternative to SVG is the HTML5 <canvas> tag, which allows the rendering of graphics drawn using java/ecma script.  There is a free-for-personal-use script library called RGraph Library that you can download with lots of example code.  Here is RGraph/LabVIEW in action in Chrome 9:

So what is my idea?  

0. Ditch Silverlight.

1. Convert all of the nice-looking UI panel objects in the Web UI Builder from Microsoft XAML to SVG and distribute them with the  LabVIEW professional development license.  I am programmer first, and I admit my web panel objects don't look too good.

2. Design a script library for handling WebSockets communcation (or add native support for WebSockets to the Shared Variable Engine) and manipulating/updating the SVG UI objects from streamed WebSockets data.  Make this library open source.

3. Create a standard open protocol for streaming LabVIEW data that sits on top of WebSockets and is free and open.

4. Publish documentation for the SVG UI elements so users and thrid parties can create new UI objects.  Make use of the creativity of the community at large!

5. Modernize the Web Publishing Tool so that it will optionally output an HTML5 and/or SVG document that accepts streaming I/O from WebSockets.  The user could choose from compatible SVG elements to use in place of front panel elements on the VI being published.

6. Create a Web UI SVG element exchange for registered NI users to upload/download elements for free.

7.  Work toward the long term goal of adding SVG Import/Export to the control editor (with better editing tools), or make the CTL format of custom controls SVG/XML.

The concept of fluent interfaces using method chaining applied to a LabVIEW block diagram would be awesome!

When calling .NET libraries from LabVIEW, block diagrams explode horizontally - the aspect ratio of the diagram can easily push 5:1 or worse (it's 10:1 in the example below). Some Method Chaining syntactical sugar would yield a more space-efficient-and-readable 4:3 to 16:9 or so.

Property Chaining is already well-established in LabVIEW - let's get us some Method Chaining!

See the first comment for footnotes...

I really like the new arrow feature with block diagram comments.  But in many cases, I have a comment that applies to more than one BD object.  So, I would like the ability to link my comment to multiple objects instead of just one.

This would allow me to turn this:

into this:

Thanks!

-John

Today, the enum data type in LabVIEW only allows having sequential numeric values (0, 1, 2, 3, etc.).

It would be very useful to have sparse enums, meaning enums which can have custom numeric values assigned to their strings, just like you can do today with rings.

If you want an example where this will be useful, think of error codes - this would allow you to use an enum on the diagram to select the error, or in a case structure.

I tend to use malleable VIs more often than half of the items in the "New" context menu list when you right-click within a project, however, it's not an option:

Instead, I either need to:

- Create a new VI and then make several property modifications, and save it as a ".vim".

- Create it through the file menu and then remember that I need to move it to the appropriate place in my project, because it gets created at the top-level.

Why not include this in the context menu?  (Bonus points if Polymorphic VIs get added too!)