One of the keys for a good EDM process is the motion management. My goal is to create an easy to use and easy to build 3 to 4 axis CNC EDM mill.

But what are the options?

ESP32

For a single axis sinker EDM the ESP32 works very well. But the more axis it uses the slower the final axis speed will be. The ESP32 won't allow parallel motion where multiple axis can move at the same time. EDM doesn't need much speed so that could still work good enough.

But also access to the SD card is a problem. It pauses the process and takes some time to read GCode.

Marlin with 3D printer board

One option would be to create a marlin fork. This would match many of the G-EDM goals. Most people could use the boards they already have in their printers and just flash the custom firmware onto it. But it has downsides:

Marlin is a very complex software. Hard to get into it, but still doable. Marlin is also 3D printing specific and I would need remove most of it to create a pure EDM Marlin fork.

Now another problem. The boards many people already have in their printers support steppers up to 1.4A. This is the case at least for the Silent Enderv2 board.

This would work for most people but it is a limiting factor. For example: The Nema17 steppers of the G-EDM are rated 1.69A.

Klipper

What about Klipper? I haven't worked with Klipper yet but it looks nice. From my understanding Klipper uses some kind of serial communication to control other boards? This is a problem with EDM. Serial Communication next to the sparks created by EDM won't work reliable until everything is shielded.

NanoPi Neo with custom software

The next variant would be really specific and custom. Using a NanoPi Neo with a custom homemade software. Maybe a QT-Application.

This would allow me to reuse the code I already have but it won't reach the goal of making it easily available to everyone. The NanoPi Neo is exotic and a little outdated.

But it may be possible to adapt the code to other boards too.

It is hard to get the ILI9341 touchscreen to work with it. There are no device tree overlays in the wild that support a shared SPI with two chip selects. And this is needed because if touch and the screen don't share some pins there won't be enough GPIO Pins left to wire up everything else.

I talked with two friends about this. One just said: "Yes" The other said: You will get the display working!

:D It is tough.