Sink EDM interface

Hi, I just registered a couple of hours ago and skimmed through the General
and HAL areas apparently not finding something that looked to be related to my issue.
My goal is to find out if EMC is the/my way to go?

A year ago I designed and built a 6 axis stepper controller (open loop) with
16x microstepping capability, having Sink EDM (not wire EDM) in mind and
with a single RS485 high speed interface. The board has a PIC18F8520 cpu
with plenty of spare computational power. My idea (maybe naive or over
simplified) was to interface at a level a bit higher in the CNC "stack" as a pulse-direction
interface/protocol as used in the parallel port interfaces.
Maybe at the n-dimensional linear interpolation, so that if the
board was managing a 4 axis system (xyz and rotary table) it would get a 4D
start point, 4D end point and a GO command and then the EDM controller would
set the pace and manage the first 4 stepper motors, until it reached completion
and issue a sort of FINISHED message (using the same serial interface) back to
the CNC controller to receive more instructions. This will require for sure writing
code either by reusing/interfacing part of EMC or writing something from scratch.

Closed loop is not needed because it is a stepper controller and there is a pretty
sure assumption that no steps will be missed due to the involved forces and ultra
low speeds. The CPU will be programmed in C, so I think there is a fair chance to
move/port part of the EMC code to the controller if that is required as a solution.
Maybe it is much easier to learn the CNC commands and write a simple
interpreter running on the board instead of using EMC?

As you can imagine the final goal is to design something using a tool like autodesk
inventor and be able to generate a file that could be fed into a chain of software tools
until it is ready for the EDM machine. I am new to the CAD-CAM-CNC chain and I
only know how to design parts using a friendly CAD, and designing electronics and
their firmware, but have no clue what is needed in between to get the job done?
For sure I have not in mind to write code that would generate the optimal tool paths
to be able to reproduce the CAD object with a certain surface quality on a machine .
Sorry that this post got so long.
Regards,
Thomas

Thanks for your input! I am in no position to start to argue only for the sake of it (specially based on my CNC and emc2 low knowledge) so I will make some assertions to be sure I understood right and give my opinion on others so you can point the eventual flaws on my reasoning. I still have gray areas I want to understand better and maybe you can suggest a specific document other than browsing the whole documentation of emc2 which I am trying to avoid .
From what I read so far in the documentation I am still not sure from where emc2 is starting. Do you feed emc2 a CNC file or is it starting from some 3D model, tool shape/type and blank position/orientation on the machine, to accomplish the final task? Either way may goal is to stay as far as possible form "reinventing the wheel". Therefore I started searching. I still have no PC where I can install the OS and package to eventually do more tests that could help me to clarify some things, so sorry for the "abuse".

From what you write I understand that even if the low level interface of emc2 is skipped and I am able to make emc2 (+ some small driver) to pass coordinates (in the machine's N dimensional space) to my hardware by configuring HAL, there are still a lot of goodies I am getting that make it smart to use it in an open loop scheme, other than code reuse?
Could you suggest a pointer to a place/document where a serial or parallel connection is used to interface emc2 to a pulse generator board, which I think could help me research on my own. I mean using the serial or parallel port to send higher level coordinates.

Almost any machine can have some sort of malfunction like a broken belt, broken bit or stuck/welded electrode (in EDM) that will make it stop either automatically or by human intervention without compromising the uncompleted part and that such an event would make it logic to restart the job at that very point later. For that I imagine there must be some way the hardware can tell the emc2 controller that he can proceed or not and if not, record where he had to resume later and hopefully that this "resume" does not require human intervention on the PC console. Some minor EDM electrode welding situations can be solved by the EDM controller, but would require to ask emc2 to wait for completion of that procedure. This feature might be useful to implement the protocol of "wait until completion and resume" I previously talked about.
I have no idea at what point in emc2 the speed and acceleration info is taken into account, but before that point the functions probably will "block" the next call until the current one was completed, eventually showing a place where to interface, and eventually skipping the more friendly HAL scheme?

I imagine that when using a stepper controller mode in emc2, an assumption/configuration is made that it will be an open loop job and that the hardware and job type will allow for the maximum configured speeds and accelerations to be achievable, with almost no error and that no steps will be lost at the steppers due to excess torque?
The idea of fooling the software by configuring big allowable errors and the like is not a path I want to follow and I rather prefer to accommodate the special things associated with EDM to a protocol that allows emc2 to make speed accommodations. Of course all the jitter that is required to keep the electrode generating optimal sparks must be in my opinion left out of emc2. Only consider a EDM machine with a cylindrical graphite electrode that once in a while retracts from the carving position remembering a safe path back and going to an electrode reshaping station and returning back to the erosion front.
One alternative is to make emc2 send the coordinates and store them in the custom hardware (maybe a file) making it believe the task was done and that the stepper controller is doing things at it's own speed, consuming slowly that data later?

Regards

Thomas

Hi Andy
Many thanks for the time you put in guiding me about what can be done. Just after writing my previous post I found this topic in the forum regarding a plasma torch that would issue (hope to remember it right) an M66 command that could be used to generate "wait" if a pin changed its state. If by using HAL I can instruct emc2 to pass coordinate info to the hardware by mean of a small driver using the serial interface, and the hardware can send "wait" and "resume" info using the same serial interface, so that the same driver again using HAL can instruct emc2 to wait and resume, everything would be settled I think. Then writing that small driver and configuring HAL would be all that had to be done. Of course the hardware had to do all the back and forth movements to maintain adequate sparking/gap and generate the pulses for the motors and all the additional stuff to control the EDM power supply.
I will read the links you gave me!
So now that I also know that emc2 is translating G-Code to motor movements I have three more questions.
1) G-Code is already generated knowing the amount of available axis in the hardware and their nature (linear/rotatory)?
2) How do you fill the gap from lets say Autodesk Inventor to the G-Code file?
3) Once you have a G-Code file how do you know (hopefully in a visual way) that the blank mounted on the machine intersects with the G-Code instructions?

I hope you do not mind so much "blood sucking"

Regard

Thomas

Hi Andy,

I am writing to share with you and the possible other interested emc2 users what I have figured out so far regarding the issue that brought me to this forum. I hope there are not big flaws in what I will write. For sure this might be nothing new to many, but maybe somebody can benefit from it? As you said, I agree that the core of emc2 is the motion controller (from the timing point of view and software effort) and therefore the CNC file/data is assumed to be available at the speed the controller/machine requires it. It is based on the fact that the file system or eventual network, will provide the CNC data at such a high speed that the consumption of it by the motion controller will never find the buffer empty with the exception of program end. The motion controller and it's controlled machine will be the "bottleneck" of the setup. If I am not mistaken, emc2 is using the "RS274NGC G-code interpreter" which is doing the hard job of translating CNC G-Codes to very basic movement functions that in turn will call the motion controller in the emc2 implementation. In general, this very basic movement functions have to be programmed by the application that will use RS274NGC as it's front end. From the software point of view, these basic interpreter functions will probably call the emc2 motion controller API's to do the job. Therefore the motion controller API's will block those basic movement/action functions of the CNC interpreter. In my oppinion these basic interpreter functions whose names are defined by RS274NGC are the right place (maybe not the only one) to interface to an EDM machine. At the beginning or end of those functions you would insert a function call that will send the same parameters to the EDM machine and these functions should in my opinion block until the EDM machine completed the movement or action. In my particular case these functions would send the simplified movement request using the serial line (RS485) to my custom hardware and wait for the "completed" acknowledge. In this new scheme the EDM machine will be the system "bottleneck" and not the motion controller that will receive the motions one at the time not being able to join them in a continuous movement or doing eventually corner optimizations, but this will not matter because the HAL will be put in simulation mode, not doing anything with the PC parallel port. Now a very valid question arises: Why do you want to use emc2 anyway? Why not take RS274NGC and write your own small driver to your custom board instead of wasting CPU power? Well, I do not know enough about emc2 to have a good answer to this, but the user interface and the ability to display in a 3D window what is going on with the tool, could be enough, not to mention the user interface to access the CNC files or give the chance to generate CNC on the fly at the program console. When I think about sink EDM (not wire EDM) I favor the generic tool/electrode shape an complex movements like a milling machine with 3 or even 5 axis, instead of building complex electrodes and doing very simple tool movements like down and then up. For the latter you do not need G-Code in my opinion.
I hope this is useful to somebody and maybe somebody can find a flaw and warn me before I get into deeper waters.

Regards!

Thomas