I already know that with klipper I would need to use generic heater to reference the multiple heat bed zones, that isn’t my current problem.
I am migrating from Marlin to klipper for various reasons, but also due to reliability on long prints. Previously I controlled the heat beds over I2C from the printer board with a few custom G-Code mods inside of marlin in order to send and update each heated bed appropriately. The current custom board is running an ATtiny828 with only I2C and programming headers broken out.
I am having issues finding good documentation on I2C with klipper and if I will need to connect the board directly to the pi or if I need to still connect via the printers board. I am also wondering if it may be better to upgrade the mcu on the heatbed controller to say STM32F042F6P6 and add it as an extra MCU and have PID etc handled by klipper instead of the extra board?
If I go with I2C I am assuming I will need to write an extras module to handle the processing of data to and from the board?
Yes - one would likely need to write an “extras” module to control an external i2c device. Examples would be sx1509.py and replicate.py (the pca9685 code).
Thanks for the info, do you know how well klipper handles things like communication timeouts etc since I wouldn’t necessarily want the print to fail due to a single failed transmit/receive. Also would it handle it better from the pi directly or could it be okay with going through the printer main board? Sorry I haven’t found a lot of info on I2C for Klipper. I am leaning towards an extras module since finding certain chips has been a bit of a pain right now and I am unsure how some of the Chinese clones of the chips (like the blue pill chinese chip) would perform if at all.
Yes but it doesn’t have enough adc pins on chip as I would need 8 adc and 8 digital outs to drive MOSFETs for the beds. I looked at the rp2040 but I saw it only had 3 available channels.
To update this thread, it looks like I will be changing the MCU to an ATmega328P and/or making a new board to take an Arduino Nano insert depending on chip availability. This way I can work directly with klipper as an extra MCU to eliminate issues with I2C and noise. I kind of got it working with I2C but it was not consistent enough to be reliable long term without having it controlled by a separate app and talk via the API to update.