Cellares Cell Shuttle

Cellares — Lead Controls Engineer

The Cell Shuttle is Cellares’ automated manufacturing platform for cell therapy production — CAR-T and similar therapies that are currently made largely by hand, batch by batch, in a process that doesn’t scale well. The machine runs the process inside a self-contained ISO 8 cleanroom enclosure, processing up to 16 patient batches in parallel through a consumable cartridge system, with integrated bioprocessing instrumentation and material handling to move cartridges between process steps. More detail on how it works is on Cellares’ technology page.

Since 2022 I’ve worked across most of the machine’s control and safety systems. The core is a Beckhoff TwinCAT PLC running the process logic over EtherCAT, with a TwinSAFE safety program handling e-stops, guarding, and interlocks for the robots and cleanroom access. Material handling inside the machine is done by Stäubli six-axis robots, programmed in VAL3, that move cartridges between the process instruments, refrigerated storage, and the machine’s external transfer point.

Day to day, that’s meant PLC and safety program development, robot motion and handshaking logic between the robots and the PLC, EtherCAT device integration, and a fair amount of design and code review as the controls team has grown. It’s also meant a lot of on-site commissioning and troubleshooting — this is industrial automation applied to a biotech process, running in real labs with real operators, and the two disciplines don’t always agree on how something should behave.

The controls team was three people when I joined and has grown to ten. In that time six Cell Shuttle units have been built, each running two robots against a PLC with roughly 150 EtherCAT devices on a 10 ms real-time cycle. The System PLC’s structured text logic runs to about 56,000 lines across 527 program blocks; the robot application code, in VAL3, is another 30,000 lines across 540 programs.

Two robots, one workspace

Each Cell Shuttle carries two robots on a shared rail, and their reach overlaps at the machine’s Sterile Liquid Transfer System instruments — both robots need to enter the same physical space to do their jobs, just not at the same time.

At the lowest level, the two robots talk directly to each other over TCP, and if they both end up in that shared “danger zone” at once, both stop immediately — a hard, unconditional interlock, because getting that wrong means a collision. The problem is that rule alone creates a catch-22: if both robots are stopped because the other is in the zone, neither can safely move to get out of it either. Two robots can end up simply stuck, each correctly refusing to move into space the other occupies.

I solved it by moving zone ownership up to the main system PLC instead of leaving it purely between the robots. Each robot now requests ownership of the danger zone before entering and releases it on the way out, arbitrated by the PLC, so only one robot is ever cleared into the shared space at a time and neither one can end up deadlocked waiting on the other. It’s been fully solved since.

A custom I/O interface board

One piece I’m particularly proud of is a custom I/O interface board I designed for the machine. It sits between the field devices — sensors, actuators, instruments — and the Beckhoff EtherCAT terminals, breaking each connection out to a labeled M12 connector and giving the panel a set of status LEDs (device power, logic power, run, safety, comms) that make the state of that section of the machine readable at a glance instead of requiring a laptop and a fault log. Designing your own hardware isn’t the usual day-to-day for a controls engineer, but it made wiring, commissioning, and field troubleshooting noticeably faster once it was in place.