LabVIEW Idea Exchange

First of all, this idea only makes real sense, when using SINGLE ELEMENT QUEUES (SEQ)!

The idea is, that you dequeue an element of a SEQ and garantee, that the element is returned (enqueued) to the SEQ by using an In-Place structure (see picture).

This would make it impossible to "lose" the data, because of a programming error....

It has come up in discusssions that NI does not really cater to hobbyists. A cheap and functional version of LabVIEW is limited to the student edition, which is restricted to a small subset of potential users.

 From the  FAQ:

"The LabVIEW Student Edition is available to students, faculty, and staff for personal educational use only. It is not intended for research or institutional use."

As a suggested first step, I suggest to remove the academia restriction and mold it into a new product:

--- LabVIEW personal edition ---

Licensed as follows:

"The LabVIEW Personal Edition is for personal use only. It is not intended for commercial, research or institutional use."

 It would be available to anyone for noncommercial home use.

LabVIEW currently has the home use exemption that allows installing a copy at home. Unfortunately, if you lose your job, you not only lose your health insurance, but you also lose access to LabVIEW, thus hampering any self paced LabVIEW tinkering that possibly would improve future job prospects. I am sure many retired LabVIEW engineers would love some recreational LabVIEW use. They could be a great asset, because they will have more time helping out in the community and forums. They could even give guest presentations at user group meetings, for example.

The LabVIEW personal edition should include all modules of interest to the hobbyist, including application builder, embedded, FPGA, and robotics.  We should be able to distribute built applications as freeware. Support would be limited to community support.

Installing LabVIEW on every single private home computer in the world would cost NI exactly nothing (except for some sales of the current student edition which is about the price of a textbook, some internet bandwidth, and loss of the zero to two (?) multi-millionaires who actually bought the NI developer suite for themselves. ). 99.9% of users would never touch it, but that 0.1% could come up with great new application areas and would help spread the word on how great LabVIEW really is. Soon 0.2% would use it.

It should follow the "customer class limited" Freemium model, (as defined by Chris Anderson), i.e. limited to personal home use in this case.

The running applications should be clearly identified to prevent commercial use. The splash screen and "about" screen should prominently display the words LabVIEW and National Instruments and could even be used for NI advertising and product placements, for example.

I would like the ability to probe the loop iteration terminal ("i" in For and While Loops) without the need to wire it to something (indicator, edge of structure,...).

I can't count the number of times I've seen this dialog :

Of course I want to continue, that's why I right-clicked the structure and chose Remove [Structure]!  This dialog must be a holdover from pre-Undo days.  Do we pop-up a dialog when you select your whole diagram and press <Delete>?  What about when you press Ctrl-B?  These actions have the potential to remove just as much diagram content as Remove [Structure].

Please get rid of this dialog, and just let us Undo the operation if we need to, just like we do all the other potentially destructive diagram edit operations.

The default LabVIEW environment option should not show terminals as an icon. 

This idea came about from a discussion at http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Require-LabVIEW-R-amp-D-response-to-any-idea-over-N-ku...

The idea is to give LabVIEW users some say in which ideas are implemented. The key components of the idea are:

1) Set aside 5% of NI’s R&D staff to work on the “people’s choice” LabVIEW idea. That’s over 100 R&D staff, so a lot can be done.

2) Take LabVIEW ideas with kudos of 200 or more (there are 39 unimplemented ideas with 200 or more kudos).

3) Put together a poll of these 39 ideas and ask LabVIEW users to vote for their favourite.

4) Keep the poll open for 2 weeks and at the end of the period, take the idea with the most votes and implement it.

5) Once the idea is in beta, another "people's choice" poll is conducted and the process repeated. (Small ideas get implemented quickly, bigger ideas presumably are worth the wait.)

The 5% R&D staff, 200 kudos, etc figures can be played with to get the desired result.

I think we'll get more smiles on our faces from the 5% of R&D staff working on the "people's choice" project than we'll get from the 95% working on the "marketing's choice" projects.

It would be preety nice if all the VIs that can be indexed in any way (for example string and array operations) would accept "n" and "n-1" and such as input to denote that the user want the last element/character/etc. or the element before the last and so on.

What if I had this:

Then I wanted to insert something with similar terminals:

I'd end up with this:

But the Error terminals aren't wired! So maybe I should be able to select both wires:

Then Right Click » Insert Write Node:

Then I'd have this:

How easy would that be!?

Add new features, flexibility, and new controls to the Front Panel.  The only new controls I've seen were made by LabVIEW Customers, and although they were great, they were not resizeable without being distorted (bitmap).  I think it's time for NI to give more options and features for the Front Panel Controls.  I attached some suggestions.  They are there for example, so don't focus on the controls I've made, but the idea of improvements I am suggesting.  NI has done a great job on the Diagrams.  I should hope it's time NI improves the Front Panel.

I propose that Case Selectors should accept any type of reference, and the two cases generated are "Valid Ref" and "Invalid Ref". (This would be very similar to the current behavior of the Case Selector accepting errors with the two cases of "Error" and "No Error".)

The current behavior using "Not a Number/Path/Refnum" is very unintuitive. It requires the programmer to use Not Logic (i.e., do something if the reference is "not not valid").

I propose LabVIEW launch the browse dialog that Windows provides with each OS version instead of the current limited LabVIEW browse dialog on all versions of Windows.

Background:

The LabVIEW browse dialog looks like this regardless of the Windows OS version you're using. This is for any browse dialog from LabVIEW... the getting started window, the file menu, save as, path controls, everything:

This is OK and works fine for most things. However, it hasn't received the updates that the Windows OS has provided for browse dialogs in Windows Vista and Windows 7. Mainly... the left pane is very limited. If you look at Windows Vista's browse dialog:

You get a much more capable left pane including favorites. The top address bar is also more capable instead of just a dumb drop down box.

The same thing goes for Windows 7:

If you are like me and use lots of mapped drives and favorite locations... it is infuriating having to give up all your favorite locations when you use LabVIEW. You always end up pathing to the same places... but can't do anything about that because the LabVIEW browse dialog doesn't support the modern Windows browse features.

I propose LabVIEW launch the browse dialog that Windows provides with each OS version instead of the current limited LabVIEW browse dialog. This is possible somehow... as the screen shots I took for the Windows browse dialogs were from Firefox 7.0.1 on two different OSs (7 and Vista). So there must be some API call to invoke the Windows browse dialog.

 I propose a “Preserve Run-Time Type” primitive for Variants that is analogous to “Preserve Run-Time Class” for Objects.  Below I illustrate, using a system of messages that I'm working on.  Two message types carry either Variants or Objects (LVObject).  In each case I must convert to a specific type (data type or child class) in order to use the messages data.  For this I can use "Variant to Data" or "To More Specific Class", but I need to do the conversion outside my "Read Message" subVIs (top two examples below).

However, with Objects I can make a cleaner implementation (third example) where I use "Preserve Run-Time Class" to do the same thing inside the "Read" subVI.  I would like to be able to do the same thing with my Variants but I cannot (but I've faked what it would look like in the forth example).

The object subVI that uses Preserve Run-Time Class looks like this:

A subVI using “Preserve Run-Time Type” would look similar, just with Variants in place of Objects.

In addition to cleaner code, “Preserve Run-Time Type” would allow additional logic to be built into the Variant to type conversion.  For example, I like to use numerics with units in my messages, as a safety device against message sender and receiver using different units, or confusing what the message represents.  However, one can always convert a numeric with units to a numeric without units by using "Variant to Data" with a non-unit type input.  This defeats some of the safety (eg, sender could send "output" in Watts, but receiver thinks it's in Volts).  I would like to make a message type that performs unit consistency checks inside the "Read" subVI, throwing an error on any mismatch; a “Preserve Run-Time Type" would allow this.

What you get when you place a radio button group:

What you do 99.99% of the time:

HTML5 supports WebSockets which allows low-latency, two-way communication between browser and server.  There are various screen-sharing technologies in existence based on this, but integrating a similar server in LabVIEW would enable capabilities that could be accessed from any desktop or mobile browser, no configuration required on the client side.  The key to this feature is the ability to configure the server and enable sharing from within LabVIEW or from a VI (i.e. a LabVIEW-aware server).

An idea of what this could do:

• Remote control of LabVIEW development machine

• Selective sharing of windows, for instance allowing interaction with only LabVIEW windows.  The server application would have a mechanism for selecting which of the open windows to share.

• A view-only mode so users could check the status of a running application from anywhere, including their cell phone.

• A brat or Express VI that when dropped in a VI would automatically share the VI when run.
• Third-party toolkits and applications could build in sharing capability for their own app using the API.

This feature would be more powerful than Remote Panels in that:

• It would give access to the LabVIEW development environment in addition to running applications.
• No configuration or special software required on the client side, enabling multiple platforms including mobile.

Add a slider on the toolbar which would allow changing the zoom level on the diagram. This should also be controllable more easily (for example, by using shift + mouse wheel scroll).

Personally, I want this less for zooming out and more for zooming in. It's sometimes convenient to have a larger display of a specific area.

I know some people feel that a zoom is a terrible idea because it will encourage people to create huge diagrams. Personally, I doubt that (since you can't work on zoomed out code and zooming out and in repeatedly isn't that convenient), but I don't mind if people do that. It's their code (as long as I don't have to work on it later).

If people really insist, this can also be prevented by setting the maximum value of the slider to 1, so that people can't zoom out, but I doubt this would have any value.

The zoom should snap to 1 when you get near it and should center on the mouse cursor.

1. Allow for "Tabbed Browsing" of VI's to better manage windows.

2. Allow for the BD to be open independent of the FP.

3. Allow dockable palettes... dock to either the edge of the screen, or to the top bar (pictured below) of LabVIEW.

4. As a bonus, consider being able to open PDF's, txt's, and html's in tabs also for Help and documentation.

5. Finally, allow the project tree to be docked into the IDE.

Please, add your own IDE upgrade ideas in this discussion - illustrations will be especially helpful here. If it's a major enough idea, create a new idea!

Edit >> Create SubVI:  I almost never use this function... but it could be so nice!

Imagine being able to develop code on some diagram, check functionality in line, and quickly generate a subVI.  We're so close with "Create SubVI", but in 7+ years, I've never really used it.

Suggested Tweaks:

1) Use default connector pane (12 terminals)
2) If there are error clusters, wire them to the bottom terminals.
3) If there are error clusters, auto create a case structure and put the code in the No Error case.  Wire the error cluster through the Error case.
4) If there are in and out references (e.g. File In, File Out), wire these to the top terminals.
5) Run Clean Up Diagram.

I believe the main issue with this is what to do with the outputs from the subVI (since you won't be able to use them) and I can think of two options:

1. This option would be settable at edit time and would break the caller if you wire any of the outputs.

2. This option would be settable at run-time and you would get default data from the outputs and an error or warning from the error out terminal of the node if you wire any of the outputs.

When the Developer Suite DVD binder arrives, the first thing I do is find a black Sharpie, cross out the name (e.g. 2010) on the binder label, and write the version of the software it contains (e.g. 2009 SP1).

Rarely if ever do I care which year the DVD binder shipped to me -- all I care about is the version of the software (the most important being LabVIEW) it contains.

Now that LabVIEW and most other NI software products are on an annual release cycle and named according to the year and service pack, I would love it if the Dev Suite binders were named the same way.