Arduino Based Auxiliar MCU

Basic Information:

Printer Model: Custom
MCU / Printerboard: SKR V1.4 Turbo + STM32
Host / SBC - RPi 4B
klippy.log - N/A

Hello!

I’ve been working on a project regarding an alternative control logic for the E-stepper to improve print quality (PA alternative) as my engineering graduation project.

In my current setup, the E-Stepper is controlled by an STM32+TMC2209 (working with Arduino IDE code for STM32). I implemented the new stepper logic on the STM, and I’m reading the pulse+dir pins from my printer’s board to get the desired E-Stepper movement. I also read some sensors with the STM32, which are used to improve the stepper movement.

It worked OK so far but I’m looking forward to improve the communication between the two boards by including the STM32 as an auxiliary MCU for Klipper. Since all motor steps timing are pre-calculated by the Pi, it would be beneficial for my project to have access to it before the execution itself.

I would still like to have the STM32 firmware compiled by the Arduino IDE, so I would switch the USB back to the PI after uploading the code.

As I understand I would have to translate the C-code from Klipper src files to my Arduino code, but I’m not sure if there is something fundamentally wrong with this idea and wouldn’t be worth trying.

Do you guys think this is feasible? Have you seen anything similar?

Thanks!

I’m not sure if this is the right approach when using Klipper:

  • Klipper essentially is a host application that intrinsically communicates with a MCU application and only both together is called Klipper
  • There is kind of a “protocol” between the host and the MCU application, that handles all the timing relevant aspects in this communication
  • The details are at least a bit fleshed out here: Protocol - Klipper documentation

It is up to you how much sense it makes to replicate / tweak / modify this within the Arduino IDE.
The “way of the Klipper” would rather be a host module that does the heavy lifting of the logic and then hands it over to the MCU controlling the extruder for execution.

2 Likes

Hi, thanks for the reply.

I understand that the right way would be to have the host to process the stepper logic and just send the commands to the controller.
I’m just trying to find the easier way of implementing my controller to have a functional prototype and verify performance. I don’t have a strong background with software, so I’m trying to keep as high-level implementation as possible for now. Then if I get good results, I could spend the time with the correct implementation and share with the community.
Ideally, I would like to have access to the protocol commands with the STM32, as mentioned on the documentations, but as I understand the Serial communication is encrypted for efficiency right?
I don’t intend to send any other command other than the E-Stepper commands, so I can process the desired velocity for the filament from the host and implement a closed loop controller based on real-time flow estimation.
Since I got good results (equivalent to PA, with automatic gain calibration) by reading just step and dir pins, I think it can be even better by having acces to the step commands prior to execution.

Well, this is exactly what Klipper is about:

  • The MCU only receive processed commands and executes them. The processing is done on the host
  • If you want to access the “raw” steps before being send to the MCU then you need to do this via a host module

Imagine, one would send your controller steps that already “contain” Pressure Advance modifications because the host calculated them in and then your MCU code puts another similar modification on top. This probably would lead to pretty much unpredictable results.

As it stands: Klipper host calculates and Klipper MCU executes. Working around this basic philosophy probably is a bad idea.

But then again, I’m not a core developer, so I happily stand corrected.

EDIT:
To add: you might also greatly profit from the tools that Klipper is providing, e.g. the so called MOTAN tools that allow in-depth analysis of the motion commands that Klipper host has calculated.
This might come in very handy during your development and to see, what is going on. See for an example Regression in dynamic PA - #7 by dmbutyugin

1 Like