LabVIEW Idea Exchange

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.  

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!

When wiring to a growable node that is currently full requires you to either pull the node bigger first and then wire or wire and create a wire stub, then pull it larger and the Connect the stub to the terminal. 

Instead change the behavior so, if wiring is started and ends over a growable node, the node will grow automatically and add the wire being created to the new terminal. 

For example: starting an error wire and ending on a merge that is currently full, the node automagically grows by one and adds the wire to the new (last) terminal. 

Provide a method to delete a shortcut to a recent file that is no longer current. The main LabVIEW window on the right-hand side below Open Existing has a list for All Recent Files, Recent Projects, Recent VIs, or Other Recent Files. The All Recent Files is default and perhaps most convenient. However, it always lists projects before files. Therefore, if we open numerous projects the recent files are pushed down and must be scrolled to, limiting convenience. It is common to open an example project, a new Untitled Project 1.lvproj, or one to help a coworker. These take up space which could show frequently-used files. These can be deleted from the LabVIEW.ini (e.g. RecentFiles.projectPathList, RecentFiles.pathList keys) but doing so it tedious and prone to allow accidental changes. A right-click pop-up menu could contain a Delete/Remove from List item; the Delete key cannot be used because there is no item selection since a single click opens the item.

Currently if you draw a diagram disable structure around a section of code any wire coming out of it will be set to "Use Default if Unwired". This is almost never the desired behavior, and can easily lead to bugs if people forget to connect wires through on the Enabled case. The VI should be broken until the developer makes any necessary changes in the Enabled case.