Robert,
thanks for looking into it
On 04/14/2015 10:17 AM, Robert Ellenberg wrote:
Very interesting stuff! I have some ideas for how to implement a more
EDM-appropriate reverse run mechanism based on what you describe. Here's a
short list of new features we would need to address your concerns
1) "Retract-to-setpoint-on-abort" modal code. If a retract point is set,
the machine would automatically retract to that position on abort. Abort
would also clear this set point.
Perhaps this pair of G codes could work (chosen somewhat arbitrarily):
G15 X## Y## Z## = set a retract point in local coordinates (and enable
auto-retract mode). Now, when a program is aborted early, the machine will
rapid to this position after stopping it's motion along the path.
G16 = disable auto-retract
sounds workable for me
could i change the retract point before returning to it?
( ruf cuts return to start point, but finishing cuts begin where
ruf ends, i call it the rufpoint, it is 1 undersize less than the print
depth )
so i'd set the 1st retact point where i turn on the power for a cut
say G0 x0 y0 z0.05; G15 x0 y0 z0.05
then cut to the rufpoint
say G1 x0 y0 z-.365
then set a new retract point G15 x0 y0 z0.05
the cut a conical path that retract to the apex if needed
G1 X0.002 Y0 Z-.367
G2 X0.002 Y0 I-.002 J0
( and if retract occurs along this circle,
the retract is towards x0y0z-.365 )
wow that'd be a great start
( yes theres other things to do,
like pecking would be towards retract point, not along path )
but one thing at one time eh?
oh yeah, its realy time to mention that for sinking theres
2 retarct points. not too tricky, but
if the apex of the cone is arrived at
then the retract ought to continue towards the previous
retract point
( retract along the cone surface, then along the mine shaft :)
I think we could do something like this by piggy-backing on the abort
command in task. I'd have to take a closer look at the logic surrounding
the abort process, but if we're lucky, this could happen without having to
change anything at the TP level.
i dunno how quick it can happen
sink edms are quick but not fast
good acceleration but slow top end
and
is we do not runaway fast enough
were are having damaging pulse at rates
as slows as 100usOn 12usOff and proximity to
stock will cause damage to work. so
running away is a good thing to do well
( monty python was right )
2) WEDM-style "jitter" feeding via HAL velocity input of some sort.
I agree that process control is important to address. If you had to write
an EDM path velocity controller as a HAL component, what inputs / outputs
would you want? Here's my impression so far:
- Input: desired average feed
yes all wedms i have used have a feedrate
and it is the max expected to be used
bottom line, you dont tell the machine the rate
the process determines the rate.
only experience and data logs can suggest possible rates.
edm is 'stochastic',
it _usually_ produces result A
if we make sure variables BCDEFGHIJK are all controlled.
- Input: process data (voltage, current)
the macros i wrote to communicate with power supplies had
parameters that should not be changed ( changes overcut and finish )
Polarity PeakCurrent ontime
parameters that affect process stability
offtime TargetGapVoltage ServoGain
parameters for adjuncts
peckOn/Off cuttimebeforenextpeck pecktime/distance
( how far to jump) flushingVolume flushSyncWithPeck
parameters for safety
sensitivity electrode/workpieceMaterialPair
parameters for special circuits
capacitanceForCutting(mF) capacitanceForTransmission(nF,pF)
CarbideCircuit
SteelonSteelCircuit
- Optional Parameter: maximum path velocity / acceleration
hmm, maybe look at a 'curve'
a curve is a function that returns velocity given process error
i include a pic
- Output: desired instantaneous velocity along cut path
would be handled by curve
the control points of the curve were left to the integrator
so the general response could be tuned for hogging weight
reduction versus wave guides or chip bonding tools
the curve pic:
left to right is the process error
the difference bewteen the GapVoltage wanted and the ActualGapVoltage
This is sample at least once a servo update period
This dGV ( deltaGapVoltage) is reduced to 0-5Vdc and centered at 2.5.
2.5V meant 'dont move' ( 0 velocity)
the vertical axis is velocity
the curve ( 4 simple discontinuous rates )
has a few control points
2 determine the 'slow down you're almost right' zone near 0 velocity
2 more control the 'runaway' and the 'fall in'
these points were up to the integrator.
the sample was processed and a new velocity fed to the drives used
in this cut every 5mS.
the above is just one implementation ( Fanuc and AGie and MITs use
similar strategies )
personally, i bent the negative velocity curve to near vertical
so _very_ prone to running away and cautious to re-enter
in HAL with linuxcnc, i simply used a bang-bang controller using a
window comparator. i had setpoints for 2 thresholds, the comparator
said Hi, Low or Between. The Hal code reduced the current position by 1
unit if Hi, and increased the current position by 2 units if Low,
and didnt do anything if Between. ( thats bangbang control )
1unit was 1um on my test system
so, all of that yak was about,
a curve can do the last 2 points you spoke of
and acceleration.,,
well these were big machines and big masses
they had laughable accelerations
so i never limited the acceleration ( it was available but useless )
peck edm ( aka jump)
a valve is synchronized to the jump
so the valve open on up stroke
closes on down
more efficient cut
https://videobin.org/+8uk/br1.html
It sounds like a HAL pin to directly specify target velocity along the
motion path would be useful for this. It would take a bit of plumbing in
motion to implement, but I think this is doable without major disruption.
-Rob
------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
