LabVIEW Idea Exchange

More often than not, one location doesn't work for both. Here's an idea:

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´m not to fond of the native Boolean constants and their ability to change value by just a mouse click. To me that is not a behaviour of a constant. What if Pi could be changed to e with a mouse click?

The issue is that when clicking around and cleaning up a messy diagram you may by mistake change a Boolean constant without noticing.

I would like to have native immutable Boolean constants like the ones I´ve implemented with two small VIs. My artwork is perhaps not the best, better ideas are up for anyone´s suggestion.

When an array leaves a loop with indexing enabled, you get an array which has one more dimension, but quite often you want to concatenate the data to an array with the same number of dimensions.

If the subarrays have the same length, you can use reshape array, but usually they don't and you need to do something like below.

It would be very useful if output tunnels for arrays had an "Enable Concatenate Indexing" option as well, as depicted below, which would do this.

This is a very small suggestion, and hopefully easy to implement.  When wires cross, very often one of the wires involved is an Error wire, and as it is usually wired last, it sits on top of all the other wires.  All I'm asking is that Error wires are always placed underneath all other wires when they are created.  To my mind, this improves the readability of the diagram.

What would help further is if Error wires were "faded", as if they were 50% transparent.  You do need to be able to see them, but not such that they stand out.  But I'm much less certain that such a change could happen.  The khaki color is an improvement on the old pink though, that's for sure!

All events have optional event terminals on the left. Signaling events also have e.g. a "discard?" terminal on the right.

Hovering over them with the mouse does not generate any relevant context help, and maybe it should. (well, there is a tip string that simply duplicates what is already written on the terminal giving boring redundant information).

I suggest that hovering over an event terminal with the context help open should first of all tell us how these terminals are called in general ("Event Data Node", according to the help, but who knows that???), but also give specific information about each terminal under the cursor.

For example:

• if I hover over the "discard?" terminal, it could tell me that wiring a TRUE would ignore the event, etc.
• if I hover over the "Ctlref" terminal, it could tell me that it outputs a control reference of the control that fired the event
• if I hover over the "type" terminal, it could tell me a list of possible types and what they mean.
• etc.

IDEA: I suggest to add relevant context help to all event data nodes. Thanks!

(Note that e.g. the "timed loop" terminal already have context help. This should be similar)

The IDE would be more consistent if all the toggle-able features were collected together under the "Visible Items" submenu. Photoshopped example of a FOR loop below, but I'm sure there are others. "Show Dynamic Event Terminals" comes to mind...