Making tapered cuts on a DIY wire EDM is what every fan of EDM wants to do. And even people who don't want to make fancy cuts may like to have the option to cut some small chamfers.

The current G-RBL firmware does not support it but the next release will.

The hardest part is to tell grbl what a U and V axis is. Maybe not the hardest part but it isn't easy.

GRBL does not know the name U and V. It requires changes to the gcode parser and some config objects. That alone isn' sucht a big deal. But there are other places where axis names are hardcoded and the deeper I looked at the code the more it felt like there are too much limitations and if it is changed at such a deep level it should be done right.

The goal was to have a config object where all the wanted axes are defined. The order should be flexible. In grbl the axis order is hardcoded. XYZ equals 012. There is also heavy use of the max possible number of axes in grbl even if they are not used. And this is heavily integrated and hard to get rid of. The settings write the positions as one blob to the NVS storage. if they are loaded and the receiving array size changed it would break things bad. Or if the order is changed it would also break things.

Instead of rewriting the parts it was much easier to just fully replace them with something less complicated and non persistent.

Short story short: The next release will have the axisdefinitions in a config object without caring about the order and also have UV support. All the dependencies on the virtual maximum number of axes are gone and it freed a few percent of the memory. 3 full files where removed from the grbl part and the files that are left barely contain anything.

This is how the axis configuration looks now. If one axis is added it will flag the axis as enabled. The names are still not user defined. XYZABCUV are available names. The axis index is dynamically set based on the position in the config object.

And a few small changes in the gcode parser:

The code will not support multiplanar synchronized arcs yet. XY and UV are two different planes in theory. But executing arcs in parallel would require deeper changes to the parser, the arc function and also the planner.

I'm working on it. For the beginning it is not needed and from what people told me LinuxCNC also does not provide multiplanar synchronized arcs. So it will be fine.