Thanks so much for all the pointers @jnecr . It appears they’re both dead ends, which is at least conclusive.
setCarsOffSet() is just a field setter (this.carsOffSet = val), no DM write. The field is a carousel slot-index offset: it’s added to the requested slot to compute shovelslot, which is then written as WR DM0 . It only remaps slot numbering for the dual-carousel (10/20-slot) geometry and gets reset to 0 at the top of every load/unload, so it’s a slot count, not a travel reference. No transfer/carriage variant of it exists.
CassetteConfTable turned out to be an immutable holder with exactly four fields, Id, Levels, Z-Pitch, BCZ-Pitch, loaded from an XML device config ( blocks), not JSON as I’d guessed. WriteZPitch just pushes Z-Pitch → WR DM23 and BCZ-Pitch → WR DM27, i.e. the carousel’s vertical geometry. No transfer-station or slide-stroke entry anywhere in it. And DM25 (shelf count) is read-only from the host (RD DM25), nothing writes it, same for DM29 (max slot) and DM46 (carousel position), so the firmware owns all of those.
So both leads close off the same way: the carousel exposes its geometry over serial, but the slide stroke isn’t stored anywhere the serial interface or the config files can reach — it’s baked into the .cod. That puts us back on the firmware-reconfig path. We will probably do the same as how @ben solved it with a Raspberry Pi with full control.
I’ve never used a Liconic with a conveyer transfer station but I have used Cytomats with them and I’m 99% positive the hardware is the same. The behavior I saw with the Cytomat conveyers was when the plate triggered the plate sensor you mention that is a few centimeters from the end the conveyer would begin to slow down and run for a set amount of time. I’m sure that amount of time was in the firmware for the conveyer but I never had a need to mess with it. We also converted a Cytomat from a static transfer nest to a conveyer transfer and the only change required for that was setting a flag in the Cytomat’s firmware. Looking back I assume now that the Cytomat firmware just needed to know that it should trigger the conveyer to do it’s thing once a plate was set correctly on the nest. I don’t believe any of the actual movements for the conveyer were set in the Cytomat firmware itself.
Our STX does none of that: it runs a fixed open-loop stroke, drives past the end sensor into the hard stop and grinds, no slowdown, no error. The motor’s a 4-wire stepper, so it’s just over-counting steps on a rail that was cut shorter.
We metered every sensor against the PLC, and they’re all live and visible, door Saia → RD 107, far Omron → RD 101, optical plate-detect → RD 1813. The controller just never acts on them to stop the slide. That matches your “it’s a firmware flag” point exactly. We also found a LiCONiC connector doc that says it outright: “Default: station motion activates on every access. Remote control via ST 1912/RS 1912 — for that, you need to change the firmware.” So the sensor-gated mode exists, but flipping to it isn’t host-settable; it needs a firmware change, which Liconic wouldn’t do (for used second-hand units)
So, to anyone chasing this issue. There is no solution whatsoever other than to completely liberate transfer station movements with a Rasbery Pi as Ben did (unless you have bought the unit from Liconic directly).
