Some things to consider regarding wire EDM:
1) Feed rates are very slow, so feedhold can
be "almost" instant. Feedrate is modulated
by the cutting process much like torch height
is modulated in plasma cutting.
2) Reverse feed, for the purpose of controlling
the cut, will be less than the wire diameter.
This is used to clear shorts, and then resume
cutting. This is typically automatic.
3) Rethreading when the wire breaks is a consideration.
This may require something like:
a)jog to clear spot to rethread, might be all
the way back to the start in some cases
b)run from here - to reenter the path
c)run rapid to here - to get back to where the
wire broke
d)resume cutting
4) A wire EDM with four axes will need to be able
to interpolate an arc simultaneously in XY and UV.
Sometimes this is relegated to CAM, but this results
in huge files.
Steve Stallings
> -----Original Message-----
> From: Michael Haberler [mailto:[email protected]]
> Sent: Sunday, November 06, 2011 11:10 AM
> To: EMC developers
> Subject: [Emc-developers] EDM: motion question - backing up moves
>
> out of todays IRC discussion - making motion usable for EDM
> (maybe other things like swarf removal):
>
> the idea came up for a motion pin 'backup' which would stop
> and revert the current move to its starting point; possibly
> several moves with a window.
>
> would the following approach be realistic:
>
> - a EMCMOT_SET_LINE or EMCMOT_SET_CIRCLE command would be
> added to the motion window of a given max window size (maybe
> just 1 to start with)
> - when during a coordinated move 'backup == 1' is seen:
>
> 1. motion would do the equivalent of feed hold but also flush
> the joint interpolators
> 2. looking at the current command, it would computer reverse
> kins from joint position, and generate a reverse move to the
> current commands starting postion, at feedrate (possibly
> corrected by a back-feedrate factor)
> 3. step back through the motion window until window size
> reached and stop until 'backup == 0'
> 4. from then replay the motion commands in window in forward
> direction until window exhausted
> - then start fetching motion commands again
>
> making any sense?
>
> what's unclear to me:
>
> - in 2, how to make sure joint motion has stopped - doing the
> feedhold equivalent doesnt necessarily imply instantaneous stop?
> - what the best place for keeping the motion window is:
> -- this could be either within motion, independent of task
> -- or within task, which would keep a window and possible
> could be told by a motion return code to 'step back in the
> window' which I think is more elegant; also error detection
> (eg steps which cant be (easily) reverted) would be at that level
>
> just a sunday afternoon idea
>
> -m
> --------------------------------------------------------------
> ----------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> Emc-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
