Add configuration and debugging tool for Channel Wires

[Norbert_B]

For my understanding, channel wires are now available to ease the use of asynchronuous data transfer technologies.

I am convinced that this requires additional configuration and debugging capabilities to be really "easy to use".

My recommendation is:

1) Add a configuration tool:

It should list all channel wires used in the project/loaded VIs. This should be possible if Channel Wires reference by name. We could have a list of terminals for specific channel wires similar to bookmark manager. Double clicking on an entry should enable the user to jump to the instance in the code.

2) Add debugging tools:

Similar to the configuration tool, naming channel wires enables debugging tools like the Distributed System Manager for shared variables or Execution Trace Toolit for LV. This helps users to identify issues due to timining of execution and possible race conditions.

[AristosQueue (NI)]

> I am convinced that this requires additional configuration and debugging capabilities to be really "easy to use".

I am neither convinced nor unconvinced. After three years of working on these, two with significant beta users, I'm a firm "maybe, leaning toward doubtful".

I think there may be a use-case for a probe that simultaneously monitors all channels on a single VI. But system wide? That's a pretty sketchy suggestion. Channels express a connection within a given subsystem. Unlike refnums or variables, their connections are well-defined, both to the user and to the compiler/execution environment. They do not engender the same potential need for global monitoring that refnums do. We built the Desktop Execution Trace Toolkit (and the related Real-Time Trace Toolkit) to cover refnums. But channels were built expressly to eliminate the need for that, and initial evidence is that they successfully do eliminate that. Data collection is ongoing.

Use the Desktop Execution Trace Toolkit if you need to add log points to your code to time global events (such as multiple VIs accessing the same hardware or file on disk). If you have timing issues between channels, you're probably stringing multiple channels of the same direction between the same two regions of code. Between any two loops, there should be one and only one communications mechanism (refnum, variable, or channel) going from A to B and possibly a second going from B to A. If you have more than one in either direction, refactor your code. You don't need a tool to find the bug -- that IS the bug. It is a bug bug in any communications scheme, but with refnums and variables, it is often a lot less obvious to see. Channels at least make it visibly obvious. You can say, "Well, I want to try to align the behavior along those multiple communication methods, so I need the global log." But that's a losing battle. Change the comm architecture to be single band.

You can add calls to "Generate User-Defined Trace Event" to trace the events of your program that are at the macro scope. We've considered adding such calls to the channel templates themselves but have thus far decided it is unnecessary given the design of channels do not admit the same timing issues as free-form refnums and we do not want to pollute those log files with information that isn't generally the source of global timing issues. Your higher level events may need timing control.

A single master table would not be a fixed list. There are a dynamic number of channel wires (reentrant clones) with their endpoints reassociated on each call as needed (shared reentrancy, call by reference endpoints). As for naming... see my reply on other idea sumbission.

[Darren]

Any idea that has received less than 2 kudos within 2 years after posting will be automatically declined.