LabVIEW Idea Exchange

Post an idea

A lot of times I generate 1D arrays in each iteration of a for loop. Rather than concatenating the arrays inside the for loop I use and indexed output tunnel which gives me a 2D array. Using the Reshape Array function this can be reshaped into a 1D array essentially concatenating the 1D arrays together.

My problem is that the "dimension size 0" input of the Reshape Array function is required. I suggest that if this input is not wired to simply interpret the n-dim array as a 1D array.

Interestingly enough in the context help for Reshape Array "dimension size 0" is not shown in bold so it should not be required.

I have become a huge fan of the compound arithmetic node, and there are a growing list of good ideas on this Idea Exchange that involve adding invert capability to more boolean inputs/outputs. Unfortunately, the circles used to show that an input/output is inverted are too small for my taste which makes them easily missed by the untrained eye. Filling the circles black is one possibility, but there is room between the terminals to at least double the size. With a more prominent indicator that a node is inverted, I will easily support adding invert capability anywhere it makes sense.

I know that most of the wildly popular ideas here involve making things smaller, hopefully with some of that reclaimed real estate we can make room for some slightly larger circles.

View All (2)

As we look at the Comparison Palette, there are three functions that offer negative logic, but fail to offer the positive logic alternative:

I commonly find myself placing a Boolean "not" right after these functions (e.g., if I want to know if there are elements in an array I must test if it is "not not empty", or if I want to know if a ref is valid I must test if it is "not not valid". Take a look at my other idea which illustrates not not logic.).

I have two proposed solutions: 1. offer a single function that has an "Invert?" option on the output, or 2. offer both the positive and negative logic primitives on the palette.

Message Edited by Laura F. on 11-16-2009 08:51 AM

View All (9)

View All (10)

View All (3)

There seem to me to be a couple of choke points in right-click access to VIs and functions. One is that I frequently need to use the same VI's repeatedly. Another is that the quite useful "insert" and "replace" context items only offer a few first-tier options: one or two related palettes, or all palettes. Try to insert a few datalog functions for example, and you have to navigate down 6 levels for each. It's even worse if you have to use "select a VI..." and browse to it. For the worst cases, insert and replace lose their advantage over copy-paste or quick drop.

I propose a dynamically generated palette consisting of the last several VIs and functions (even controls) that have been dropped. This is analogous to recent-commands-list functionalities common in CAD packages.

- As a member of the functions palette, the items in it are at or above the level they are in their normal place in the hierarchy.

- Since it's a palette you could pin it and it would be handy for dropping the same node on two different block diagrams

View All (5)

Problem:

When handling larger data blocks I get "not enough memory" error messages with only option to kill the executable (from time to time, but usually unwanted ).

Most of the time this involves array functions (initialize array, build array, etc). As this problem is also related to the used PC it cannot be tested (easily) on a developer machine before deploying the executable to a wide range of computers...

I propose the idea to enable some error handling in such cases. This could be done in two ways:

1) Add error output to array functions. This could be available optionally by right-click menu so you don't break older code. Output would be an error stating "Not enough memory for operation ..."

2) Add a new application event "Application.MemoryAllocationError". This way the program the program can atleast catch the problem. (Inspired by "OnError" constructs of text-based programming languages...)

View All (5)

View All (6)

When you double click a dynamic dispatch VI, LabVIEW opens the implementation selection dialog to allow you to choose the relevant VI.

There is, however, a case when this seems to be unnecessary - if the wire going into the DD terminal does not have implementations in a descendant (or doesn't have descendants at all) we could immediately open the VI in that class because that's the VI we most likely want.

In this example, the child class does not have any descendants, so if you double click the bottom VI, LabVIEW could (and if this idea is accepted, should) immediately open the VI from that class.

You might think that if you're already using the child wire then the VI doesn't need to be DD in the first place, but there are cases when you work on the lowest level and want to use VIs which are also shared by the higher levels.

This isn't a huge issue (you basically save a single double click or Enter), but it would be a nice shortcut. In cases where we do want the implementation from a parent class we could get it from the project.

In the Build Specifications under Version Information one has the option of setting the Version Number of the build. Ther Version Number is of the form Major.Minor.Fix.Build.

There is an option to Auto Increment the Version Number. If this is selected the Build component of the Version Number is automatically incremented every time the specification is built.

I always use this setting since I can thereby tell the difference between builds. The major annoyance here is that although only the Build component is automatically updated all four controls are disabled and grayed when Auto Increment is selected. That means that every time I want to change the Major, Minor, or Fix part of the Version Number I have to uncheck Auto Increment, make my changes, and then re-check Auto Increment. More than once I have forgotton to re-check Auto Increment, which then screws up my numbering scheme.

Idea: When Auto Increment is selected for the Version Number, only disable and gray out the Build control. Leave the Major, Minor, and Fix controls enabled.