LabVIEW Idea Exchange

This idea came to me from Darren's Nugget 2-23-2018 on Data Agnostic Probes I thought it might be useful to write a Probe.vim or specifically, a data type malleable probe to gain the ability to have some access to the data itself in a general smart probe and maintain the ability to display the data in a type specific manner.

One example would be a "Data History Probe" that displays the history values of any data type.  I'm sure there are other good uses.

My forum question asked here: http://forums.ni.com/t5/LabVIEW/Determine-and-Minimize-LabVIEW-Build-Dependencies/m-p/1441734 has prompted me to post a New Idea on this exchange.

    To summarize:  LabVIEW executables tend to be on the LARGE side especially when driver packages like DAQmx, VISA amd IMAQ are required.  I'm asking if NI could add some enhanced functionality to the Application/Executable Builder that assist the user in determining and minimizing the size of the final distribution package.  Ideally this would be a completely automatic function that would simply minimize the build parameters to the smallest possible set after analyzing the active project.  Additionally, it would be great if this would be smart enough to pare down the driver package itself to the bare minimum.  (I.E. It shouldn't require a 150MB DAQmx package size to read a few thermocouples with a 9211 module.)

    At the very least, the Additional Installers tab should show the size of the packages you're checking off and the resulting installer's total size.

An example of the size increases of required installer packages for a simple DAQmx application:

Create a Panel Open event.

Among other things, it would provide a clean entry point for guaranteeing Control References have been created, allowing for their dynamic event registration to prevent errors such as the following:

(not really related to this idea)

Deferring panel updates is a tedious procedure, requiring a panel reference (not intuitive to get!) and a couple of property nodes. However, deferring panel updates is sometimes very important. For example when coloring the fields of a large table according to their values, a serious performance impact is encountered unless we defer panel updates. There are many other situations where panel updates should be suspended temporarily, especially if property nodes are used in a tight loop.

My suggestions is to make flat sequences a little bit more useful by adding a new function to the right-click menu of each frame: "Defer Panel Updates". Now a new connector will appear on the frame that accepts a panel reference. If left unwired, this applies to the panel of the current VI, but we can wire a reference to any panel we desire (useful for subVIs). There should be a visual indication indicating that updates are deferred, e.g. a slightly different background pattern (e.g. faint checkerboard or similar). Note that this idea does not clutter the palettes with a new structure, but simply extends the functionality of existing elements. Let's put those sequences to some good use!

During execution of such a frame, the panel updates are deferred and automatically enabled again once the frame ends. The configuration should be "per frame" of a multi-frame flat sequence.

This has many advantages over the current situation:

• It is immediately clear what part of the code executes during the deferral
• The deferral is clearly delimited and it is not possible to accidentally forget to re-enable the updates

How about having a timeout occurrence as an input for functions which support timeouts?

I am illustrating a single use case with queues (and a notifier) but I would see this as being beneficial to nearly ALL functions with timeout inputs.

Sometimes we'd like to wait for one of a few different functions (an example of mine which springs to mind is the Dequeue primitive).  At the moment we must essentially poll each primitive with a relatively short timeout, see if one responded and then handle accordingly.  This is (for me at least) ugly to look at and introduces polling which I generally don't like.  I'm an events man.

What I propose would be that instead of simply defining a timeout in milliseconds we can define both a timeout (in milliseconds AND an occurrence for the timeout).  If we wire this data to several primitives (all sharing the same occurrence) the first primitive to receive data triggers the occurrence so that the others waiting in parallel return also.

In the case where no data arrives, each function waits the defined amount of time but upon timeout DOES NOT fire the occurrence.  This would cover corner cases where you may want different parallel processes to have different timeouts (Yes there are cases although they may be rare).  It is possible to change the "priorities" of the incoming queues in thie way.

Background info: One example where I could use this is for RT communication.  Here we multiplex many different commands over TCP or UDP.  On the API side it would be beneficial to be able to work with several strictly-typed queues to inject data into this communication pipe while still maintining maximum throughput.  I don't like using variants or flattened strings to achieve this multiplexing.

Being forced to poll means the code must decide between efficiency (low CPU usage) OR response time (setting a very low timeout).  Although the CPU load for polling may be low, it's not something I personally like implementing and I think it's generally to be avoided.

There IS a LVOOP solution to this particular problem but not everyone can use LVOOP in their projects (for various reasons).  I can envisage other use cases where interrupting a timeout would be desireable (Event structure, wait on ms, VISA read and so on and so forth).

Shane.