Sink EDM interface

More
06 Sep 2010 01:54 #3993 by tmagdahl
Sink EDM interface was created by tmagdahl
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 :P .
Sorry that this post got so long.
Regards,
Thomas

Please Log in or Create an account to join the conversation.

More
07 Sep 2010 08:51 #4025 by andypugh
Replied by andypugh on topic Re:Sink EDM interface
tmagdahl wrote:

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


I don't see any advantage in controlling the axes in your custom hardware rather than in EMC2, but you might be able to achieve what you want.

The HAL file contains links which take the axis commanded positions and pass them either to a step generator (either software or hardware) or to a PID loop for servo control.

It would be possible to pass the commanded positions to your hardware using your RS485 link (I think, you might need to do some work on a driver for the port)
The axis commanded positions already include velocity and accelleration limitation. If you really want to handle this in your hardware instead (and I see no real reason to do so) then you could perhaps set the limits very high, allow a huge following error, and feed-back the accurate position. I don't know whether this would be enough, it depends on whether EMC waits for the feedback position to be reached before moving on. I don't think it does. Following each move with a "wait for digital input" would work, but seems inelegant and pointless.

Please Log in or Create an account to join the conversation.

More
07 Sep 2010 15:45 #4033 by tmagdahl
Replied by tmagdahl on topic Re:Sink EDM interface
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

Please Log in or Create an account to join the conversation.

More
07 Sep 2010 20:32 #4040 by andypugh
Replied by andypugh on topic Re:Sink EDM interface
tmagdahl wrote:

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?


I am not entirely sure where "EMC2" starts and finishes either. The package as-installed is a system of modular components, many of which will work without the others.
At a basic level, though, EMC2 takes G-code programs and turns them into motor positions, which are then converted to motion by step generators or servo controllers. The step generation and servo control can be inside external hardware, or handled by software components, so the boundary at the bottom end is blurry. You can even generate step patterns in software to drive stepper motors directly with nothing more than buffer components (transistors, at the crudest). Or you can send the position requests direct to a smart controller with Modbus, if you choose.
Generally the advice is to keep as much as sensible inside EMC2, where you have control and can monitor the signals (There is a tool called Halscope that lets you watch all the HAL signals and see what they are doing)

Even the assertion that EMC2 takes G-code as input is not entirely true, you can use filters to pass other types of file to EMC2 and they will be handled. Image-to-Gcode accepts bitmap images, for example. However there is still a G-code layer in the dataflow.
www.linuxcnc.org/docview/html//gui_image-to-gcode.html

There are a number of front-ends that can be used with EMC2, the main ones being Axis, Touchy and Mocca. Those all interface with the Motion controller and the G-code interpreter (which presumably also interfaces with the Motion Controller. So I would guess that the "Heart" of EMC2 is the Motion controller.
However, you don't _have_ to use that either. You could pass position requests to stepgens or other HAL components from any source, and motors would still work. Various toolchangers written in Classic Ladder (the built-in soft PLC) do exactly that, but you could even do it from the command line.

Is that still EMC2? I am not sure, you can in principle run just a stepgen, and alternatively everything else and no stepgens. I don't know of any situations where you would not use HAL, but I suspect somebody can think of one.

There is a good description of one aspect of the inner workings of EMC2 here, in answer to a very different question:
wiki.linuxcnc.org/cgi-bin/emcinfo.pl?WhyManualWhilePausedIsHard

As an example of a HAL driver that uses the parallel port to control a pulse generator, have a look at the PPMC and Hostmot2 drivers:
git.linuxcnc.org/gitweb?p=emc2.git;a=blo...6bad13a1fc5e;hb=HEAD
git.linuxcnc.org/gitweb?p=emc2.git;a=tre...0cc6c51de0b0;hb=HEAD

But bear in mind that a lot of the "housework" of writing such a HAL component can be done for you by the "comp" preprocessor:
linuxcnc.org/docs/html/hal_comp.html

You do, however, raise a very valid point about a sink-EDM machine needing to wind back out under feedback control. The motion planner in EMC will never run backwards, but it will pause or change speed under the influence of the adaptive-feed HAL pin.
If I was trying to make an EMC2 controlled EDM machine I think I would be looking at a custom HAL module to handle the gap-control feedback, communicating with the motion controller through the adaptive feed pin. It is conceptually similar to plasma Torch Height Control, which is also a good example of a comp file to look at.
git.linuxcnc.org/gitweb?p=emc2.git;a=blo...02fa7bb54473;hb=HEAD

I hope this has clarified rather than obfuscated.

Please Log in or Create an account to join the conversation.

More
07 Sep 2010 21:08 #4041 by tmagdahl
Replied by tmagdahl on topic Re:Sink EDM interface
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

Please Log in or Create an account to join the conversation.

More
07 Sep 2010 21:46 #4042 by andypugh
Replied by andypugh on topic Re:Sink EDM interface
tmagdahl wrote:

1) G-Code is already generated knowing the amount of available axis in the hardware and their nature (linear/rotatory)?

You need to tell your G-code generating software what axes to use. EMC will complain if the G-code file contains references to axes which are not declared as valid in the EMC2 ini file, but makes no distinction between rotary and linear axes.
Conventionally the axes are X,Y,Z as linear, A, B, C as roatray axes (around the x y and z axes respectively) and then there are U V and W which are a further 3 linear axes, normally parallel to XYZ.
However, none of this is enforced, if you want a rotary X and a linear A, then that is up to you. As far as EMC2 is concerned they are just "Joints" 0 to 8.
(Technically this is only true for a "trivial kinematics" system, EMC can move robots, hexapods etc in cartesian space using non-cartesian actuators, but that is unlikely to matter to you).

2) How do you fill the gap from lets say Autodesk Inventor to the G-Code file?

At the moment, I tend to make a drawing in Inventor, then hand-code the G-code. There are lots of very good packages out there to automate the Gcode creation, but they tend not to be free, and the best are frighteningly expensive. Google terms for the cheaper and some free options include HeeksCNC, SheetCAM and FreeMill.

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?


You instruct the CAM software, look at the Axis Graphical preview, and then at some point you just have to hit "Run" and hope it is correct. Generally with a finger on the "Esc" key :-)

Please Log in or Create an account to join the conversation.

More
06 Oct 2010 18:32 #4538 by tmagdahl
Replied by tmagdahl on topic Re:Sink EDM interface
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

Please Log in or Create an account to join the conversation.

Time to create page: 0.223 seconds
Powered by Kunena Forum