LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

View All (3)

View All (2)

The idea is simple: if the label ends in a number (i.e. consecutive string of numeric characters), increment that number:

It seems like it only works if there is a space character. If there is a good reason for doing it that way, help me understand what it is.

I linked some similar ideas below. I like these discussions for the most part, but they tend to have broader scopes than what I'm suggesting.

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Smart-er-automatic-label-names-on-copy/idi-p/1873663

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Auto-increment-number-in-middle-of-control-name/idi-p/977710

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Don-t-skip-quot-1-quot-during-automatic-naming-of-copies/idi-p/977300#A2089

View All (2)

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.

View All (2)

Add sparse enums to LabVIEW

View All (2)

View All (5)

Add Control Anchors to Labview

.net and many other languages have an intuitive and simple way to allow you to define how a window behaves when you resize it: anchors. Anchors allow you to define the distance between an edge of a child control and the edge of a parent control regardless of the size of the window. The size of the control itself stays constent unless it violates the rules of the defined anchors in which case it changes sizes to meet those rules. For example a front panel with the following anchors:

Would be resized into:

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.

View All (1)

View All (3)

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...

View All (2)

View All (3)

I sometimes delete controls from the BD and realise some time (from milliseconds to minutes) that I have some broken local variables.

I get greeted by the hugely informative imagery as shown below:

Yeah, good luck realising what exactly you deleted by mistake. No name, no way of finding out what the local PREVIOUSLY linked to.

I suggest retaining at least the name of the Control / Indicator the local was linked to so that the poor programmer (me) has some fighting change of undoing the error. Bear in mind there could be many changes made to a VI before this kind of thing is notices so a simply "undo" fix could end up being VERY awkward indeed.

An example of how this could look:

Here I at least know WHAT I have deleted by mistake.

View All (1)

Install LabVIEW API ONLY for NI Drivers

Problem

Many times, the bulk of LabVIEW development happens on computers that will never interface with hardware. A dozen engineers may be collaborating on code that will ultimately run on a dedicated machine somewhere, that is connected. Yet, as things currently are, I have to install more than I need on my development machine to get access to API VIs. If I am working on my laptop on an application with DAQ, RF, Spectrum analyzer, etc. components, I have to choose to either download and install all of that, or deal with missing VIs and broken arrows. This seems needless, since my particular machine will never actually interface with the hardware.

Idea

I would like to have the option to install only the LabVIEW VIs and ignore the driver itself. In many, if not most cases, the LabVIEW API could be independent of driver version. It could install very quickly, since it would just be a set of essentially no-op VIs. I don't care that the VIs would do nothing. They would just be placeholders for my development purposes. This would allow me to have full API access to develop my code without having to carry around large driver installations that I will never actually use.

View All (4)

display captions in arrays

I am probably not alone in my trepidation in using the Block Diagram Cleanup tool, but I can not help but recognize its power to be a tremendous help. We already have tools (Grids, Align and Distribute, Ctrl-T QD shortcut, etc.) to get Nodes and terminals positioned nicely. Even with this idea in Beta, wiring can still be a tedious chore. The BDCT does a reasonable job routing wires, but also moves things around including control/indicator labels, and is often unsatisfying.

What I want is to be able to lay out the BD, wire things while only worrying about beginning and end, and then have the BDCT only adjust the wire routing.

Despite numerous RCF shortcuts and new behavior in LV10, this is not the same as cleaning wires. The solution is not to methodically select only wires and Ctrl+U. The reason: the process should be a global optimization, not a serial process where each wire route is chosen based on the current state of the BD. The BDCT uses a global optimization, 'Cleaning wires' does not. What I want is the optimization of the BDCT limited to only wires, leave my nodes and terminals and labels alone!

For example see the following:

View All (1)

The help page, that is supposed to provide a starting point for the developers on creating readable, high quality code in LabVIEW seems to be unchanged for quite some time: LabVIEW Style Checklist - NI.

At different workplaces (including NI) and different teams I have seen different implementations of such guides, many of which included extra "rules".

One such example is the file naming convention:

Using spaces for separating words.
Using Libraries to namespace VIs instead of including the noun in every related VI.

These are the most prominent examples I can come up with from the top of my head, but I'm sure that there are more.

I'm curious if an updated version exists somewhere that could be used to replace the above refenced help page?

If there is not, then I think could we collect some ideas here for updating this document.

View All (2)

Sometimes you want your front panel fixed to a particular size. Sometimes you also want to access the “Tools,” “Window,” or “Help” menus.

When you have intentionally re-sized your front panel to a specific (small) size, it’s a pain to have to resize the window or switch to a different window every time you want to access something under “Tools” or any of the other menus that are not visible.

(Sure, I could switch to the block diagram and get to the menus from there. But if I can’t remember the keyboard shortcut to open the block diagram, I have to resize the window to get to the “Window” menu to open the block diagram.)

For example, when you make an XControl, you want to re-size the facade to fit the controls that you put on it. And then you want to keep it at that size. On the built-in Simple Dual-Mode Thermometer example, you can’t see any of the menus past “Edit” on the Facade without re-sizing the XControl.

It would be nice if an arrow or something appeared on the menu bar when the window is sized too small that I could then click on and expand to get to the menus that are not visible.

View All (2)

Allow editing of map and set constants

Similar to how array and cluster constants on the block diagram can be edited, it would be useful to be able to edit map and set constants on the block diagram.

For example:

In the map constant above, the developer can scroll through and see all of the key value pairs in the map (plus an empty element at the end of the map).

It would be useful to also be able to edit the key-value pairs in the map (and add more key-value pairs to the map by changing the empty element at the end of the map).

Control Reference Improvement

The current implementation of Control References on the Block Diagram could be improved. This Idea was first conceived over a year ago in a discussion on Smaller Static Refs, in the comments here.

Consider the following advantages:

It's generally bad style to have Ctl Refs with hidden labels. New implementation always demonstrates the label to comply with inherent self-documentation of G (just like a Local)
Smaller footprint combined with better visual distinction between Ctl Refs doubly improves information density
In general, the Control Class does not need to be shown at all times on the BD. Rather, it could be shown in Context Help (currently, CH is not useful when hovering over Controls Refs, but this is another topic), or determined by browsing Properties/Methods.
Eliminates the undesirable ability to rename/delete a Control Ref Label such that it no longer matches the Terminal Label.
Creates a better distinction between a Control Ref and a Control Class Constant (NULL Ref). The color of the Static Refs denote a "live link" with a control, while the muted tones of a Class Constant indicate no such link (NULL)
Complements the new LV2010 Local Variable upgrade (see image), yet remains distinct by having a different glyph, different background colors, and no directionality arrow

In summary, a Control Reference revamp could reduce the footprint, increase readability, and prevent obfuscation that decouples the Static Control Ref from the Control.

View All (6)

LabVIEW Idea Exchange

Change CLUSTER SIZE to a Wired Input

Control all the 4 [6] colors of Booleans from their Properties page

Increment label ending in numeral when copying control

Support Multiple Boolean Text Colors

Add sparse enums to LabVIEW

Add Explicit Decoration References to LabVIEW

Add Control Anchors to Labview

Support for HTML5 and SVG in Web Publishing Tool

Allow Web Based Help for lvclass, lvlib, XControl ,etc.

Fluent Interfaces with Method Chaining for Objects (especially .NET!)

Consistently provide Invoke Node Method / Property Node Property in error messages

Allow comments to point to more than one object

Visual help in fixing broken local variable linkage

Install LabVIEW API ONLY for NI Drivers

display captions in arrays

BD Cleanup Option - Optimal Wire Routing Only

Overhaul the LabVIEW Style Checklist inside LabVIEW help

Allow access to menus on the menu bar without re-sizing the front panel window

Allow editing of map and set constants

Control Reference Improvement