Okay can someone break down what would need to happen to get klipper running on a jackpot? Like 5th grade level explanation first.
I am assuming there are two issues. 1- the host “firmware” doesn’t support an esp32? 2-the TMC expander chip we use?
How freaking cool would that be though.
Whoops I should have searched first. Why is Klipper not compatible with ESP32? - General Discussion - Klipper
Lookie there, I have even seen that thread, Jeffeb3 wrote the third reply…
So if you strapped on a raspberry pi and used the esp 32 as a basic USB microcontroller, it in theory could be done, but there would be no esp hosted web page… Kind of pointless to use the esp32, unless you wifi bridged them over wifi. But that could be a nightmare if connection became an issue during a cut. Too bad the pico isn’t pin compatible with the esp32. That could be a tethered board running klipper, but in either case there would be some firmware development required.
Don’t you connect to the pi for klipper and the jackpot would be tied in over USB to the pi? You never actually connect to the host board on a klipper install right?
Once you flash the basic Klipper firmware on to the host board then the Pi does everything with it from then on out. Some boards you flash direct from the Pi others like the SKR you put the klipper.bin on an SD card, rename it firmware.bin and flash just like we did marlin
The jackpot brain is the esp, so you’d have to use it but over usb. The web page is hosted by mainsail on the pi with Moonraker that communicates with klipper on the jackpot.
My point was that the wifi advantage of the esp isn’t needed if it is USB tethered and the web server running on the raspberry pi makes it unnecessary so a different controller option might be an approach, but maybe not practical as it sits.
What would you be looking for in klipper that fluidnc cannot do??
Run a 3D printer, MP3DP v5.
Oh gotcha.
So you figured out esp32, i bet you can figure out arduino for klipper ;).
That sounds interesting. Need 6 channels, so the skr1.2 is a possibility, though with can bus, you only need 5 plus the extended / remote part.
With Klipper, the microcontrollers are just peripherals to the controller. Need 12 steppers, use 2 Jackpots. Similar with all the other IO. It’s “just IO”.
I’d imagine on Klipper that you’d deliberately turn off the Wifi on ESP32 and use both cores as needed to run the IO.
I guess I"ll need to read that thread now. Klipper on ESP32 on Jackpot woudl be AWESOME.
Jackpot has 6 channels and is a lot less expensive.
Sounds good!
Dagnabit, now you got me even more excited.
I totally think it could be done, but you will disable some of the board capabilities to do it. Oh yeah, you can have klipper take dual or triple usb devices and just run them together.
I was just reading about how with the processing done on the pi, the 32 bit controllers are overkill for klipper and the older 8 bit ones work just fine.
The expansion IO part of the Jackpot could be an enabler.
Maybe, depending on how testing goes with Marlin + expander on Jackpot, a 3D printer module might make sense.
It might also make sense at some point to add a header on the jackpot to get access to the GPIOs currently used as endstops- but as a potential expansion module interface.
But first things first, thinking about modules and development steps.
I really think the WiFi / Web UI part of the original discussion was something of a red herring. Inside the ESP32, WiFi is just another interface. The microcontroller is cheap and powerful, so just shut off the wifi and use the microcontroller as a microcontroller.
The other red herring was the original discussion of limited IO. The IO expanders as used on Jackpot and the MKS boards make that a non-issue as well.
So if ever there was a good time to revisit whether Klipper on ESP32 made sense, it is now.
There are multiple ESP32 boards on the market that would be very usable as expansion IO under Klipper.
So i just googled and klipoer does not look at esp32 yet, from what i saw, but i did see mks skipr on aliexpress the other day and it is supported. I have not had any problems with my tinybee.
MKS SKIPR uses the RK3328 as a processor like what you get with the Raspberry PI, and the STM32 MCU is the microcontroller (And, isn’t an ESP32). Sort of a Pi and SKR board built all-in-one.
It’s like the BTT Manta board, except with a soldered-in RockChip processor instead of a board-to-board CM4-compatible interface.
On the other hand, MKS TinyBee is an example of a board using the ESP32 and IO expanders.
Correct, i just found out about the skipr having logic. Surprised!! I am watching this https://youtu.be/-Coa-w77cWo?si=ECeZaIyE3E-WgXK2 right now. Tinybee is fluidnc on my mpcnc with 8825s, but ryan wanted klipper. Oh and it has canbus
Easy enough…
Ok this really would be awesome! I know it will run Marlin, Jamie has already proved that. But as much as I love the jackpot board I’m not going back to marlin to be able to run it. Now if we can get it to run klipper consider me sold!!!
Just one point here. Moonraker communicated to klipper on the pi. And klipper on the pi talks to klipper on the mcu. Klipper itself is independent of moonraker and mainsail and all of that. The genius of klipper is the coordination between mcu and the klipper host that runs on the pi. It enables so much comparability and rapid development.
That thread pops up with a new reply every once in a while. I admittedly disagree with myself and that third post. It should be easy and useful to do.
I would completely ignore the wifi and BT capabilities on the ssp and just treat it like a really fast dual core microcontroller. Because it is. It is still faster than a pi pico or skr microcontroller, even without the wifi/BT. The one Achilles heel is the gpio, but the jackpot expander fixes that.
The good news is, writing mcu software for klipper is one of the easiest tasks in all of this. If you know Marlin, you basically only have to write the HAL layer. The rest is done in the pi. The protocol to talk between esp and pi is well defined.
The bad news is, to make it good, you still need to be decent at embedded programming. And they have been pushing for some reusability in the mcu firmware. So it would not be blessed by the klipper mcu maintainers (probably). Near the bottom of that github thread, there are some people determined to try it. But I haven’t seen any success.