LabVIEW Idea Exchange

We're witnessing more and more requests to stop LV hiding important information from us.  In One direction we want to be able to know (and some want to break code) if structures are hiding code.

Others want LV primitives to give visual feedback as to how they are configured, especially if that configuration can have an effect on what's being executed or how it's executed.

Examples include (Please please feel free to add more in the comments below)

Array to cluster (Cluster size hidden)

Boolean array to number (Sign mode hidden)

FXP simple Math (Rounding, saturation and output type hidden)

SubVI node setup (When right lcicking the subVI on the BD and changing it's properties - show FP when run, suspend and so on)

Sub VI settings in general (Subroutine, debugging)

I know there are already ideas out there for most of these (and I simply chose examples to link to here - I don't mean to leave anyone's ideas out on purpose) but I feel that instead of targetting the individual neurangic points where we have problems, I would like to acknowledge for NI R&D that the idea behind most of these problems (Some of them go much further than simply not hiding the information, and I have given most kudos for that) is that hiding information from us regarding important differences in code execution is a bad thing.  I don't mean to claim anyone's thunder.  I only decided to post this because of the apparent large number of ideas which have this basic idea at heart.  While many of those go further and want additional action taken (Most of which are good and should be implemented) I feel the underlying idea should not be ignored, even if all of the otherwise proposed changes are deemed unsuitable.

My idea can be boiled down to the fact that ALL execution relevant information which is directly applicable to the BD on view should be also VISIBLE on the BD.

As a disclaimer, I deem factors such as FIFO size and Queue size to be extraneous factors which can be externally influenced and thus does not belong under this idea.

Example: I have some Oscilliscope code running on FPGA and had the weirdest of problems where communications worked fine up to (but not including 524288 - 2^19) data points.  As it turns out, a single "Boolean array to number" was set to convert the sign of the input number which turned out to be completely wrong.  Don't know where that came from, maybe I copied the primitive when writing the code and forgot to set it correctly.  My point is that it took me upwards of half a day to track down this problem due to the sheer number of possible error sources I have in my code (It's really complicated stuff in total) and having NO VISUAL CLUE as to what was wrong.  Had there been SOME kind of visual clue as to the configuration of this node I would have found the problem much earlier and would be a more productive programmer.  Should I have set the properties when writing the code initially, sure but as LV projects grow in complexity these kinds of things are getting to be very burdensome.

According to my understanding and the following discussion:

http://forums.ni.com/t5/LabVIEW/Why-exactly-can-t-I-inline-this/td-p/3126562

certain types of Property nodes and Invoke nodes should be inlineable without any great problems.

I would suggest that the LabVIEW compiler get's a bit smarter about this aspect of limiting the ability to inline code.  If there's no technical limitation regarding inlining of a property node or Invoke node which is fed with a reference (which does not originate from a local object i.e. a static reference to a FP object) then it should be inlineable.

The Run Method is pretty much the only option we have in LabVIEW to scale an application dynamically by instantiating new VIs - but there is one big catch - for some reason it requires the unser interface to be idle(!).

Related methods like setting control values e.g. do not have this requirement so they do not pose a problem - but the main method for dynamic instantiation does - and can be blocked by something as simple as a user that opens the calendar view of a date and time control (which of course never should do this either, but that's another issue/idea).

Personally I use the run method to create new trend windows (you never know how many trends a user wants to see at the same time), create session handlers for remote clients etc. The times it is used to actually create user interfaces it is not a big problem that the run method is in the user interface thread, but for session handlers and other things that needs to be created in the background based on requests from the outside? A HUGE issue.

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)