LabVIEW Idea Exchange

There is a construct I am quite fond of in pointer-friendly languages, using iterator math to implement circular buffers of arbitrary data types.  They are a little bit slower to use than straight arrays, but they provide a nice syntax for fixed sized buffers and are helpful in cases where you will be prepending and appending elements.

I am pretty certain that queues are implemented as circular buffers under the hood, so much of the infrastructure is already in place, this is mostly adding a new API.  Added bonus:  the explicit circular buffer can be synchronous, unlike the queue, so for example you can put them in subroutine VIs.

It should be easy to convert 1D arrays to/from circular buffers.  Array->CB is basically free, the elements are in order in memory.  CB->Array requires two block copies (most of the time).  This can be strategically mananged, much like Reverse or Transpose operations.

Use cases:

You can implement most of  the following two ideas naturally:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Looping-Input-Tunnels/idi-p/2020406

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/New-modes-on-auto-indexed-input-array-tunnels-in-loops/idi-p/2263706

Circular buffers would auto-index and cycle the elements and not participate in setting 'N'.

You can do 95+% of what I wanted to do with negative indexing:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Negative-Values-in-Index-Array-or-Array-Subset/idi-p/960863

A lot of the classic divide and conquer algorithms become tractable in LV.  You can already use queues to implement your own stack and outperform native recursion.  A CB implementation of the stack would be amenable to subroutine priority and give a nice performance kick.  I have done it by hand for a few datatypes and the beauty and simplicity of  the recursive solution gets buried in the implementation of the stack.  A drop-in node or two would give you a cleaner look and high-octane performance.

Finally, perhaps the most practical reason yet:  simple XY Charts.

As for appearance I'd suggest a modified wire like the matrix data type.  Most if not all Array primitives should probably accept the CB.  A few new nodes are needed to get/set buffer size and number of elements and to do the conversions to/from 1D arrays. The control/indicator could have some superpowers:  set the first element, wraparound scrolling (the first element should be highlighted).

What bugs me about the VI Profiling Tool is that it is not intuitive.  The information it provides is really useful; however, it's so hidden and difficult to interpret that few people actually know where it is to use it.  Let's say you are simply acquiring data using DAQmx and writing that data to a file, as below:

You might want to find out how to make this more efficient, but the only way you know is to insert Tick Count VIs and wrap your wires through sequence structures to do it.  It's annoying, and there are other ideas from JackDunaway (here) and JohnMc19 (here) which aim to simplify the use of those VIs. 

But why re-code your application when the VI Profiler can do it for you?  In addition, the VI profiler has more timing information (longest, shortest, average, total, etc) as well of number of runs and memory allocation data.

Good news: VI Profiler makes getting the data easy. 

Bad news: VI Profiler makes using the data difficult.

Why Using the Profiler is Difficult

First, you need to know it exists among a number of bland and condensed gray menus (Tools>>Profile>>Performance and Memory).

Next, you have to coordinate starting the profiler with starting your VI (start the Profiler, then start your VI, then stop your VI, then stop the Profiler).

Finally, you have to dig through a TON of VIs to find the ones that are relevant (I assume this is because, for polymorphic VIs, all of the instances are loaded into memory, even the dozens that aren't currently being used.)

When you find the VI you wish to examine, it will look something like this:

Have fun sorting through that!  When I finally find a VI that's hogging memory or speed, I'd expect to click on it to navigate to that VI.  NOPE!  All the VI Profiler does is make the line bold.  Not particularly easy to use...

I can't say if it's possible to get rid of VIs that aren't being used, or to make the menu option more visible to the user, but I do have an idea or two for how to make this information easier to understand in LabVIEW.

So here's what I suggest:

Adding a couple of check-boxes to the top of the VI Profiler will view in relation to your LabVIEW VI.  Notice the extra check boxes in the top of this image. 

One checkbox allows you to color the column you wish to highlight in your LabVIEW code.  The other checkbox inserts a text comment containing the highlighted data straight into you LabVIEW code (right next to the sub VIs):

From the above picture, you can clearly see the Write to Spreadsheet File VI is the slowest to execute.  Next in line are the Start DAQmx Task VI and then the Stop DAQmx Task VI.  So if a developer wanted to find out how to make his loop run faster (and therefore increase the rate data is read from his PC RAM), he would know the VIs that are more red are the ones he needs to focus on first.

Also, if a user wants to highlight the memory usage, he could select a memory column from the VI Profiler.

Then the LabVIEW block diagram would look like this:

In this case, if a developer wants to find out how he can optimize his code for memory usage, he knows where to start.

Side-note: I think selecting multiple colors at a time (one for each column of data you wish to highlight) would be cool, but that would start to get messy on the block diagram.

Other data, like the number of runs, could highlight which sections of code are running more often than others.

If we integrate the VI profiler more effectively into LabVIEW, there are a lot of benefits:

1. Re-coding to find timing specs won't be necessary for Sub-VIs

2. Monitoring memory allocations much easier (some users don't know it's possible with LabVIEW).

3. When there's a problem, it's easier to understand which SubVIs are slowing down code or hogging their memory.

4. Developers can further code development WHILE being wary of inefficiencies.

5. More integrated development environment "feel" for new customers or the experienced G-coder.

Please let me know what you think!

So when it comes to using a queue, there is a somewhat common design pattern used by NI examples, which makes a producer consumer loop, where the consumer uses a dequeue function with a timeout of -1.  This means the function will wait forever until an event comes in.  But a neat feature of this function is it also returns when the queue reference becomes invalid, which can happen if the queue reference is closed, or if the VI that created that reference stops running.

This idea is to have similar functionality when it comes to user events.  I have a common design pattern with a publisher subscriber design where a user event is created and multiple loops register for it.  If for some reason the main VI stops, that reference becomes invalid but my other asynchronous loops will continue running.  In the past I've added a timeout case, where I check to see if the user event is still valid once every 5 seconds or so, and if it isn't then I go through my shutdown process.

What I am thinking is that there could be another event to register for, which gets generated when that user event which is registered for, becomes invalid so that polling for the validity of the user event isn't necessary.

before:

after: