Wire EDM machine

[magicniner]

Sorry,
I thought you might be developing a useful, functional machine with wider applications, Kudos for making it work at all but it's so disappointing that it's been intentionally developed down a remarkably limiting dead-end :-(

- Nick

[Neale]

Nope, if you're looking for a commercial scale, production-quality machine, you're right out of luck in this thread.

Life's a bitch sometimes...

Let's be realistic here. A bunch of amateurs wanted a challenging technical cross-discipline project that was feasible in a home workshop (or three). The team has built a prototype that met and actually exceeds its modest ambitions and design goals. It would scale fairly easily - the mechanical bits are straightforward application of ballscrews and profile rails, cutting and inertia loads are low, and a bigger, heavier machine would be easy. The wire support arm needs beefing up anyway, but that's not rocket science at this level of sophistication. The control electronics and software are not a problem - probably need to move away from the PIC to an Arduino or something like that. SMOP, as I said earlier. The really difficult bits, the spark and motion control electronics, don't really need to scale at all within reason. Could up the spark energy a bit with some bigger capacitors, but my guess is that we could do a reasonable size (for some definition of "reasonable") job with what we have.

My bet is that we could cut things like die blocks for model steam loco valve gears, ratchet wheels and pawls directly into hardened carbon steel rather than cutting first and risking shape change on heat treatment; one suggestion received was cutting combs for musical boxes. So, our toy machine could do a useful job making bits for other toys. Not really in the business of cutting keyways in bevel gears for wind generators or any of the jobs the wire EDM service companies provide. I'm quite interested in the idea of being able to cut profile tools for use in a lathe; although my lathe would take something like 16mm shank tooling, for many purposes something much smaller is perfectly OK and within the scope of this machine. Quick search on AliExpress, wave a credit card, and you could have your own machine delivered with much more capacity and sophistication with a lot less effort.

Happy to discuss what we did and how we did it, if there's any interest, but I'm not putting this forward as "the only way to do it" or even "the best way to do it." Whether our original aims were challenging enough is a separate question but even George Stephenson didn't start out by building Mallard!

Apologies to anyone who thought that this thread was advertising machines for sale, or even a proven design and source of PC boards and components to build one. Mike Bax in the Netherlands is, I believe, working towards doing something like that; the plasmaboog Yahoo group would give more information on that although Mike seems a little reticent to say too much about how his development works for commercial reasons.

[m_c]

Getting water on electronics is rarely good. Perhaps an additional cover, or maybe some tank extensions that slope inwards to try and help contain splashes?

What I suspect Nick is getting at, is how are you going to generate the code to machine complex parts, if you can't use some kind of standard/common code that most CAM packages can produce?

While I remember, a KFlop running KMotionCNC can be run in reverse. Simply command a negative FRO, and it'll run as fast in reverse at it will forward. If it only it could also put the material back while running in reverse... :-)

[Neale]

Ah, design in retrospect - always the easiest approach! You are quite right, though, and one simple change has been to put a clear waterproof cover over the front panel, which should help. There are also covers over the rest of the electronics, partly to keep out fingers as well as water. No-one but an idiot would put a large open container of water directly over a heap of sensitive electronics... I remember once visiting a hotel that had just been closed - the swimming pool had developed a leak into the electrical plant room below, so we aren't the only ones. The real point, though, is that this was built as a proof of concept, something that would, if it worked, be able to do something demonstrably useful albeit on a small scale. If I admitted that the current controller can only accept designs that are something like 16K steps long, which equates to about 200mm cutting length, am I going to be nailed to the wall again? Extending that part is, again, just a matter of upgrading the front-end software and hardware. SMOP.

As for "standard gcode", I possibly did not explain myself very well. Normally, for example, you would design in, say, Vectric vCarve and use its CAM module to produce gcode aimed at specific motion control software - Mach3, say. Mach3 translates that gcode on the fly into steps which are sent to the stepper drivers. We design in Vectric vCarve and use its CAM to produce gcode. We use the grbl post-processor. To simplify the software running in the EDM machine micro-controller, we do the gcode to step translation in a separate application which runs on a PC. The step file is then downloaded to the machine. The work flow is very little different from, and the design stage is identical to, that used with the kind of machine that most people on this forum use. There is one extra step that we make explicit that most people do not see as it happens in the motion control software.

Use of Kflop or similar is a valid point, but we took a simpler approach. Our approach means tight coupling between spark generator and motion control at a spark-by-spark level. I suspect that this is one reason for the surprising rate of cut but this is a guess.