OWEN.A-M Connection and Programming Failure

Jason IP3 min read
Other ManufacturerPLC HardwareTroubleshooting
Licensed PE Working through this on a live machine? A Maine-licensed engineer can take it from here — included with IMD hardware, by the hour for everything else. Book an engineer

Its boot log shows that the controller still starts, reads DATAFLASH, mounts the flash file system, initializes communications, and loads the PLC core. The evidence does not establish a field-repairable cause; it points to inconsistent configuration data or communication between internal boards and supports service-center diagnosis.

Observed Failure Sequence

Stage Observed evidence Engineering interpretation
Initial operation Intermittent conveyor stops and missed sensor events The fault affected control behavior before engineering access was lost.
Connection attempt The software reported that the selected PLC profile did not correspond to the controller. Confirm the actual controller identity and loaded target before treating this only as a network fault.
Hardware inspection Capacitor C27, marked 100.0 uF and 35 V, was swollen and replaced without restoring operation. C27 was visibly defective, but replacement did not resolve the reported fault; it is not proven to be the sole cause.
Firmware attempt Programming failed near the end. Do not assume that another firmware attempt will correct the underlying condition.

What the Boot Log Confirms

The affected controller reports OWEN program loader 1.3, binary version 2.15.3, required target version 2.10, IP address 10.0.6.100, gateway 10.0.6.1, and mask 255.255.255.0. Power status is reported as OK, DATAFLASH reads successfully, and the file system mounts.

The same log also reports four bad flash blocks, a maximum wear level of 54, ERROR: Loading parameter manager info, an invalid channel entry where channel 2114 must be 2012, and missing templates for module IDs 2003 and 2004. Despite those messages, the parser later reports successful configuration parsing and boot-project loading. The log therefore proves that startup reaches the application-loading stage, but it does not identify which message causes the profile mismatch or failed programming.

Do Not Compare the Two Logs as One Controller

The second log belongs to an analogous replacement controller used for the programming attempt. It reports binary version 2.14.0, IP address 10.0.6.10, zero bad blocks, a maximum wear level of 5, and ERROR: Can not open Checksum file. These values differ materially from the first log.

Evidence Affected controller Analogous controller
Binary version 2.15.3 2.14.0
Required target 2.10 2.10
IP address 10.0.6.100 10.0.6.10
Bad flash blocks 4 0
Maximum wear level 54 5
Application-stage error Parameter-manager loading error Checksum file cannot be opened

Because the logs describe different devices and software states, do not use the second controller's successful hardware startup as proof that the first controller is healthy. Likewise, the checksum-file error on the analogous controller does not establish the cause of the original connection failure.

Diagnostic Decision Path

  1. Identify which physical controller produced each captured log. Record its PLC model, binary version, required target version, IP address, flash condition, and final application-stage message.
  2. For the affected controller, preserve the complete sequence from the intermittent machine behavior through the profile-mismatch message and failed programming attempt. Include the conveyor stops, missed sensor events, loss of connection, C27 replacement, and the fact that replacement did not help.
  3. Escalate the controller for service diagnosis. The available assessment identifies a possible internal inter-board communication problem, but this remains a hypothesis rather than a confirmed component-level fault.

Service-Center Submission and Verification

  1. Send the instrument without mounting hardware or removable terminal blocks.
  2. Include a cover letter on company letterhead with a detailed fault description. State what equipment the PLC controls, the operating conditions, the observed sequence, possible initiating events, and which part was considered defective and why.
  3. Include the warranty certificate when available. If it is missing, the warranty period is determined from the manufacturing date encoded in the factory serial number.
  4. Send the same detailed description to OWEN support at [email protected] and include it with the service-center shipment.
  5. After service, verify that the engineering software recognizes the controller profile, a connection can be established, the intended program can be transferred without an end-of-process error, and the conveyor and sensor signals operate without the original intermittent symptoms.

FAQ

The affected log contains binary version 2.15.3, required target version 2.10, parameter-manager loading errors, and inconsistent module data. Confirm the physical controller and target selection, then submit the complete log for service diagnosis because the evidence does not isolate one cause.

Does “Licence limited to 360 bytes” prove that the PLC license is damaged?

No. The line appears in both captured logs, but the evidence does not define the limit or confirm whether this PLC should be unrestricted. Ask OWEN support to interpret it for the specific controller.

What must be sent with an OWEN PLC to the service center?

Send the instrument without mounting hardware or removable terminal blocks, a detailed cover letter on company letterhead, and the warranty certificate if available. When the certificate is missing, the warranty period is calculated from the manufacturing date encoded in the factory serial number.

Back to blog