G-EDM

Just a small update.

All parts for the XY conversion arrived and I'm currently working on the technical drawings for the Aluminum parts.

The images don't show the final arrangement. The linear blocks are raised with 3D printed spacers and the ballscrew is mounted below the aluminum plate.

It uses 500mm HGR20 rails for the Y axis. The aluminum parts are 15mm thick.

Currently printing the parts for the Y axis. It uses 500mm HGR20 Rails and again a 1605 ballscrew.

The linear rails should arrive soon and then it is time to calibrate the software and create the first parts.

Since not everyone is able or willing to spend 1000.- for a tabletop EDM machine I decided to create a second model that reduces the total price tag and opens the world of Hobby EDM for more people.

One of the things that can easily be changed are the big aluminum extrusions.

The only reason I used those big extrusions is because they where available from a different build. They are heavy, large and expensive.

The budget model replaces those extrusion with smaller ones. Instead of the big 120x80 extrusion it uses a 4040 and instead of the 160x40 base it uses a 15180 extrusion.

There will be more changes like leadscrews instead of ballscrews and rollers instead of linear rails.

For now the budget version will be single axis only. I don't have too much time available to design a budget XY conversion. But it is a work in progress and maybe after the release someone is willing to help.

This model will be designed in a way that allows to mount the 2040 extrusion with the Z axis rail anywhere without the need for other extrusions at all. So if the only thing available is a tree: Mount it to the tree.

A github repo for the G-EDM that will grow over time.

For now only the 3D files and some images are available.

https://github.com/G-EDM/G-EDM

Added Up/Down functionality that allows to switch from one path to another.

This allows to erode more complex shapes in one single run:

Added multiple new functions to the GRBL fork and the G-EDM UI.

One thing that is new is the ability to home XYZ through touch inputs:

And one of the most important features is the new possibility to retract the X and Y axis. This feature makes this build ready for horizontal probing and Wire EDM and is basically a ring buffer that stores the previous motions for a few mm and allows to move back and forth on the motion history.

The video just shows a quick test.

Let's get ready for Wire EDM!

Just a small update:

The GRBL fork does work nice. The one axis sinker/drill part gives a stable burn and the first test with the x axis wasn't bad.

I'm still testing different ways for the XY motion. The one shown in the video stops the XY motion while the Z axis is adjusting.

The workpiece was clamped down very sloppy. With a solid vice this would have been a different quality. Lots of room to improve but all in all a very nice first cut.

I also had to stop the process since the workpiece was on the bottom of the plastic container and the electrode started scratching the plastic.

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:

GRBL is a very cool project but it is not suitable for EDM without deep changes.

The process of GRBLis well made:

1. Take a line of GCode

2. Parse the line

3. Pass the line to the planner that creates blocks of instructions and puts them into a buffer. It defaults to a maximum of 16 blocks that can be place in the planner buffer or 15 if the blocks contain the current line number..

4. An ISR timer interrupt routine grabs a block from the planner and copies the block into the segment buffer to work with it.

5. Each time the interrupt is called it does one step. It counts the steps it has done and if ready it purges the current segment buffer block and goes to the next one.

6. There is also a second planner buffer for system motions. It is implemented in a way that after such a system motion is executed it fully restores the default ring buffer.

It is not possible to just retract an axis without a deep change of the segment or planner buffer. And this is what I'm going to do next.

There are multiple ways to alter the code to make it suitable for EDM and I'm pretty sure the fork will turn out nice in the end.

GRBL can accept different sources for inputs and creates an inputbufffer for each of them. The main protocol loops over each of those possible inputsources to check for new lines. I think this is somehow messy and removed all of them except the main internal input buffer. So instead of looping over 4 possible inputsources it now knows that there is only one source for inputs.

The changes already done reduced GRBL code from about 2.7mb to 2.4mb.

Completely purged the WebUI, Bluetooth, WIFI, Telnet, Bluetooth, xModem, UART stuff.

Replaced the internal Serial communication.

Removed different loops that want to loop over all clients to send messages or fetch inputs.

Replaced the SD card code with a custom class.

Created an API that connects the Touchinputs or SD card to the specific GRBL functions.

And some other stuff.

Just a small update. The video shows the homing cycle. The commands are loaded from SD card.

Grbl runs on Core 1 and the UI with touch on Core 0. The G-EDM API provides easy access to the basic Grbl functions like jogging, homing, running files from SD card, pushing commands to the buffer or run realtime commands.

Jogging motions are canceled if the axis are jogged while it is already running a jog command and access to the touch motion controls and sd card is restricted while grbl is running. This is indicated by the gray color of the buttons.

Edit: Instead of creating a custom spindle I used the existing laser spindle class from GRBL. It works. PWM Frequency and Duty can be changed via touch inputs and the interface pushes the needed commands to the grbl command buffer. Enabling and disabling the spark generator works too.

Now it is time to implement the probing. The probing is not exactly what grbl expects and it will use a custom probing routine.