EtherCAT reliability and diagnostics improvements. The controller now recovers from a drive communication interruption (for example a disconnected cable) on the first attempt, in about half the previous time. The root cause of the failed recoveries was found in our own software: it was rejecting valid messages from the drive because it assumed the drive numbers its messages the same way we number ours. The official EtherCAT specifications say the two numbering sequences are independent, and the drive was following the rules. The message handling was corrected to match the specification, and the drive error-clearing procedure was rebuilt around the specified completion signal. The controller also no longer wastes processor time waiting for network responses (it is now interrupt driven), procedures that used to be able to wait forever now have time limits, and the serial log now reports lost or repeated drive messages so field problems of this kind can be diagnosed from a log capture instead of a bench investigation.