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.

Problem: Currently, the native nodes and VIs that can be used for error manipulation are located in the Dialog & User Interface palette. While manipulating errors can mean generating dialogues, and can influence the User Interface/User Experience, error manipulation is a broader and stand-alone topic.

Solution: Nodes and VIs that are relevant to error handling/error manipulation should be given their own subpalette inside the Programming palette. The new subpalette could be named "Error Handling", "Error Manipulation" or "Errors".

The Project page of the Project Properties window contains the Mark Existing Items... button. When pressed, this button enables the programmer to enable the "Separate Compiled Code" setting for all files in the project. This is very useful.

Suggestion: It would be useful to have similar functionality that could enable or disable Automatic Error Handling for all VIs in the project. This could be achieved by adding a drop-down menu that enables the programmer to select whether they want AEH to be enabled or disabled, alongside a button that enables the programmer to apply the selection for all project items, as seen below.

Notes

• It may be best to add the button and drop-down menu in a new dedicated Category page named perhaps "Error Handling".
• It would be useful to have the functionality available at a class and library level too. Meaning the ability to easily enable/disable the setting for the VIs inside a lvclass or lvlib, but not for the rest of the project.
• The "Separate Compiled Code" and Automatic Error Handling settings are similar in that they are both Boolean settings (True/False value) that apply to each and every VI.

Problem: When developing or inheriting a large code base it is helpful to know which VI has Automatic Error Handling (AEH) enabled and which has it disabled. Currently, the quickest way to get this information is to bring up the VI Properties window (pressing Ctrl + I) and navigate to the Execution page. This is tedious when done on large numbers of VIs.

Solution: LabVIEW should display whether AEH is enabled or disabled on the Block Diagram. For example, a grey triangle located in the bottom-right corner of the block diagram window could indicate that AEH is disabled, and an "error green" triangle could indicate that AEH is enabled, as seen in the screenshots below. This display method is just a suggestion - professional UX designers may well find a better method. I would be happy with any indication method that I could at a glance see on the block diagram window.

Idea expansion:

• Executing a single left click on the triangle (or any other indication method) would toggle the setting to its other value. For example, a single left click on the grey triangle would toggle the AEH to enabled and the triangle would become green.

Idea/bug-report:

If you have a multicolumn listbox with column headers and you want to delete one of the columns you can right-click on the column and select delete column, but if there are no items in that column LabVIEW will not actually do anything(!):

This also applies to empty rows with headers. This is non-intuitive and makes it cumbersome to remove a header and keep the width/height of the ones you want to keep...