The decisive evidence is not a generic SCADA timeout: the Lectus OPC server reports a COM4 write failure followed by COM4 becoming unavailable.
System and Failure Pattern
| Item | Evidence |
|---|---|
| Controllers | Five Pixel2511 units and two SMH2G units |
| Software | MasterSCADA with Lectus OPC Server |
| Workstation | Windows 7 |
| Server version | Version 3.9, Build 108, dated 15.04.13 01:55:52 |
The USB port was configured to remain enabled, so the evidence does not support simple USB power suspension as the confirmed cause.
What the COM4 Log Establishes
14:28:42.941 [2552] [ComPort] Error writing to COM port, Port=COM4
14:28:42.972 [2552] [ComPort] COM port unavailable, Port=COM4This establishes that the server lost access to COM4 at the failure boundary.
A SCADA write may coincide with the failure, but the available log excerpt does not prove that the requested Modbus write or its target address caused the outage. Preserve log data from normal polling through the first COM4 error before changing communications parameters.
Isolate the Fault Domain
- Enable Lectus server logging and capture an uninterrupted segment showing normal traffic, the first failed write, and subsequent port-unavailable events.
- Update Lectus OPC Server from Version 3.9 Build 108 to the manufacturer-supported current release, then repeat a run longer than the observed 1.5–2-hour failure interval.
- If replacement does not resolve the fault, test another USB port and inspect the USB port and converter for temperature-related instability. Heating was identified as a plausible signal-integrity or device-reliability mechanism, not a confirmed cause.
- Escalate with the server version, driver details, converter identification, and the log segment surrounding the first COM4 error. A post-failure bug file alone is less useful than the transition from working to failed operation.
Verify each change by running beyond two hours without a COM4 write error, confirming live values continue to update, and exercising the SCADA command that previously appeared near the outage.
Polling and Modbus Map Decisions
Polling interval and inter-request delay can affect serial traffic load, but the evidence does not show buffer overflow, timeout counts, or bus utilization. Do not treat reduced polling as the primary repair until COM4 remains available. After stabilizing the port, adjust one timing setting at a time and verify sustained reads and writes.
The available evidence reports no inherent conflict from using controllers with old and new Modbus variable maps on the same network. Each device must still be addressed using the map that applies to that controller. No supported baud-rate value is supplied, so retain a mutually supported network rate and validate it through error-free operation rather than introducing an unsupported numeric recommendation.
FAQ
The log narrows the fault to the server-to-COM-port interface chain but does not distinguish among the server, driver, converter, USB port, and operating system.
If a compatible spare is available, substitution is a direct isolation test after preserving the failure log and updating Lectus OPC Server from Version 3.9 Build 108. Run the replacement beyond two hours while keeping other settings unchanged.
Can old and new Segnetics Modbus maps share one network?
The evidence identifies no inherent network conflict. Configure each controller's OPC items against its applicable variable map and verify both reads and writes; the supplied evidence does not provide a specific baud-rate recommendation.