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).

NI updater kindly informed me that LabVIEW 2014 SP1 was released (even though I uninstalled it shortly after I tried it last year) and out of curiosity, I took a look at the known issues list.

I learned a few interesting things I did not know about, and also that some problems had been reported as long ago as version 7.1.1. This type of stuff looks like bugs that won't be fixed, ever.

For instance, CAR #48016 states that there is a type casting bug in the Formula Node. It was reported in version 8 and the suggested workaround it to use a MathScript Node instead of a Formula Node (where is the "Replace Formula Node by a MathScript Node" contextual menu item?).

Problem: the MathScript RT Module is required. Even in my Professional Development System, this is not included by default. Does this really count as a workaround?

I read: we don't have the resources to fix that bug, or we don't want to break code that expected that bug.

In any case, this bug with most likely never be fixed.

The bottom line is, we can waste a lot of time as users, rediscovering bugs that have been known for a while and will probably never be fixed. As a user, I would really appreciate a courteous warning from NI that there are known traps and have a complete description handily available with the help file related to the affected function.

My suggestion: add a list of known issues (with link to their description) for all objects, properties, functions. VIs, etc, in the corresponding entry in the Help File.

Hello,

When you have to handle events, many times you have to use "defer panel updates"  fonctionnality, in order to make your front panel updates more fluent.

It could be nice to include a checkbox in the event configuration window, in order to ask (or not) an automatic defer panel Update.

If check box is checked :

• At the begining of the event handler code execution : DeferPanelUpdate = TRue
• Execution of the event code
• At the end of the event handler code execution : DeferPanelUpdate = FALSE

Manu.net

It would be nice to have the option for showing the radix on the index display of an array. This would make it easier to look at an array when dealing with addresses in hex.

For example, if you have a large array representing the contents of a flash, and want to look at specific addresses, you need to convert the hex address into decimal to be able look at the corresponding value in the array. This can get tedious and time consuming (although I will admit it does force one to learn how to make the conversions a little more quickly in your head... as long as you are not making mistakes!)

 >>>>> 

After installing a few word processing and graphics editing programs, my font list in LabVIEW is about 6 screens long and all I see without scrolling are some really useless fonts.

To select the ones I typically use (tahoma, courier, etc.). I need to scroll many pages, keeping a close watch on the alphabetically sorted names flying by when scrolling). Of course I could spend a day cleaning out my fonts, but I am never sure if something actually uses one of these.

Like most other applications, LabVIEW should maintain a short list on top, containing favorite fonts. This list could be auto-populated by the fonts used on the current front panel or just be a short history of recently selected fonts. There should also be a configuration option, allowing us to "pin" certain really-really favorite fonts to that area.

It could look as follows:

Of course what we really need is a modern text toolbar, but this idea would apply there equally. 😄

This idea started when I realized the WebDAV API provided by NI does not have the ability to read the File Creation information on a remote file.

"That's okay" I thought, I'm a programmer and will add it myself.  Looking at the source it looks like NI just leveraged someone else's protocol, and wrapped it into some Call Library Function Nodes.  NI could have written the WebDAV API wrapping their own HTTP API functions, using G instead, allowing for customization but they didn't.

"That's okay" I thought, I'm a programmer, and I'll look into recreating the WebDAV API, by calling the NI HTTP API.  Looking at the source sounds like NI didn't implement all of the HTTP functions available, only the most basic ones.  And since WebDAV requires more than just the PUT, GET, and POST, that means also having to update the HTTP API to have those functions, so that I can rewrite the WebDAV API.  Oh but look at that, NI also just (seemingly) wrapped someone else's implementation again into Call Library Function Nodes, this time calling the ni_httpClient.dll.  NI could have written the HTTP API wrapping their own TCP primitive API functions using G instead, allowing for customization but they didn't.

So this idea is for one or more of the following things, from the easiest, to the most difficult.

1. Add the File Creation Date, as returned information from the Get File Info of the WebDAV API.
2. Implement the WebDAV API in G, and eat your own dog food.
3. Implement the HTTP API in G, and eat your own dog food.