Thanks ben, really appreciate the offer to help, and the RD 3210 pointer especially.
Direct answer on RD 3210: it reads 1 on our unit. So RS 3210 doesn’t apply to us, the active-station bit is already set, and the overrun reproduces with it at 1. Read-only survey, carriage sitting at the distal end:
RD 3210 active-station flag = 1
RD 101 Omron distal prox = 1 (carriage at far end — position endstop)
RD 100 door-side home switch = 0 (never asserts on our slide)
RD 1813 EX-14A optical detect = 0 (no plate/target present at rest)
RD 1807 second detector = 0 (no sensor feeds this input on our build)
RD 1814 error flag = 0
RD 1915 ready bit = 1
RD DM200 handler error code = 00000
One heads-up for anyone following your STR240 register list: on our STX220 the home/end switches are read at the input number directly (RD 100 / RD 101), not in data memory. RD DM100 / RD DM101 on our unit are unrelated static data words (28294 / 02958), not the 0/1 endstops, so the DM100/DM101 addressing doesn’t transfer between models, but the active-station flag RD 3210 does.
The behaviour, captured. A full re-home (ST 1900 → ST 1801):
ST 1900 → OK
ST 1801 → OK
t= 0.0s RD 1915 ready=0 RD 1814 error=0
…
t=45.2s RD 1915 ready=0 RD 1814 error=0
t=48.2s RD 1915 ready=1 RD 1814 error=0 ← reports DONE, no error
The carriage creeps to the door-side reference (correct), then shoots out to the distal end, and the motor keeps driving into the hard stop. However, RD 1814 never sets, and the handler reports ready. It then just sits at the far end; it never reverses to return the plate to the door.
What we think the issue is:
The slide travel distance is hardcoded in the firmware and runs open-loop. The key point, and we verified this directly: the PLC does see the distal endstop, RD 101 (the Omron) reads 1 the instant the carriage reaches the far end, and the motor drives straight past it anyway. So the stop isn’t gated on that sensor at all; it just runs its programmed (pre-cut-rail) distance. Plate presence is a separate input (RD 1813, the EX-14A optics) and is likewise not consulted to stop or reverse the motor. We cut our rail to ~38 cm to mate with a Tecan EVO and relocated the endstop to the new far end, but because the firmware ignores it and runs the old, longer distance, the carriage over-drives past the shortened rail into the hard stop and never reverses.
What we’ve ruled out: The bare slide-jog relays ST 1110 / ST 1111 from the Java driver are unmapped on our firmware build, as indicated by an OK returned but zero motion, even after a full re-home (details in our reply to jnecr above). And the composite import/export (ST 1904 / ST 1905) only takes carousel/cassette geometry params, not a slide-stroke distance. So we’ve confirmed there’s no serial command that moves the slide a tunable distance, the travel really does live in the .cod.
This puts us right where you were: it’s a firmware travel reconfig. We bought ours used as well, so we’ll push Liconic on it as you suggested, but they will do the same to us. Your Raspberry Pi bypass is a great option at the moment. Thanks again, this thread has been hugely useful.
).