Please ensure Javascript is enabled for purposes of website accessibility
Powered by Zoomin Software. For more details please contactZoomin

AVEVA™ Plant SCADA

Debugging Messages

  • Last UpdatedAug 04, 2025
  • 1 minute read

DriverTrace command

The DriverTrace command is still useful to check the communication (DCB requests and replies) between the IOServer and the driver.

Generally speaking, have this turned on with a [debug]drivertracemask of 21c0f. This setting traces things down to the unit level (not data) and allows to understand what state the I/O server thinks a driver is in.

When the issue is data integrity, then the higher volume traces may be needed to confirm the actual error or data value being returned to the I/O server. This mask will be something like fffeff (this excludes the CPU calls which you normally don’t need).

Drivertrace allows either all ports or a single port to be traced. If the issue is isolated to a single port, then just trace this port. [debug]drivertraceport=PortABC

Syslog Size

To minimize the chance of missing something, [debug]syslogsize=32000 should be set and the syslog.dat’s deleted or renamed prior to capturing fresh traces.

DCB Debugging

When the INI parameter DebugCategory is set to DCB, then trace statements will be produced in the driver log file. The trace statements detail the actions undertaken by the driver in order to process requests received by I/O server.

The following legend describes the symbol abbreviations used in the trace statements:

Symbol

Description

ad

I/O point address

ua

Unit address

ut

Unit type

uc

Unit count

In This Topic
Related Links
TitleResults for “How to create a CRG?”Also Available in