The Trigorilla v1.0.4 used in the Kobra series (Anycubic Kobra, Anycubic Kobra Plus, Anycubic Kobra Max) has a serious hardware bug: It looks like last minute Anycubic swapped the extruder TMC2209 for a TMC2208 but didn’t update the address pins on the board. This means the extruder and X axis both use address 0. This creates an interesting situation where we can write to the controller registers but reading will cause a bus conflict.
Currently Klipper insists on reading registers from the controller to confirm writing was successful and to check status when there’s an error driving it. Both of these aren’t entirely necessary for the printer to work, which is why Marlin works on this board.
The controllers will always stop on error or host overload on error, and writing to registers seems fairly reliable in practice. Furthermore the only time we actually need to write to registers is for sensorless homing which happens once during the printer’s on cycle. All other activity is controlled using pins not conflicting.
Supporting these printers in Klipper has to be done in one of three ways:
- Not at all: These boards are broken, people can use other printers
- Requiring microsoldering: People will have to modify their board to fix the bus conflict and break compatibility with stock firmware.
- Software workaround: Developers will have to add code to workaround this issue and run a somewhat sub-par Klipper experience
I originally opened a PR to discuss a software workaround with a proof of concept here: WIP: Support broken TMC boards on the Anycubic Kobra by Jookia · Pull Request #6091 · Klipper3d/klipper · GitHub But I’m genuinely not sure which way is the path forward for Klipper with this board.
I will be maintaining a fork with a software workaround while I use this printer so users could just use that.
I’m interested to know what should be done here from Klipper developers.