LabVIEW Idea Exchange

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

As soon as we have more complicated data structures (e.g. clusters of arrays), a large portion of the FP real estate is wasted taken up by borders, frames and trims, etc.

 

We need a palette full of "Amish" 😉 controls, indicators, and containers that eliminate all that extra baggage. We have a few controls already in the classic palette, but this needs to be expanded to include all types of controls, including graphs, containers, etc.

 

A flat control consists of a plain square and some text (numerical value, string, ring, boolean text, etc). A flat container is a simple borderless container.  A flat graph is a simple line drawing that would look great on a b&w printer. A flat picture ring looks like the image alone.

 

They have a single area color and a single pixel outline, if both have the same color, the outline does not show. They can also be made transparent, of course. If we look at them in the control editor, there are only very few parts.

 

Now, why would that be useful?

 

Let's have a look a the data structure in the image. There is way too much fluff, distracting from the actual data. If we had flat objects, the same could look as the "table" below. Note that this is now the actual array of clusters, no formatting involved! It is fully operational, e.g. I can pick another enum value, uncheck the boolean, or enter data as in the cluster above.

 

Many years ago in LabVIEW 4, I actually made a borderless cluster container in the control editor and it looked fine, but it was difficult to use because it was nearly impossible the grab the right thing with the mouse at edit time.

 

The main problem of cours is that the object edges completely overlap, making targeted seletion with the mouse impossible. (For example the upper right corner pixel is the corner of an array, a cluster, another array, and an element at the same time.)

 

So what we need is a layer selection tool that allows us to pick what we want (similar to tools in graphics editing software). It could look similar to the context help shown in the picture with selection boxes for each line. Picking an object would show the relevant handles so we can intereact with the desired object. Another possibility would be to hover over the corner and hit a certain key to rotate trough all near elements until the right element is selected, showing it's resize handles. I am sure there are other solutions.

 

As a welcome side effect, redrawing such a FP is relatively cheap.

 

Message Edited by altenbach on 06-03-2009 09:20 AM
Message Edited by altenbach on 06-03-2009 09:20 AM

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.

 

 

Block diagram string constants have a useful feature "Size to text" which is accessible through the standard right click menu.  One way in which this is useful is to ensure that information in an array of constants is not hidden: Right click on an element of a string-constant array and select "Size to text" and it will expand to show the full length of all the strings it contains.

 

What's needed is an equivalent for numerics (including rings and enums).  When dropped singly, these constants expand and shrink around their contents.  But if you drop a numeric constant on an array constant, it takes the size of the numeric and can only be expanded manually.  If you then enter a constant that is longer, only the first part will be shown, and there is no indication that the values are truncated.  (see image)

 

I think that arrays of numeric constants should resize to show everything entered, automatically.

 

16985i3AA6C5F1591D73F6

Make possible that Boolean function accept error cluster as input as this example:

 

StopOnError.png     StopOnErrorCast.png

I don't know how many times I've added a case statement post-programming, but I do know that there isn't an easy way to make a tunnel the case selector.  Usually I delete the tunnel and then drag the case selector down and then rewire, there should be an easier way.  For loops and while loops have an easy way to index/unindex or replace with shift register, why can't a case statement be the same?

Case2.PNG 

Case3.PNG 

GUIProgrammerDream.png

 

...the ability to bulk-create References, Local Variables, Property Nodes...

Here's an enum with a lot of elements:
enum1.png

 

The enum has a built-in right-click menu to 'Select Item', but it's worthless... it does exactly the same thing as clicking on the enum directly:
enum2.png

I think we should replace the 'Select Item' right-click on enums and rings with a Quick Drop-like UI that lets you filter the enum/ring contents and select an item without having to scroll a giant list:
enum3.png

Current Situation

The current commenting practice in the BD is to place free floating comment number labels and write the comment in a text field as in the example below.

Current Code Commenting Practice.png

 

Disadvantages

- comment number labels do to stick to the code block. if the code number block is moved the comment has to be moved as well.

- no link between number and comment text block

 

This unsophisticated way of commenting LabView code lead to the lack of comments in general. Usually a new programmer can understand what happens, but not why a function is implemented like this.

 

 

Proposal

LabView provides the Advanced Code Commenting Functions.


InsertCommentBlock.png

 

CommentBlock.png

 

The comment block is more then just a text block. Basically it has a comment ID, the comment itself and a comment category.

By the context menu the following functions are provide:

  1. add comment
  2. delete comment
  3. move comment up
        The particular comment line is moved up in the comment block. The ID is decremented
  4. move comment down
         Opposite from 3.
  5. highlight function
         The function to which the comment ID sticks is highlighted.
  6. the comment category can be selected. (e.g.. Code Explanation, To Do, )

Adding Comments

Adding a comment in the comment block incorporates two steps (after selecting Add Comment from the context menu):

1. Sticking the automatically generated comment ID to a particular code block just by selecting the item the comment belongs to.

   This could be any type of code: wires, SubVIs, the whole Case, a particular Case, Sequences....

2. Writing the comment

 

 

 

Example of Block 1.png

 

If the mouse pointer is set over a comment ID the comment is shown like a tool tip and disappears as soon as the mouse is moved away.

 

Case.png

 

Advantages

  • Comment moves with function block if function is moved on the BD
  • Comment ID sticked on the BD item and ID on the comment block always match
  • generally more comments in a LabView programm through more simple way of commenting code

 

 

Resizing the front panel so it is correct when running the VI is still very tedious and can easily mess up during editing. The problem is even more severe for Xcontrols, because their runtime size is often very small so there is not even enough room to e.g. display all the tools in the tool bar during editing. Once the runtime size is correctly set, all it needs is a double-click on a terminal that has its FP item hidden outside the visible area and everything on the FP shifts and messes up.

 

We need three things:

  1. An "edit time" FP size that is "comfortably big" so we can see the entire toolbar and possibly also helper controls and even maybe some comment text intended for the programmer that are outside the operator area and only used for debugging and such.
  2. A "run time" FP size that matches exactly what the operator sees during running.
  3. A special decoration or other visual cue during editing that indicates the FP area that will be visible at runtime.

 We already have the crosshair in the upper left corner when showing the grid, so that could be defined as the upper left corner at runtime by default. All we need is define the upper left and lower right corner and the runtime FP area is uniquely defined. As a visual cue, everything outside the runtime area could be a shade darker or tinted differently than normal to indicate that fact. Running the VI would snap the FP boundaries to the bright area.

 

Then we also need handles to move any of the boundaries at single pixel increments. A control that scales with the front panel would simply scale to the bright area instead. Of course a legacy mode for older VIs that did not have this feature during their creation needs also to be supported.

 

The example image shows a reddish transparent area (just to throw out another idea, maybe a slightly darker grey would be better). This is one of my own subVIs that demonstrates the problem at hand. At runtime, only the progress bar should be visible, while at edit time, I want to see all controls, because I might need them e.g. to wire the connectors. It is not easy to switch between the two sizes.

 

(Of course we can currently program around all that by setting windows parameters via property nodes, but it is ugly, inefficient, and tedious.)

 

 

 

I often make small For Loops using Auto-Indexing, and only occasionally do I use either the Iteration Terminal or Count Terminal. My current practice is to tuck the Iteration Terminal under the Count Terminal just to get it out of the way, shown below. I propose that these two terminals can be shown or hidden (circled in green), just like the Conditional Terminal.

 

CurrentForLoop.png

 

Here's an example of the new lower-profile For Loop with the unnecessary terminals hidden:

 

LowProfileForLoop.png

My idea is simple: Put the connector pane on the front panel next to the VI icon.

 

Why: Right clicking to show the conpane means extra clicks that would not be necessary if it was always there.  It would also be solve the problem of saving the VI with the connector pane hiding the VI icon.

 


 before_alwaysshowconpane.pngafter_alwaysshowconpane.png

When creating a subVI from a selection, LabVIEW should do two things:

  1. Use the user's default connector pane pattern instead of selecting one matching the number of inputs and outputs. This will make easier wiring and allow users to add more IO later.
  2. If the user is using a "standard" pattern (e.g. 4-2-2-4), LabVIEW should try placing the error clusters at the bottom corners and objects or references at the top corners.

It should also try to make the FP of the subVI cleaner, but that's another matter.

It could be nice to have a context help on coercion dots to see what is the expected type of the data that is supposed to be wired to. This way you can rapidly determine what kind of conversion to use to avoid the coercion dots.

 

ContextCoercionDots.png

 

When you connect the error wire to a case structure selector, you get two cases for error and no error. I think you should be able to add in cases for specific error numbers so you can handle specific errors differently. You could do this currently, but you would have to unbundle the error and use the error code.

 

Numbered error case.png

Support unicode officially for all FP indicators and controls! Captions and string indicators can be "coaxed" into showing Unicode characters (among other controls/indicators), but trees and listboxes (among most others) cannot show Unicode.

 

Of course, this may have a small audience, but anyone who has developed a UI meant to be distributed to half a dozen language-speakers has probably fought the same Unicode battles and figured out the display "hacks" that we have.

 

Unicode!.png

(As already hinted here, I think this deserves a seperate idea).

 

Property nodes have many items that accept color data (cursor color, plot color, bg color, etc). When right-clicking these and "create constant|control|indicator", we get a generic U32 type. Instead, we want a colorbox! Even more complex color structures, e.g. (colors[4] of a boolean) should have colorboxes as the innermost elements.

 

In all instances I have ever used these properties, I ended up replacing the U32 with colorboxes for code readability and simplicity.

 

Idea: when creating an input or output (constant, control, indicator) on any color property, we should get a colorbox (control, constant, indicator) instead of a plain U32 numeric. 

 

color.pngcolor.better.png

For example, when you probe an array, the "Probe Display" only shows the first value of the array. A lot of times, I would like to see a few elements in the array, somewhat like resizing arrays on the front panel. This would be useful for strings, numerics, and clusters as well.

 

Current:

untitled.PNG

 

Suggested:

Suggested.png

It'd be usefull for develloper and especially application user to improve graph control by adding to Graph direct access to Plot Visible property on plot legend.

 

For the time being, you have to go to color and choose transparent or to change visible property dynamically.

 

I propose control like that ... but we could find another idea to access Visible property.

All plot visible Selected plots visible

 

 

It would be nice if you could change a selected font style by using the standard windows (MS office) shortcuts, such as CTRL-B for bold and CTRL-U for underline.  This would save many mouse clicks.

 

I realize that many people don't use Windows, so maybe it could be customized in the .ini file or would be dependent on what OS your are running.

 

font styles.PNG

It would be nice if NI added "Mouse Scroll" (and its counterpart filter event) to the supported events. Today, you can do this by using the mouse input VIs in a separate loop and polling, but that's not a very nice solution.