The problem
The Delta DVP panel was sound and the ladder ran its full fill cycle on every scan, but the Raspberry Pi supervisor written by an earlier engineer never reached the controller. Every Modbus call timed out. The site team had spent weeks on cables, converters and the Pi itself, and was talking about scrapping the supervisor and going back to a dark HMI nobody had the password for. The constraints were plain: do not touch the ladder, no rip and replace, and every fix verifiable on site against panel labels.
What I did
I pulled the ladder export and walked it rung by rung: the STL states from idle through feed, position, dual head top off, withdraw and discharge, the counters and timers, the per head enables, and the separate Modbus master loop that writes conveyor speed to the VFD over RS-485. Then I cross checked every address against the C++ headers. Two problems surfaced, neither visible at the wire.
The PLC's COM1 was in ASCII framing while libmodbus was speaking RTU, so no handshake could ever complete. And the address map used the wrong base, so writes that should have reached the M coils the ladder reacts to were silently landing on the STL state bits. I switched the port to RTU, rewrote the map to Delta's standard bases, and demoted the Pi from sequencer to supervisor.
It now starts the cycle, watches the running flag, reads the produced count, writes recipe values and logs batches. None of the safety timing lives in it.
Decisions that shaped it
- Walk the ladder before touching the code.
- Fix the framing first. Nothing else can be tested until a handshake completes.
- Rewrite the address map to Delta's documented bases, so writes land where the ladder listens.
- Keep the PLC as the safety authority. The line keeps running if the Pi is unplugged, and the key switch and E-stop still gate the start rung.
Result
Deployed and running on the line. The operator kept their panel, their ladder and their VFD loop.
