An OWEN TRM210 installation reported SP from the LvoP group with Bad quality while PV continued to read normally. The fault appeared in WinCC 7.0 and two independent OPC clients, which localizes the problem to the OPC server, device command handling, or parameter mapping rather than one SCADA client.
Identify the Failure Boundary
| Item | Observed result | Engineering implication |
|---|---|---|
| Device | TRM210, reported version v02.0022
|
Record this version when escalating or validating replacement software. |
| Connection |
COM3, device address 1(8), OWEN protocol |
The same communications path returns different results by command. |
PV |
Reads normally | The serial link and device are not completely unavailable. |
SP |
Bad quality in WinCC 7.0, QuickOPCClient, and OPCScout10 | The failure is reproducible outside the SCADA application. |
| Server maintenance | Reinstallation and removal with Kassl-dOPCUnReg did not restore SP
|
Repeating the same reinstall is not an evidence-supported remedy. |
Interpret the OPC Server Log
11:32:21.355 COM3: address 1(8) read command(Pv ) parameters() << 0x42 0x18 0xd9
11:32:22.292 COM3: address 1(8) read command(SP ) parameters( 0 0) << 0x31 0x91 0x 7 - n.Err=0x31The log confirms that polling reaches both commands, but only the SP transaction records n.Err=0x31. The evidence does not define that code, so do not assign it a device-specific meaning without the applicable server or protocol documentation. Because PV succeeds on the same port and address, first investigate command encoding and the legacy server's SP mapping.
Use the Supported Migration Path
The legacy server was identified as “OPC server RS485 protocol OWEN.” OWEN stated that its older OPC servers contain unresolved defects and recommended migrating to the newer OPC server. No affected server version or fixed release number was supplied, so verify the installed server build and current TRM210 library support through OWEN's official support channel.
- Back up the existing OPC configuration and record the TRM210 version, OWEN protocol selection,
COM3settings, address1(8), andLvoPitem definitions. - Install the newer OPC server in a controlled test environment and check whether its OWEN-protocol library now includes the TRM210.
- If TRM210 remains absent, do not treat a TRM101 definition as a validated production substitute. A test using TRM101 read both
PVandSP, but the evidence does not establish complete command, scaling, write, or alarm compatibility. - Escalate the missing TRM210 definition and
n.Err=0x31log record to OWEN, including the recorded device and communications details.
Verify the Corrective Action
Test with an independent OPC client before reconnecting WinCC 7.0. Confirm that PV and SP both return good quality, that SP has the expected value and scaling, and that repeated polling no longer produces n.Err=0x31. Then verify the same items in WinCC and monitor the server for the previously reported cyclic restarts.
FAQ
Why is TRM210 SP Bad while PV still reads correctly?
The log shows successful PV polling but records n.Err=0x31 for SP. This points toward the legacy server's command or item mapping rather than a total loss of the COM3 connection.
Will reinstalling the old OWEN OPC server fix Bad SP quality?
Reinstallation and unregistering with Kassl-dOPCUnReg did not correct this case. OWEN identified unresolved defects in older OPC servers and recommended using the newer server.
Can I configure TRM210 as TRM101 in the new OPC server?
A TRM101 library definition read both PV and SP during testing, but full TRM210 compatibility was not established. Use that result only for diagnosis unless OWEN validates the mapping for production use.
