On 02/03/2013 07:47 PM, EBo wrote:
> On Feb 3 2013 3:42 PM, Peter C. Wallace wrote:
>> On Sun, 3 Feb 2013, John Kasunich wrote:
>>
>>> Date: Sun, 03 Feb 2013 17:08:37 -0500
>>> From: John Kasunich <jmkasun...@fastmail.fm>
>>> Reply-To: EMC developers <emc-developers@lists.sourceforge.net>
>>> To: EMC developers <emc-developers@lists.sourceforge.net>
>>> Subject: Re: [Emc-developers] custom EDM configuration questions
>>>
>>>
>>>
>>> On Sun, Feb 3, 2013, at 03:59 PM, EBo wrote:
>>>
>>>> possibly, but a more principled hack would be to interface it at
>>>> the
>>>> point where it calls the low lever Catmull-Rom spline, and just
>>>> evaluate
>>>> it in reverse. I do not know how difficult that would be, but it
>>>> would
>>>> require the ability to move in the negitive direction. I have
>>>> written
>>>> things like this for moving along splines with custom code, but I
>>>> would
>>>> have to look into how to do this in EMC-s low level motion
>>>> planning.
>>>> Probably the easiest thing to do would be to set up a
>>>> "reverse-motion"
>>>> pin in HAL, and then evaluate it internally, or modify the adaptive
>>>> move
>>>> command to allow positive/negitive feedback voltage which would
>>>> imply
>>>> forward/reverse of motion. Anyway that is my thought off the cuff.
>>>>
>>> Where things get ugly is when you try to do this in a general way.
>>> For
>>> example, what happens if you ask for negative feed while in a
>>> spindle
>>> synchronized move (single-point threading or rigid tapping)?
>>> Actually,
>>> that issue must have already been dealt with - adaptive feed would
>>> cause the problems in that case even for positive scale factors.
>>> But
>>> that was just an example. What about probing moves? What about
>>> the blend between successive non-co-linear straight lines? What
>>> about
>>> a profile that consists of many 0.002" long lines? Can you back up
>>> more than 0.002"?
>>>
>>> Sure, you can say "an EDM will never make a spindle synchronized
>>> move", but changes to the motion module need to do sane things
>>> regardless of what kind of a machine is being controlled.
>>>
>>>
>> What about different motion modules optimized different classes of
>> applications?
> Sure if you can describe realistic situations...
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_jan
> _______________________________________________
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
i've written and investigated Linuxcnc for EDM for years now
maybe this will be of interest
there are 3 basic forms of edm and each has unique needs
all are EDM though and cannot tolerate the 'in position on time' nature
of linuxcnc ( needs a different rule set for where the tool tip must be
now )
the tool tip must be in a position dictated by the process, independant
of time and independant of the position where we were last check.
the 3 types of edm are ( besides edg and a few even rarer modes)
1) hole drilling... only moves along a single axis. usually a single
joint
2) sink edm ... retracts to a given point
( maybe 3-8 axis, maybe 1, but the retract path is not neccesarily
the approach path ( nor often the same ))
because it retacts to a safe point, this is 'sky blue', you need'nt
have begun or been there before, its just safe
3) wedm.. retracts along the programmed path thru one or more path
pieces
( multiple gcodes/ multiple sequenctial tangential geometric entities)
this requires a memory ( at least waypoints, like the segments spit
out by the traj planner )
1 & 2 are HAL solvable
3 requires changes to linuxcnc position planning ( at least a history
that can be un-done, like gps waypoints )
my own tests are only for sink edm ( some for hole poppers but my
HiPresure pump is down now )
i suggest something much simpler than the
VtoF to HAL to thresholds to motion proposal
i simply use a window comparator and output ADVANCE or RETRACT signals
to hal
hal knows the beginning and ending positions (limits) of the motion
and an OFFSET component's input is inc'd/dec'd according to the process
( according to the window comparator )
the machine cannot exceed the depth programmed ( could be x y z c as you
like )
so it has 'spark out' with a little hal-foo and timer ( or a higher
threshold in mine )
It is not locked at the bottom, simply watch for it to be at the bottom
for a len of time w/o backing off... thats a sign the work is really
completed
the cut could go bad and retract to the RETRACT limit, and I abort at
that point
( no where to run )
the cut could get done and spark out at the bottom
right now i'm playing with feeding JMK's sine/cosine stepper example to
implement orbiting from this lower 'roughing point'
i specialize in sink edm. I just rebuilt 2 OKAMOTO's that were terribly
dead and abused.
they cut fine now. I wrote all the macros for ELox system 8/9/10 fanuc's
i wrote all the code for AGies during the 1980's
i wrote all the PLC and macros for Strathclyde & EDMsolutions cnc edm's
i wrote the software that generates all the cutting tables ( etables )
for them also
now I've re-written all the user macros for OKO's too
circular vectoring spherical in any axis, subgates and back tapering,
copper/graphite in many material combos
blah blah blah i knows a S^&%&load about cnc edm
i think the F2V is overload and too slow, yes the process is slow, but
the intelligence is fast.
you can advance slow but you better run away NOW and FAST
i've posted it all too many times, schematics, code, ini's , hal's
nuff said
just seems like a old story that nobdy listed to anyways
tomp
tjtr33
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
