ESP32 is powerful enough to let you kill Demons and Nazis, via Doom…
6 Likes
Not an expert on that matter but I think that one is the elephant in the room. How to get microsecond sinchronous start signal over Internet? … That would neat I must say.
2 Likes
Again. It is powerfull. A Ferrari is powerfull but off-road I would rather have the power of a Humvee. Again my personal opinion (and maybe faulty).
This would be much nicer with some input from Terjeio or Bart. They are 2 of the most experient guys in this matter Imho.
EDIT: talking about raw power check out the SKR3. It’s not cheap but man this thing must be a beast.
And IO wise the GTR can be expanded to 11 stepper drivers with an additional board. The board itself looks like an SKR Pro 1.2
3 Likes
I would think klipper’s clock sync should work over UDP (presuming klipper works, or can be made to work over UDP at all).
Maybe ROS can do something here (@jeffeb3)? But I think ROS needs an ARM minimum and can’t run on AVR.
1 Like
Latency would be too wild, and not deterministic. 10ms is pretty common latency in a local wired network. Internet is much worse, at least 100ms.
Klipper syncs the clocks and then prepares motion primitives (in the form of speed trapezoids, which are very clever). As long as there is enough of a buffer, it can handle any latency, but the clocks have to be synced.
I think I remember things like sntp have a 1ms spec for precision.
Interesting problem. Pretty hard. But not impossible.
2 Likes
Exactly. The thing is the kick start. Arduino UNO can do up to 30 steps in 1ms.
I don’t know how Klipper does it’s magic in depth but I believe the fine (µs) clock is handled internally by the microcontroller and executes the motions stored in an internal buffer. Windows or Linux (most versions) are not IO and time deterministic systems. You get access to the resources in an allocated time that can vary by milliseconds.
Microcontrollers don’t have that problem (mostly). You set an hardware timer to fire at a given point and it will do just that.
2 Likes
Yeah. Klipper uses a buffer and syncs clocks with round trip pings.
The mcu doesn’t compute much though, the kinematics are computed in the pi. The buffer stores these neat trapezoids for speed profiles:
https://www.klipper3d.org/Kinematics.html
The protocol is pretty interesting too:
2 Likes
There is also a different 2.4GHz wireless standard supported by espressof called “Matter”: How to Use ‘Matter’ on ESP32 | Espressif Systems
That might be much lower latency. At least low enough to get the sync pings. I don’t know if you can do any wifi or BT if you have it enabled though. I have been meaning to play with it. I have way too many esps on my regular wifi router 
1 Like
Thanks. I’ve read that. I think the main difference between Klipper and the others, is that iteractive solver (newton raphson or something of that sort) to calculate exactly when the stepper should pulse. Others like Marlin or Grbl use a sort of riemann sums to aproximate the trapezoidal acceleration profiles
The microcontroller only acts as an IO interface with an internal clock… Or so I think
Nope. As I was digging through posts trying to get the card recognized, I saw that it is not capable of sending gocode for some reason even when it does work. From what I can tell at least. The details are unclear since the V3 is still in Alpha testing. So SKR boards are still easy, the Rambo’s only chance for headless would still require an LCD to hold the SD card. bummer.
1 Like
The headless is fantastic. The problem is boards that don’t have an SD card built in headless won’t work. Like the Rambo and mini Rambo.
I was hoping to use espui with the esp32cam to utilize the sd card port that is on board.
Have you looked at version 3-alpha of ESP3D?? It looks to me like it supports SD card.
That is the one I was using. The SD can be enabled but in one comment Luc mentions it can’t be used to run gcode.
I’ll triple check. I never actually got the SD to work so maybe…
1 Like
Ahh ok. Maybe they will later implement it. It would be a shame not to be able to do it like that.
It may be possible to connect the rambo spi bus to the esp32 sd interface to allow the rambo mcu to directly access the sd card on the esp32 module. Something like:
- Rambo sd/spi extension header → esp32cam spi (jumper p2 - 2,3,4)
- Disable espui sd access in firmware
- Logic level conversion between 5v and 3.3v
Let me dig into the espui stuff a bit more and at least get the card working to verify if it does or does not serve gcode. Even if we did wire it in we would still need to be able to select it so helping to get esp3d to use the card seems like the best option.
Fresh cup of coffee in my hand trying to decipher the SD card stuff. ESP3D/configuration.h at fa2023fe9483d5b777513ce5774c472dec449bfd · luc-github/ESP3D · GitHub
Okay it looks like it is NOT working yet, but close.
While you guys are making the future happen, I’m wondering why my v1 forum logo icon is shrinking more and more…
I’m sorry, don’t mind me, I’m just enjoying the convo and eating my popcorn! 
2 Likes
Taking notes.
I can see the SD card on a ESP32-CAM finally! I read conflicting information about the settings. I have not tried to serve the gcode yet.
In esp3d/configuration.h I changed;
-#define SD_DEVICE_CONNECTION ESP_DIRECT_SD
-#define SD_DEVICE ESP_SDIO
That is it. My SD card is formatted fat32.
P.S. Found this cool esp32-cam site during my travels, 60+ ESP32-CAM Projects, Tutorials and Guides with Arduino IDE | Random Nerd Tutorials
2 Likes