LabVIEW Idea Exchange

Looking at messy diagram from forum posts (not mine!), I often find myself in a situation that I cannot really tell where an "interesting" wire is coming from. Triple-clicking just shows me a spiderweb of wire segments going in all directions.

Often, the leftmost wire end is near the data source, but not always. Maybe it would help if we could right-click on a wire and do a "find source" and a halo,(or donut or similar) would temporarily appear showing where the data in the wire is originating.

A wire can have many sinks, but only one source and the data source is the most interesting property of a wire.

A tool to find it quickly could be helpful.

This picture is way too ugly, but should give some idea.... 😉

Anchore position of Bundle & Unbundle Ny Name elements to "Input cluster" and not to same point in the middle of element.

I don't like when I place (Un)Bundle By Name element to Block Diagram and when I connect Input cluster to same cluster wire then element dance on block diagram.

Similar: when you change (Un)Bundle By Name element by clicking a name terminal and selecting a name from the shortcut menu then element is dancing (moving) on block diagram.

Every time I have to shift (Un)Bundle By Name on block diagram to original position.

Expected behavior: Anchor (Un)Bundle By Name position to Input cluster part of element.

Second Unbundle By Name is reference of original position.

Second Bundle By Name is reference of original position.

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.

I'm missing somthing like that:

Amir.

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

I wanted to use a property node in an application today. I happened to have the Help context up and it showed "Run-Time Engine: No". But I could easily have missed that and not discovered the issue until much later, after building a lot of code and wasting time.

If the node had an obvious indication as soon as you put it on the block diagram - for example, a different color - that would help a lot and potentially save a lot of headache.

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

When a user clicks and drags a slider - hundreds of value change events are generated for your code to handle.

Most of the time the user experience you want is just to use the value when the user has stopped dragging the slider. Similar to a text input field where you can select to have the value update only once the user has finished typing instead of all the intermediate values.

My proposal is to change the slider events to support this use case. I'm inclined to leave the exact solution open - as long as NI can support this use case.

There is another idea to add an ended event which would allow for this: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Create-a-quot-User-Control-Ended-quot-Event/idi-p/1075504?profile.language=en but I created this post to be more specific.

You can find a number of attempts if you search the forums for "slider too many update events" such as 

• https://forums.ni.com/t5/LabVIEW/Slider-control-generates-too-many-quot-value-change-quot-events/td-p/830659?profile.language=en

• https://forums.ni.com/t5/LabVIEW/DBL-Slider-prevent-update-until-done-sliding/td-p/3705848/page/3?profile.language=en
• https://forums.ni.com/t5/LabVIEW/slider-value-change-event/td-p/802590

If you follow this through there are always compromises in every solution for getting this behaviour.

It would be nice to easily find objects that prevent a structure with "Auto Grow" from becoming smaller in size.  For example, the Add function in  the True case in the simplified example below.