That was a bumpy ride and I learned much about why most OpenSource Motion controllers just won't do very well with EDM.

It doesn't matter if it is Marlin, LinuxCNC or GRBL. They all use some kind of step buffers to store prepared blocks with step instructions. This is a good if things should run fast and the process is static.

But EDM has different requirements. We don't need a fixed feedspeed or fast feed rates. Instead the speed should be handled by the sparkgap. Also it needs realtime position adjustments and fast reactionspeeds.

It should be possible to use them for WireEDM. Slow speeds and a constantly moving electrode will help a lot.

But it is far from perfect. Let's take GRBL for example. It uses a step segment buffer and a planner buffer. Each block in the segment buffer seems to hold a maximum of 80 steps.

Even with rapid feedholds and resumes the worst case is that it does 80 steps until it stops From my experience with low voltages the difference between a nice spark and a short circuit can be as low as 10 steps and  less with a step resolution of 4096 steps/mm.

Also acceleration and de-acceleration is a big problem.

But to keep it short: I was able to change GRBL and get a stable spark gap.

It was hell to do and still is. The footprint of the compiled code shows how massive the changes are.

The original GRBL codebase uses 23% RAM and 93.3% Flash memory:

The fork uses about 6% RAM and 23% Flash memory: