@spike, the existing controller is really dated and not entirely designed for the specific application. I would classify the Rambo as a “firmware development PCA” for printers. Not a professional design for the lulzbot.
There are a lot better stepper drivers these days. More aggressive microstepping can allow for more precise stepper motor control and smoother movements. The existing Rambo board also doesn’t support encoders. For something that moves continuously for days really should have some feedback to be used to detect if the nozzle was bumped off so it can reset and retry the print. Or automatically abort.
The thermistors are just being read directly by internal ADCs on the micro and are being used to change a PWM output of the heating elements. This really should be an analog circuit where the microcontroller sets a voltage setpoint through a precision DAC and then an analog PID to do the actual control. This is significantly faster and more precise.
It doesn’t even look like the micro has a POR. Nor are the voltage rails being monitored.
There really should be two processors on this and some form of off-chip memory. That way the primary communication processor handles commands and debug information from an external source (your PC, a Pi, etc). Then loads the gcode into memory and then the motor control subsystem micromanages the stepper motors and DMAs the commands from memory. This allows for much tighter control loops.
Then the communication processor can supervise what’s going on. The temperature control should be “set and forget” using a DAC and an analog PID, but the processor monitors the whole system makes sure everything is in bounds, monitors the actual position of the motors with encoders, and can stream debug/system information much faster and more precise without bogging down or disrupting motor control. It’ll also allow for more up-to-date information in CURA. For example you would then be able to monitor the exact layer count and nozzle position in software. It also facilitates much more improved quality control and customer support since you would be able to set error codes more tightly (and more detailed) and have the entirety of the system monitored. Being able to see EVERYTHING that’s going on in numerical data has helped me a lot in troubleshooting significantly more complex systems by just remoting into the control software and watching the data. It also helps for QC when building so you can do automated routines for calibration and configuration. Plus more detailed POST routines on startup.