LabVIEW Idea Exchange

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

It is not obvious that a NaN numeric constant can be created by simply typing "NaN" as value. What we see are weird constructs, e.g. "zero divided by zero" or "square root of -1" to generate a NaN on the diagram.

 

I suggest to add a NaN diagram constant to the numeric palette to make it more obvious.

 

 

(This is just a quick draft. Of course it should be matched in color and design to the other constants)

                                      se tappe la tête.gif    original5.png   fou_2.gif

                                                                                    fou-5.giffou-5.gif

 

                                                                                    but ...

 

 

                                                         pouce_levé.giforiginal6.pngpouce_levé.gif

 

                   same problem for all functions from the Exponential Functions Palette

 

                   Bench_1.png

 

                                        much more clear, readable and explicit

 


 


Large string constants, like to one shown below, can really get in the way. I would like to double-click the border and have it collapse, like the LV 2010 Cluster now does. Putting large string constants in a VI, or rolling them up, are some work-arounds, but this would be easier...

 

Collapse Text.jpg

 

                                 Double-Click the "text" icon to reverse.

How many times have you found yourself entering items in an array, typing merrily along, only to have to switch back to a mouse to click on the next element and type it it.  I suggest that Alt-Enter complete the current entry and move to the next array element.

 

This idea proposed using the Tab key, which collides with manual tool changes.  Shift-Enter was also proposed, but it collides with the ability to move to a new line in strings and to add another element to a enum/ring.

 

I propose using Alt-Enter to advance to the next array element:

AltEnter.png

Title says it all. Have a slider or pull-down that increases or decreases the highlight execute rate.

I could be easier to insert or delete element from array by only select and hit Insert or Delete on keyboard.

 

Insead of this:

 

DeleteFromArrayOld.png

 

Select like this:

 

DeleteFromArrayNew.png

 

 

More often than not, one location doesn't work for both. Here's an idea:

 

label_loc.JPG

 

When an array leaves a loop with indexing enabled, you get an array which has one more dimension, but quite often you want to concatenate the data to an array with the same number of dimensions.

 

If the subarrays have the same length, you can use reshape array, but usually they don't and you need to do something like below.

 

It would be very useful if output tunnels for arrays had an "Enable Concatenate Indexing" option as well, as depicted below, which would do this.

 

 Concat Indexing.PNG

 

The current boolean diagram constant is potentially confusing and too elaborate.

 

Confusing, because it almost looks like a toggle switch, so the new user might click on the right half, expecing an unconditional FALSE. However, there are no active areas, and an inversion of the current value occurs no matter where we click.

 

Too elaborate. All we need to see is the current value! Why do we need to see the "other" value greyed out??? We can guess that by simple elimination. 😉 There is too much redundant information, wasting twice as much diagram space than actually needed to display relevant information. The current design also makes e.g. 2D boolean diagram constant very confusing. Have a look at the image. Can you immediately tell that the 2D array on the left is only true on the diagonal? (I did not think so!). Now look at the suggestion on the right. Ahh... much better! 😄

 

 Suggestion:

The boolean diagram constant should be smaller, simpler, and cleaner.

The image shows the current design on the left and the suggested design on the right.

 

 

What a difference in clarity and economy!!

 

Message Edited by altenbach on 07-03-2009 02:39 PM
I would love to be able to draw a box over a bit of code on the block diaghram and be able to highlight execution just for what's in the box. The rest of the code should execute at full speed. This frequently becomes an issue when you are trying to track down a bug in a big program and you've got to wait for ages to get to the bit your interested in.

The State Diagram Editor was a very cool tool and lots of LabVIEW users (not only beginners, far from!) are missing it!

 

And no, the state chart module is not a replacement for the State Diagram Editor!

 

Discussion here.

 

Image borowed from Ben

I really like having two different default locations for my terminal labels.  What I do not like so much is that I still end up dragging a lot of labels around after changing a control to an indicator or indicator to control.  I would like it if the label location was automatically moved to the default position when the direction of a terminal is changed. 

 

You could get fancy and only move it if it is currently in the default location, I'd prefer it to always be moved.  And I am not interested in the Quick Drop shortcut here.  I do not want a quick way to clean up the mess I do not want the mess made in the first place.

 

Move Labels.png

It should be nice to limit the action of Ctrl-B to a selected part of the block diagram.

 

For the moment the Ctrl-B removes all brocken wires in the complete VI.

 

Sometime when you have a case structure with multiple cases ... and when you have multiple brocken wires in many cases ...It is usefull to keep non visible broken wires...

The broken arrow (list of pending errors) will then help you to find all locations to modify. 

 

SelectiveCtrlD.PNG

I've had enough!  Your code does not have to look like this:

all your paths.png

 

Or this:

even worse.png

 

You don't have to wire a string into Build Path's second input!  It can take a relative path just fine!  This is particularly helpful when building relative paths that involve climbing a directory structure.  But it's also useful for building hard-coded folder paths, or even just specifying a file name:

 

everything works.png

 

 

I've seen code that looks like the first two images way too often, so I propose the following:

 

  • Change the name of the second input of the Build Path function to 'relative path or name'.
  • Change the default data type of this input (i.e. what it looks like when unwired) to path instead of string.

The function will still work fine with string inputs (so existing code is fine), but this approach encourages developers to actually use the path data type when working with paths. You should kudo this idea if you have ever (1) written code that looks like the first two images, (2) needed to explain to someone that they can wire a path into Build Path's second input, or (3) gotten burned by multi-platform issues when somebody typed path separators into a string wired into Build Path.

I just ran into a situation today where I had a case structure with approximately 64 frames in it, 48 of which I wanted to remove.

 

The method of right-click the selector, select "Remove Case" (This step is right beside the "Insert Case" which is frustrating), repeat 48 times while the mouse is wandering all over the screen between the case selector and the menu selection..... cue carpal tunnel problems.

 

I really wished I could just either use the "delete" and "insert" buttons to mimic the appropriate menu selections

-OR-

Be able to select multiple cases from the "Rearrange cases" window and select "Delete".

Auto-indexing of arrays in for and while loops are a nice luxury in LabView.  One option that could save much time would be a menu option to turn on conditional indexing, this would expose a boolean terminal under the auto-index icon to select if the current itteration should add the itteration to the array or skip it.  From an execution standpoint there would only be a minor performance hit (could still preallocate max array size on for loops and automatically return used subset).  This could also work for autoindexed in but would have less use that the autoindeded out case.  I know I have built many conditional arrays inside of a for loop and it requires a case selection and a build array making the code less readable and requires time and thought.  It can also be less efficient than a compiler can do.

 

See the example below which would run a for loop and only build array of < 0.1

 

Conditional autoindex.jpg

NI send us the NI Developer Suite each year on DVDs all packed in a nice little NI branded dvd carry case. We are on the SSP suscription and we receive 3/years, which means I have a whole stack of them.

 

I suggest that NI start shipping USB keys instead. USB has several advantages:

 

  • USBs are smaller
  • USBs are more usable on devices without DVD player
  • Installing with one large USB means no more DVD swapping. I can go to lunch while NI installs/updates without having to change the DVD every couple of minutes.
  • USBs are reusable: when you get a new version on LabVIEW on a new USB, you can use the old one for regular usage. This also means less waste, since the USB keys are still in use after a new version ships, but the DVDs are useless.

 

Ship developer suite on NI USB keys

I think it would be nice if LabVIEW was smart enough to know that when I drop a For Loop around scalar inputs it doesn't auto-index output tunnels - but rather uses Shift Registers - for matching inputs and outputs.

The common use case for this is with the Error input/output - it annoys me how it becomes an Array output.

 

As it is already wired, inline and not broken, dropping a For Loop around it should not break my code! 

 

Reference or Class inputs are other use case too - I want to pass the same thing around not create an Array

Shift registers are better than non-auto-indexed tunnels (other option) as they protect the inputs on zero iterations.

 

21826iFF181EE2E7ECE408

 

This would remove one step required for most use cases, speeding up my development experience.

There should be an easy way to replace a control/indicator/constants of a certain type to an array of that same type, and vice-versa.

 

changetoarray.jpg

Message Edited by David_L on 12-04-2009 02:06 PM

Hi,

 

There are numerous ideas floating around about where the color box constant and control should be located in the palettes. How about if there wasn't a distinction between a color box and its numeric representation? Like the "View As Icon" option on terminals and clusters, I suggest a "View As Color Box" on numeric constants and controls/indicators:

 

ViewAsColorBox.png 

 

I'm undecided on if this options should be available for all numeric data types, integers only, or U32 only, and what should happen to the Representation options when the numeric is a color box. I see at least these options (ordered after my preference - I prefer 1) the most):

 

1) The "View As Color Box" option is available for all numeric data types, but when selected the data type changes into U32. If you change Representation to anything else but U32, the "View As Color Box" option is automatically deselected.

 

2) The "View As Color Box" option is available only when the numeric is U32.

 

3) The "View As Color Box" option is available for all numeric data types, and coercion happens between the selected "color value" (U32) and the true Representation of the numeric.

 

Several ideas would be fixed by this, for instance this and this.

 

Cheers,

Steen