LabVIEW Idea Exchange

Suppose that in the scenario seen below we would like to merge the error out terminal of VI 2.vi back into the main error wire. This is, of course, a common programming pattern.

Currently we would need to insert a Merge Errors node into the existing wire (Pressing Ctrl + Space, typing "erg", then Ctrl + I is probably the quickest way to do this), then wire the error wire as desired. Currently creating a wire from the error out terminal and ending that wire onto the existing error wire results in broken wires, as seen below.

It would be useful to have an option that specifies that a Merge Errors node would automatically be inserted in this case. That option could be named something like "Automatically insert the Merge Errors node when suitable", and could be located in the Tools >> Options... menu alongside options such as "Place structures with Auto Grow enabled" or "Auto-insert Feedback Node in cycles".

When the "Automatically insert the Merge Errors node when suitable" option is ticked, a Merge Errors node would automatically be inserted in the scenario described earlier, as seen below. This would save the few seconds required to execute the Ctrl + Space, "erg", Ctrl + I sequence.

Notes

• I would be happy if the default value of the "Automatically insert the Merge Errors node when suitable" option would be unticked, which would maintain the current default behaviour.
• Even if the option would be ticked (enabled) by default, I think it would still make sense from a usability point of view. I suspect that the number of times people intentionally use this feature would be greater than the number of times that people wire error wires together by mistake and would wish for the wires to be broken.

Thanks!

Problem: Currently it is impossible to know in advance what errors (what error codes) a node or native VI can produce. (Native VI = VI that ships with LabVIEW)

For example, I recently implemented a module that communicates with another endpoint using the LabVIEW TCP primitives we know and love: TCP Open Connection, TCP Read, TCP Write, TCP Close Connection. In order to create robust software I needed to understand what error codes each of these primitives can generate, and in what circumstances.

Through initial testing I discovered that TCP Open Connection can generate errors 56, 62, and 66. I then handled these errors locally in the code.

Around two weeks later, during further testing of what I thought was a fully complete and tested module, the module unexpectedly started experiencing error 60 many times per second. The module had never experienced error 60 before. The module was configured to broadcast an event each time an error was detected. This flooded the listener (the DQMH tester VI that was listening to all broadcast events) with thousands of error messages per second. The tester VI front panel buttons became unresponsive, because the tester was flooded with so many incoming broadcasts. The only way to break out of the cycle was to abort the tester, then close the project to shutdown the module.

This way I learned "the hard way" that that TCP Open Connection can generate error 60 in certain circumstances, in addition to the error codes I had handled already.

Solution: The detailed help of each node and each native VI should list all error codes that can be produced by that node or VI. For example, in the case of TCP Open Connection, the detailed help should contain a description similar to the below.

"

TCP Open Connection can generate the following errors:

• Error 56
• Error 60
• Error 62
• Error 66
• and so on listing here any/all error codes that can be generated by the node.

"

This list would be extremely useful, as it would make us (professional LabVIEW programmers) aware of the various error codes a node or VI could occur generate. This would encourage the programmer to think of ways to handle all those possible errors, thus resulting in more robust code.

By reading the "Explain Error..." message of each error code the programmer could also understand the circumstances in which the node or VI generates each particular error.

Notes

• In summary, this idea suggests an improvement to the detailed help documentation of each node and native VI.
• It should be possible to automate the creation of the lists for each node and native VI.
  • For nodes whose source code is written in C++, a program could be created to scan the source code files and return the list of possible error codes generated by the function.
  • For native VIs, VI scripting could be used to achieve a similar purpose and output the list of errors that could be generated by that VI.

I am currently struggling with the issue that the shown knob permanently triggers "Value change" event as long as the user has not finished adjusting it yet (left mouse button is still pressed). This may be an intended behavior, but it is not in my case.

For boolean elements, there is the configuration option of "Mechanical Action". For strings, there is the option "Update value while typing". However, there is currently no such option for numerical elements.

Therefore, I would like to suggest the following:
Add an option "Update while adjustment" - true by default, so it acts as it do currently. If this option is set to false, the "Value change" event would only be triggered after the input is completed by the user.

The situation:

There is a user interface that provides the user with an array control.

The array control provides the user only one or a limited number of elements.

The user must use the scroll bars or the index control to select the correct element that he wants to modify.

The problem:

The user can scroll to a position beyond the last available array element and enter data. This increases the size of the array as expected, but not as desired in the given situation.

After the user finishes entering, the program must check the size of the array and reduce it again.

The proposed solution:

There should be a "max. array index" property of the array control. It should prevent the user from scrolling to a position beyond this maximum element index and/or editing such a position. It should also prevent adding elements via the right-click menu when the maximum number of elements has already been reached.

Extensions:

There could also be a minimum property that prevents the user from deleting array elements so that the total number falls below the minimum.

Notes:
The proposed solution should only affect the user's input capabilities. It should not change the size of the array if it was specified programmatically.

It would be nice to have some sort of overlay on the Controls and Indicators that are hidden on the block diagram, to quickly see that its hidden on the FP.  Add a black frame or grey out the background.  

If you have an event that contains a cluster typedef, then the event structure automatically unbundles the data:

I generally want to work with the entire typdef though. Why not expose the entire typdef to improve code maintainability?

(No one wants to re-bundle that data just to send it to a subVI or new event...and then risk losing data when a new property is added later.  Workarounds include adding a typdef of a typdef, or going class-based...but that overhead/creativity shouldn't be necessary.)