I’m curious to know if Klipper accesses the serial I2C EEPROM built in to most Main Controller Boards like:
Marlin definitely uses it for the printer’s configuration, but as far as I can tell Klipper doesn’t.
I’m not sure if this belongs in “Developers” or here in “General Discussion”.
Thanx!!
No - Klipper doesn’t use the EEPROM on any board or chip today. One could access it, of course, but I don’t know of anyone who has done that (nor any particular reason to).
Cheers,
-Kevin
A pretty huge use case popped into my head reading this (starting out with the most trivial example):
Part of Klipper’s configuration could be stored in this EEPROM, just the part specific to that particular device. It could be brought into Klipper in a similar way to how the include statement works.
With this, printer add-ons could be made plug-and-play without having to go back and edit your configs.
For example: Plug in a Pico with an ADXL345 and the system automatically is configured to be able to use that chip. Unplug it and that configuration is removed (so it doesn’t fail with an error trying to access the chip).
Triggering the reload could be manual at first, by resetting the firmware.
Later, USB plug/unplug detection could be used as a trigger for the reload.
The method I use for the exact case above is to hand-edit the config file each time to uncomment/comment-out an include statement for the accelerometer then restart the firmware.
That’s just one very minor example though, as this could be used for anything.
I don’t know how much work would be involved to import configs live, but if that could be done, then the system would be able to plug/unplug additional heads (extruder+heater+thermister+fans) on a multi-head printer without having a limitation on the number of heads imposed by the electronics (think a tool-head carousel, like on an industrial CNC machine).
Imagine a machine that only has the electronics for two heaters+thermisters being able to swap out the idle head for a different one for the next tool/filament change, the number of filaments would only be limited by your physical add-on that performs the swaps. You could even conceivably include things like the pressure-advance needed for the filament in that head (I’ve done combo prints with PETG & TPU in the past and had to hand edit the GCode to swap pressure-advance configs during the filament change).
This way, aside from being just all-around more user-friendly for everyone who might add/remove hardware to their machines periodically, manufacturers could provide devices that are automatically supported by Klipper without Klipper having built-in support for those devices. 
FWIW: I’ve wanted to do the connect/disconnect head-swap thing for a very long time, but currently it’s impossible in Klipper. That is, unless I missed some significant development (very possible).
What you have described here would be appropriate for Marlin but not for Klipper.
The Klipper firmware facilitates (for lack of a better word) printer hardware operations. It is configured for the MCU it is running on as well as the communications method with the host. There is one more case and that is whether or not it is being used as part of a CAN network but that’s it. Communications from the host command it to carry out a specific hardware IO function (ie “Turn Stepper 3 140 steps clockwise”) but nothing in it specifies the actual printer hardware connected to it.
The actual configuration (ie the printer.cfg) is located in the host system (ie Raspberry Pi) and this is what needs to change when the hardware connected to the MCU changes.
I don’t get your comment about Marlin, as Marlin cannot use multiple MCUs controlled from a single computer, which is a prerequisite for the point of my post.
Yes, I understand how Klipper is configured. I’m the one who wrote the initial howto post on how to get the Pico working for the adxl345, how to wire it, and how to configure Klipper to use it.
https://www.reddit.com/r/klippers/comments/owqvo2/raspberry_pi_pico_as_a_secondary_mcu_for
And yes, I’m aware of CAN bus, I got it working in a build with both a HAT based host adapter and a USB one. My comments could also be applied there for the same reasons.
koconnor already replied that accessing the EEPROM was possible, so I don’t know why you’re trying to say that it’s not.
My response was directly addressing Kevin’s statement that he’s not aware of any reason to do so, so I suggested one that would not only be appealing to users, but also companies who are adopting Klipper.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.