LabVIEW Idea Exchange

It has been a few months since a suggestion has been made to do something about the For Loop, so if nothing else it is time to stir things up a little bit.  There have been several suggestions to do something with the iterators, for example:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Smart-Iterators-with-Loops/idi-p/967321

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/for-loop-increment/idi-p/1097818

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/quot-Start-Step-Stop-quot-structure-on-For-loops/idi-p/1022771

None of these has really gained traction, and heck, I haven't settled on any of them myself.  In most cases I am satisfied with a workaround, usually involving the Ramp VI.

There is one case where I am not happy with the workaround.  I happen to need reverse iteration values quite often (N-1,N-2,...0).  With the N terminal pinned to the top-left corner I have little choice but to do the following and start zigging and zagging wires:

I would simply like a reverse iteration terminal which can be moved around at will and simply counts down.  Doesn't have to look like I have drawn it, that just happens to be intuitive to me.  Naturally this terminal (and the normal iteration terminal) should have the option to be hidden.

I thought about having the option to have the loop spin backwards, similar to reversing all auto-indexing inputs and having the iteration terminal count down, but I just could not decide what to do about auto-indexed outputs.  My G-instincts tell me that they should be built in the order of loop cycles, my C-instincts tell me I am building array[i] and if i goes in reverse order, so should the array elements.  For now I say, forget it, and just stick to the simple terminal.  Array reversal is essentially free, so I at least have a workaround there.

Hi,

It would be awesome if there was an option in project window to set if the method is contained within a .lvclass file or ouside of the .lvclass next to it in the folder.

Now it's like this:

It's hard to use a class like that in a plugin architecture with VIs on the outside. Lets put everything together inside like a LabVIEW LLB!

How it should be:

Don't get me started on Packed Project Libraries 😉 We just need LLB functionality, for the class to behave like a folder and we are happy 🙂

Piotr

Please add to the right-click Cluster popup menu a Remove Cluster item analogous to a tab control's Remove Tab Control removes the parent container and leaves the contents as-is.

The LabVIEW IDE may coerce diagram constants when the enumerated typedef changes.  The problem is: the constants may occur in many places, and the coerced value is not necessarily helpful.

In the pictures below, the "Idle" element is removed from the typedef and the IDE coerces the diagram constant to a neighboring value "triggered".

Now the program behaves as if triggered. 

When a diagram constant becomes invalid, wouldn't it be better to flag it as broken, so that the programmer is forced to handle the problem?

In LabVIEW we can dynamically run a VI in a few ways:

a) If it's not running Top Level VI or if the VI re-entrant with the Run method.

b) Already running as sub VI, with Call By Reference.

c) Make a new VI and drop the (running) sub VI on the diagram.

Downside of a) is we can't always make sub VI's re-entrant, but still want to call it by reference. Downside of b) is we need to know the strict type (connector pane). Downside of c) is we might end up with a lot of VI's just to function as Top Level VI for the sub VI's and it doesn't work in executables.

I like to propose a method, so we can dynamically call a sub VI without knowing the strict type.

Using it, we enable LV to dynamically run sub VI's while setting\getting it's parameters by name.

For sub VI's (already running) this method will act as Top Level VI. For Top Level VI's it will fail unless it's idle.

(Please ignore my first confusing attempt)