Intro

I'm a Finnish tool & die maker by profession and use electrical discharge machines (EDM's) almost daily at work. On my free time I do machining as a hobby and use the machines at work to build stuff for myself. I have built a working wire EDM system completely from scratch during the last couple of years and it is currently running as a stand-alone system with Arduino MEGA 2560 R3 board. Only portion of grbl I used was the G code interpreter from some early grbl version and did my own motion controls.

To see videos and explanations of the wire EDM system and its use, mechanics and electronics, please visit my YouTube channel at http://www.youtube.com/TheWireEDM as those videos will answer most of the questions I usually get.

Typical EDM features

The moving parts see little to no resistance as the cutting process is contactless. Thus the only friction comes from the drive components themselves. Typical spark gap size, meaning the distance between the workpiece and electrode, is about 0.02 to 0.1 mm depending on many variables.

Sinker EDM

The simplest sinker EDM is a 1-axis machine where only the Z axis moves under CNC control. A more sophisticated machine has the basic XYZ configuration and the next step from that is a 4 axis machine with usually a C axis so that the electrode can be rotated.

Usual feature in a sinker is hydraulic or hydrostatic flushing, where the electrode is 'pumped' periodically up and down to flush the gap better. This retraction amount and interval time is usually selectable and the movement is usually done with rapid moves. Though with big enough electrode surface area the forces might become so great under the fluid that a rapid move is impossible.

Drill EDM

One special case is a drill EDM, which acts like a 1-axis sinker EDM. The Z axis sports a constantly rotating (0-300 rpm) tube eletrode, which is used to drill small holes (0.1-6 mm) to workpieces. Usual use case is starter holes for wire EDM.

wire EDM

The simplest wire EDM is a 2-axis machine with XY controlled by CNC and Z axis (upper wire guide) being manually positioned for workpiece thickness. The next step up is a 4 axis version that has XYUV, allowing thus tapered features to be done.

Machine feed rates are in the range of 0-20 mm/min (sinker EDM) and 0-50 mm/min (wire EDM) when cutting, so there is no sudden changes in speed/acceleration. Only G0 commands need proper accelerations as they are used to go from one place to another quickly with the assumption that no cutting is done during such a move.

Spark generator

The open gap voltage for a typical sinker is in the 100-200 VDC range and 100 VDC for wire EDM. A typical spark gap voltage is something between 30-70 VDC, depending on electrode size, preferred gap size, finishing/roughing, etc. Typical average currents are anything from 0 to several tens of Amperes for a sinker EDM, while on the wire EDM an average current is 0-6 A (pulse current can exceed 1000 A).

The spark generator is either RC type self-oscillating system or a PWM pulse controlled supply. RC type is the easiest to build and use, but changing R and C values to get different machining parameters requires extensive amount of switches (digital or mechanical) and of course parts. With a pulse type generator system it is easy to change parameters by changing the frequency and the duty cycle of the output and controlling the maximum output current with either a set of fixed value resistors (easy) or with an adjustable active current limitation (complex).

Dielectric fluid

The machines have some sort dielectric fluid that is circulated with a pump through a filter. It is used to flush the eroded particles and to keep everything cool. In a sinker EDM this is usually a very light weight special oil.

But on wire EDM's the most used dielectric is water. This poses an issue as the eroded particles make water electrically conductive over time. This is why in a wire EDM there is a water treatment system in which another pump is used to pump the filtered water through a deionisation resin to remove conductivity. This conductivity is monitored with an EC meter and the controller tries to keep this reading between 10-50 uS/cm.

EDM behaviour

In short, an EDM system constantly watches the spark gap voltage and if it is higher than set point value, it advances the electrode towards the workpiece. When the voltage goes below the wanted set point voltage, it enters a feed hold situation until the voltage rises high enough again. If the voltage goes too low (i.e. shorted), the machine will back out from the cut until the voltage rises back to the wanted limits or errors out if the maximum retraction distance is reached (something gone completely wrong).

Thus an EDM is a process-controlled machining situation, in which you can't just feed it with constant velocity and be happy. It will either result in a short-circuit condition or it will go much much slower than it could. And as EDM is slow to begin with, this is not good, especially as such on-off sparking results in poor cutting conditions due to unstable burn. Thus the movement needs a P(ID) loop from the gap voltage at the very least.

In my own original machine this was done such that before stepping the motors one step the machine checked the gap voltage. If it wasn't high enough, it waited until it was and only then took the step. This made my wire EDM approach the workpiece in cutting conditions at 30 mm/min and when the sparking started it basically slowed down to a perfect speed, i.e. the speed that the eroding process dictates.

Existing solutions

Hardly none. I've seen 5 or 6 wire EDM's done by hobby crowd, countless sinker EDM's and not a single drill EDM. All of these have used varying degrees of software solutions and different hardware. The wire EDM systems have been basically without any good motion controllers except the one I made, unless you count proprietary systems which are not open source and also not designed for EDM use.

Intention at the moment

After reading that the current (v0.9) version of grbl supports feed hold and cycle start inputs, I'm inclined to setup and test my wire EDM with a grbl controller. Only thing I need between the machine and grbl controller is a small circuitry to watch the spark gap voltage and control the grbl input pins based on that value.

Problems & possible solutions

1. The biggest problem is that grbl is not designed to be process controlled. This can be circumvented by the feed hold and cycle start inputs that have been added, but it isn't still perfect as the initial maximum program feed rate has to be adjusted so slow that the machine actually stops 'immediately' after feed hold input so that it won't short circuit. This is because the spark gap is a very small distance and when grbl is instructed to feed hold, it will decelarate to a controlled stop.
2. Adjusting the initial maximum feed rate to 'something' becomes completely experimental based on workpiece material and thickness and the generator settings. For example, my wire EDM would go under 1 mm/min with 10 mm thick steel piece, while in 1 mm thick aluminum it tried to go as fast as my Arduino program code (not optimal) could execute. Thus the feed rate should be adjusted via process parameter, in other words the gap voltage, as the work piece and generator power settings affect the possible feed rates dramatically.
3. Short circuit handling. In short (no pun intended), there is none in grbl, as it is designed for a 3 axis milling machine. Thus the controller has no idea how to back out the same way it came in to the position at which the short circuit condition occurred. The only workaround that I could think of currently is to use an external buffer device like another Arduino between the G code sender and the grbl controller to detect the gap voltage and control the grbl with feed hold and cycle start inputs. If the gap is shorted, it would send the grbl a command to flush the motion planner buffer, send in a movement command that would reverse the movement until the short is cleared and resend commands to get where it was when the short occurred and continue to send the original code.
4. Control inputs/outputs for different machine functions. Flushing pump is pretty obvious, just use the coolant output, as is the wire speed (variable spindle speed). But the EC meter input, resin pump output, spark generator settings (like relays for different R values) etc. can't be controlled. With an external Arduino these could be done in the background by spying on the G code traffic sent to the grbl controller.
5. Industry standard M-codes for cut/rethread wire. M60 and M61 are these codes, which on a machine without Automatic Wire Threading (AWT) would halt the program, wait for user to cut and remove the wire, then cycle start would reposition the machine to the M61 line and wait the user to rethread the wire and hit cycle start to continue. So basically M60/M61 works about the same as M0 does, except that wire feed handling manually is allowed to feed the wire as needed for rethreading.
6. Amount of pins for input/output. Now, this could be a little problematic with just the Arduino UNO, but doable with the Arduino MEGA 2560 without any additional hardware. BUT, most of the inputs/outputs needed are not real-time sensitive (like activating a pump or changing the power settings), so they could be done via I2C port with something like the MCP23017 I/O-expanded IC. This I haven't fully investigated yet but it is an idea that wouldn't require changing from the Arduino UNO to some other board to keep code changes to minimum. Though I'm sure the following suggestion is such a large addition/change that changing the board to the Arduino MEGA 2560 wouldn't be such an issue.
7. All of the above could be circumvented with an external hardware wrapper that would control the G code sent to grbl and would also keep track of the EDM process and contrl the extra machine inputs/outputs and make the grbl behave about as it is supposed to in an EDM application, but I would really call this is a hack at the best.

Suggestion

As EDM's are a completely different animal compared to conventional machining in the way they behave and are controlled, I would suggest that there would be a 'grblEDM' branch developed that is separate from the actual grbl. The difference would be in that the grblEDM would be a process dictated controller with the possibility to reverse direction. Most of the motion control planner wouldn't be needed as the eroding movements are so slow that they can be calculated on the fly. Only fast moves would be G0 rapids to position the machine as that condition assumes that no cutting takes place.

I would be prepared to help develop this system as I have skills in mechanics, electronics, CNC work and can also code more than enough but not at the level which grbl is done, which kind of excludes modifying the grbl as I don't quite have a full understanding of its inner workings. I also have no idea how the github repositories work or how they are supposed to be used, as most of the names for things are not familiar for me (the language isn't the problem, but limited knowledge on multi-coder projects and repositiories).

I also have the incentive to do this as I already have a wire EDM at home to play with and I can also do testing with a sinker and drill EDM if it is needed (very simple to build as additions to the wire EDM frame fo testing). I also have access to a MasterCAM 3D license to generate test tool paths for various parts if necessary.

I would be very interested in hearing back from the grbl dev team about this whole thing and would like to engage in discussions about the possibility of this. I can be contacted via here or fastest through my email address which should be visible in my profile.

And what I would like to see of the possible grblEDM is that it would be under GPL to keep the open source community and activities thriving without limitations :)

TL;DR

This isn't the project you are looking for ;)

Outro

Thank you for your time and hope to hear from the dev team and others for feedback on this topic. Ideas are also welcome, though they are the next step after getting feedback.

Jaakko Fagerlund
tool & die maker

@JaakkoFagerlund : Great post. I've always had the intent to support wire EDM machines. However, Grbl has needed to start small and simple with conventional 3-axis CNCs to keep the development tight. This year, I'm planning on opening up the development and support for lots of other types of machines and new feature sets. For one, lathe support has been a pet project of mine. Anyway, I think it's not outside the realm to install a closed-loo control scheme for things like EDM motion control, but, for me, it's pretty far down the list of things to do unfortunately.

Hello chamnit! Thank you for your words and time, great to hear you liked :) The lathe support would also be nice, as it too is a bit far from usual 3 axis mills/printers/plotters/etc. for which this grbl has been used extensively and sits in like a nose on the head. I've had the nice opportunity to also work with CNC lathes for a time (one 2-axis and one 4-axis with rotating tools) and they sure are different from mills.

Now if I understand correctly, you are the one who keeps the project grbl under his wing and others help, correct? As said I dont' know much about the development process for projects like these, but I would believe you are not the only one doing the coding. If so, I would like to hear from other coders also about this idea for a possibility to have a grbl EDM.

Great work so far and great to hear that there might be a slight chance to get a 'special' edition sometime in the future :) I just have to make-do until then with the workarounds detailed above and see how it goes and keep this thread updated with the information if that is okay. This way others can use the information also and maybe it can serve as the basis research information if the grbl one day branches to the EDM world :)

Anyway, if there is an interest by someone(s) to develop this sort of version at somepoint, I'm all ears and ready to help in testing, valuating and providing useful information about EDM's. Due to my own EDM projects and due to work I have had a couple of years time to gather information about this and that regarding EDM systems and I would thus be capable of providing lots of details for the project.

I'm very interested in details about your EDM power supply.

@JaakkoFagerlund : Yes, I'm the lead developer of the Grbl project, but for the most part, I'm the only developer for the past 4 going on 5 years. The only other major contributor is the original author Simen Skogsrud, who worked on this project up to 2011. You can view all of the minor contributors and various forks of Grbl in the "Graphs" tab. That said, there are many interesting forks of Grbl out there, but this is the main repository that these reference, as the intent of this project is to develop the CNC motion control core, rather than support specific features for specific machines types.

@matthewSorensen You can find a pretty good explanation from one of my YouTube videos, but to say it in short, the RC generator is just a 100 ohm resistor to limit maximum power from the supply and the 0.47 uF capacitor is in parallel with the gap. The newer version with PWM pulse control has 8 resistors in parallel, selectable with relays for maximum current and the PWM pulse controls a MOSFET that switches the power on/off at 50 kHz and with adjustable duty cycle (50 % is a good place to start fiddling).

@chamnit, wow, that's a heck of a workload for two persons only! I checked the graphs tab and have to get back to that later, but seems there is a handful of forks out there. I got you on the core thing, so basically I could just try to make a new fork of grbl to include some sort of feedback loop and reference it here, so that it would show up as a "sister" project?

Now, I've just read the source code for grbl from here and there to see what it does, it is pretty straightforward even though the programming is a level or two up from mine, but the big picture of how everything is tied together is still a bit missing. Kind of like wondering if I can just plug in a "wait here until voltage is good" piece of code in to the stepper algorithm or if it will mess it up completely.

It is basically the same as THC (plasma cutter).
And for slow motion, Add step divider, externally or internally and it works fine.

@JaakkoFagerlund : Quite. However, it maintains a certain level of code quality that is often missing from open-source projects (they usually become a patchwork mess of code). As you stated, the code looks pretty straightforward, but it's deceptively simple. The hardest thing to do is make something complex and make it look simple. It's very difficult to do as a system without strict oversight.

To help keep the workload low, I review forks or interesting pull requests time-to-time that have patched in new features to see what the requirements are for that feature. Then, I'll look into integrating into the Grbl system in the correct way that is sustainable and easy to understand.

As for an EDM version, it doesn't hurt to see what it would take to install closed-loop control. Others and myself could use that work as a basis for furthering the idea. This is how research works. Failure is just as important as success. It often leads to great insights and sets the level of understanding closer to the goal.

@cri-s : Basically yes, follow a voltage signal. I have fone a few searches but come up empty on existing solutions. So the voltage good signal would have to be somehow integrated to the motions. The only issue which is completely different from THC is the feature that the machine can/should back out from the cut if the voltage is too low for too long. Basically run the G code file in reverse until the short clears out.

I didn't quite catch what is the purpose or idea of having a step divider? Why can't you just step slower instead of dividing steps and stepping faster?

@chamnit : So true, no spaghetti or MacGyver patched patches on patches. I've been looking at the code more and slowly it is starting to make sense, especially since I found someones blog post with Google, explaining the inner workings of grbl v0.8. So a G code interpreter & communication, ring buffer, motion planner and then on the background ticks a timer for stepping the motors. I presume that this core functionality hasn't changed much from the previous version?

Right on, always reminds me of Edison..."I didn't fail 2000 times, I just figured out 2000 ways it doesn't work" :) I think I'll start on making a hardware wrapper for the grbl (basically a second Arduino) and try to get the machine working that way. If that works, then it would be just a matter of figuring out how to implement that directly in to the grbl if at all possible. It might be that UNO isn't cutting it for this application, but have to port the grbl to MEGA. Should be easy, just changing the ports, bit numbers and pins as required to still keep all the pins requirements satisfied.

@JaakkoFagerlund : The overall functionality isn't much different. In v0.9, there was an introduction of an intermediate step buffer between the planner and the step execution. Most of the improvements are stability and performance based. FYI, Grbl does "unofficially" support the Mega2560. The pins are a bit different, but it works.

If you have a grbl shield and want to use a Mega please see this post #390

@chamnit @EliteEng : Ah, just discovered the cpu_map file that relates to MEGA and its pins :) Somehow had missed that completely while browsing through the files, as I've been trying to get a mental image of the whole system and been plotting a little functionality graph for myself so that I can easily see what function does what is called from where.

I'll see what I can do, if I don't run in to memory issues or lack of pins, then two Arduino UNO's should suffice, as one would hold a modified grbl (without Z-axis, with addiotional M codes) and one would feed it with the program information based on the spark gap.

@chamnit : Do you have any information about how fast I can send pulses to the feed hold & cycle start input pins? At the moment I have an Arduino Pro Mini configured to watch the spark gap voltage and if it is above set point, it pulls the cycle start low for 5 microseconds and returns it high again. If the gap voltage is lower than the set point, it does the same action on the feed hold input.

Initial testing by sending something like G1X50F50 and then emulating the gap signal with another potentiometer seems promising, the grbl immediately stops (well, decelarates at 1000 mm/s²) and then resumes when the emulated signal goes high enough again. However, there is currently no hysteresis in the set point, so every once in a while it seems that the grbl somehow hangs up and just sits there, responding to nothing. I presume it doesn't like too high switch rate at those two input pins?

I really really have to say thank you for coding the grbl, it is just awesome in doing what it is supposed to do :) My way of raping it just seems brutal and would really really really love to see a closed loop control version with an (analog) input signal. I can code one, as I've proven with the previous controller version I used in my YouTube videos, but it lacks all the accelerations and thus has to be driven very very slow, even during G0 moves.

But the very least would like to hear on those two input pins and how long pulse I have to send and how fast I can toggle them without grbl going crazy :)

Pretty good news, the thing works now pretty well :) Just did a simple X-axis cut in 2 mm aluminum plate with grbl and the aforementioned Arduino Pro Mini brutally whacking the feed hold & cycle start inputs depending on the gap voltage signal. I sent grbl a G1 X-20 F30 command and it happily started cutting and maintaining quite steady gap (+-10 V) voltage, even though I didn't do any filtering for the gap signal. Don't know of the actual speed of the cut, but it is way less than the F30 I asked it to go, so it works! :D

Now I'm off to sleep happily and will start developing this 'workaround' around the grbl controller and hopefully I'm also able to figure out why the grbl hangs sometimes? It just stops, says "QUEUE" but doesn't respond to anything, not even soft reset. @chamnit If you have any ideas of where this hanging might occur, any hints would be appreciated as you are the most familiar with the code flow and structure. All I can describe is that some point grbl just goes nothing, only says "QUEUE" on the UGS screen and I have to do a hard reset from the grbl Arduino board reset switch. This condition happens most likely due to pulling those feed hold & cycle pins low constantly (erradically), there is only about 100 microsecond delay between consecutive pulses (artificially made by me).

Maybe I should include some state information in my code so that it doesn't pull the feed hold when it is already in feed hold mode and the same with the cycle start.

I think I know where your hanging comes from: its ESD on some pin or other. I guess you have plenty of it in an EDM setup.
I have loose wires without a decoupling cap for probing and sometimes grbl freezes like yours (no reaction to anyting) when I touch it the wrong way or take of the wire from the tool before the wire from the pcb blank.
I'm pretty sure this is your problem too. Do you have limit switches?

@JaakkoFagerlund : There's a possibility that you found a bug by pushing the feed hold very hard. Re-factoring the state machine, in general, is a high priority, because it's a bit cobbled together at this point. I'll make certain I look for the bug when working on it.

Later, when I find the time, feedrate overrides will be installed into Grbl. Perhaps this would be a better control tool, where you can adjust the speed on the fly, rather than enforcing holds and resumes constantly.

@jgeisler0303 : "Hello neighbours, put your hands up in the air 'cause tonight Sir Discharge-A-Lot is in da house!!!" :D Yeah, it could be one thing, though the hang-up didn't occur during EDM'ing, it was during testing without the generator switched on. But it still might be interference, as I have a laptop runnin UGS, shielded USB cable to Arduino, Arduino sitting on the bench, those flimsy cheap quick protoboard connector wires jumping from the Arduino to the second Arduino and couple of them passing over the stepper motor controller. Have to sort it out later when I build the actual case for all this and put proper star grounding in place and route all the control signals away from power signals.

@chamnit : Probably, time will tell if it is a bug or I'm just pushing it too far. Basically I just have very high acceleration in settings (500-1000 mm/s²) and quite moderate feed rates (200 mm/min maximum) and while cutting the feed rates I give are likely under 30-50 mm/min. When I tested out the grbl, I set slow acceleration and put it to move a long distance and then manually switched the feed hold & cycle start pins to ground to observe if it feed holds to a stand still before cycle starting again. Happily discovered that cycle start during feed hold (decelaration) restarts the stepping sequency as it were before, meaning it accelerates to the set speed.

I'll have to try the feed hold & cycle start lockouts on my second Arduino so it doesn't send them continuously but just once when needed, so the grbl might be a bit happier about it. I'll also try and see what happens when I change the microsecond delay in my program, as I put it there for just this reason that the grbl has time to process things to a "stable" state before getting the next command. This is a balancing act between the commanded initial feed rate, generator power settings, the wanted gap and acceleration value. The more there is delay in getting the feed hold issued, the more likely it is to have a shorted spark gap.

Which by the way @chamnit brings up a question: in the grbl code there is the line that says "minimum feed rate" that is default as 1 mm/min and then there is a warning of some issues if this is smaller. Which issues this would bring up, as EDM tends to go slower than that in many cases (thick workpiece, low power settings, poor flushing, etc.)? And how much is too low, could I put in 0.1 mm or 0.05 mm per minute as speed there? Just as a reminder if it is relevant to my question, EDM doesn't need fast rapids or fast feed rates, as the hydrostatic forces start playing a huge role in achievable movement speeds.

The feed rate overrides would be awesome, best would of course be an analog voltage input but I don't know if that brings any issues with the rest of the code or not. All I know it needs some time to do the conversion, but I remember that it happens in the background and sets some flag or interrupt or something when it's done?

If that would end up in grbl (or grblEDM), I suggest taking a look at http://content.heidenhain.de/doku/oma_controls/CD2/tnc/406_416/gb/thb416.pdf from page 156 onwards a couple of pages, especially the feed rate diagram versus (gap) voltage. Basically the machine runs at the set free running feed rate until the voltage comes to the upper threshold, then switches to a settable slower feed rate and then closer to the set voltage point even smaller feed rate or approaching zero. The machines usually have a servo speed control potentiometer or a data table setting which gives a percentage by which those feed rate values are multiplied, so the user can go even slower but maintain the set point values.

I wish I could be of help with the coding, but I'm afraid my talents lye somewhere between C++/Arduino and pointers are those arrows by the road that show which way to go ;) I so much wish that there would be a grbl like control for 2/3/4 axis (wire) EDM with the analog voltage input and some sort of P(ID) loop back to the control, not to mention the feature not needed in anywhere else but EDM -- reversing back from the cut a set distance in case of short circuit.

At least the EDm version would be easy in the sense that it doesn't need so much planing ahead of time, as it is just so slow and all the positioning rapid movements can just go in straight line, stop, and then continue to the next direction. I'm not sure if this would help in the coding much, but at least it would free up the memory on the AVR chip quite much as there would be no need for planner blocks, just the step segments needed for the current and next path (I presume).

@JaakkoFagerlund, see #432 for the reason behind minimum feedrate. Essentially, if the move was too slow, floating point rounding trimmed it to zero and the system hung. Specifically (min_vel^2)/(2*accel) needs to be not rounded to zero.

@ashelly and @JaakkoFagerlund : From what I recall, it wasn't the (min_vel^2)/(2*accel) calculation that was the problem, because it didn't affect the segment generation if it was zero. It was the vel*dt cruising calculation. If both dt and velocity are too small, relative to distance, it would round-off to zero.

At the time and with the current configuration defaults, I computed that 0.1 mm/min was the absolute lower limit (set at 1.0mm/min with margin) and realistic lower limit for foreseeable CNC machines that Grbl would have been used for. With EDM, that obviously changes.

I can add this to the list of things to look into, but it should be fixable with some coding to check for and account for exception conditions. For now, you can try to decrease the ACCELERATION_TICKS_PER_SECOND setting to something like 50-60, which will increase the dt value proportionally. You should then be able to reduce the MINIMUM_FEED_RATE to something like 0.1mm/min safely as well.

http://content.heidenhain.de/doku/oma_controls/CD2/tnc/406_416/gb/thb416.pdf that link is not open 404 not found..

Is this project is open source ?

You will have to contact Heidenhain for that document, they removed their manuals.

Who is Heidenhain ? Any contacts details ?

JaakkoFagerlund plz uplod adreno Mega code under gnu gpl..

JaakkoFagerlund I love your mindset, I had the exact same idea as probing the feed hold and cycle start to control the programming. Luckily I stumbled upon your post at the exact moment I thought of this. Have you played around with v1.1 yet? There are feedrate overrides now, however I just looked at this and haven't figured out a way to control this. It looks like you would need to have some sort of feedback to your gcode sender in order for it to send the appropriate commands to grbl. Unfortunately it doesn't look like a simple analog signal input. I really wish I had a wire EDM to test with you.

Also any more luck with the feed hold and cycle start routine? It would be easy enough to add a counter and timer to your secondary arduino to basically send it into a timed loop anytime it sends a feed hold or cycle start signal and force it to not send any signals until that timed loop has completed. Also within that loop you could create a secondary counter for each time that loop was successfully completed. You could monitor that counter and modify your initial feedrates (slower or faster) until that counter has reached a specific value over a test cut. This could help you optimize your system for a given material/thickness

@moulikgajjar Heidenhain is a commercial CNC controller manufacturer here in Europe, best known for their precision measurement systems, conversational programming CNC controllers and awesome service. But, if they have pulled the service manual from online, then you have to contact them directly. Google is your best friend.

@zagmongor Nope, haven't checked the latest version as I'm busy writing my own controller that is geared towards wire EDM use and isn't so limited as this grbl is in the sense of inputs & outputs. Far more easier to make a separate controller than to try and stab the grbl code or try to work around its limitations.

@zagmongor Also, one of the reasons I'm not using grbl because I need way more axes than it has to offer. That is why my own system can do 8 axis simultaneous motions (XYUVWABC), thus allowing pretty much any type of EDM to be built or expanded.