LabVIEW Idea Exchange

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

 

 

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.

 

 

 

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

 

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.

 

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. 

 

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

 

Or this:

 

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:

 

 

 

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.