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 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. 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 - Input: process data (voltage, current) - Optional Parameter: maximum path velocity / acceleration - Output: desired instantaneous velocity along cut path 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 On Sat, Apr 11, 2015 at 11:13 AM, TJoseph Powderly <tjt...@gmail.com> wrote: > resending, no attachment > using url instead > > https://www.dropbox.com/s/xbmd0cij2ml9knn/edmGapSignal-vs-XpositionOverTime.jpg?dl=0 > > > -------- Original Message -------- > Subject: Re: [Emc-developers] Reverse Run > Date: Thu, 09 Apr 2015 13:07:06 -0500 > From: TJoseph Powderly <tjt...@gmail.com> > To: EMC developers <emc-developers@lists.sourceforge.net> > > Robert > thanks for looking into this > > I'd like you to look at a real EDM cut > I've included a plot, but if you could actually watch the motor > during a real cut you would observe important info. > > You may find that the adaptive feedrate idea is very wrong for edm. > > The velocity is constantly changing sign during a real cut. > I include a plot of a real cut , and it is an extremely stable cut. > Its a sinker EDM plunging a .025x.375 rib into hastalloy. > > notice the position proceeds in a single direction > but at any one servo update period, the direction is fwd or reverse > according the the process. The directional change is the jiggle of the > line. > The direction of the last period has nothing to do with the value of the > next period. > > so, imo the adaptive feed is incorrect > imo adaptive feed reduces the velocity to below the potential velocity > (the efficient target point of the control loop) > and thus forces inefficiency. > > Adaptive feed ignores the process and 'works' by timidly staying way > behind any efficient/aggressive seeking of the control point. > > Yes i know i saw the edm maple leaf cut once, ask the author how it > compared to the other machines in his edm repair shop. > > But even with this reduction, the work you've done is very interesting. > > Please remember there are 2 different EDM retracts/reversals > short term and long term > > the immediate reversals are constant and of small dimension > see the picture, the jiggly advance is _necessary_ for the process. > > The short term are controlled by the small fluctuations of the process > the efficiency of the cut is determined by following the process closely. > > The long term reversals are after near fatal errors, > these attempt to clear the gap when the process control > has failed badly. > > ( the better the process control, the lower the need for > long term reversals ) > > I'd also suggest that there are 4 common forms of edm > Examining them shows their different TP strategies. > > They are graduated in difficulty of control as follows > 1) easiest, HOLE DRILLING, moves in 1 axis between 2 limits > this can be done in hal w/o tp changes > > 2) middle difficulty, SINK EROSION, including orbiting. this requires > a 'sky blue' safe position to retreat to. > > During a roughing operation ( creates the net shape ) > the tool simply can retract to the point where edm power was turned on. > IF the toll achieves the end of roughing, > i call its position ( duh ) the 'roughing point'. > All finishing operation move FROM the roughing point > and return TO the roughing point. > > Several excursions (orbits) occur, > each with slightly lower power, > and slightly larger excursions > ( the range of motion is 0 to 0.5mm in my experience ) > > Each excursion begins and ends at the roughing point > During each excursion the tool expands the eroded volume according to > a prescribed pattern. > DURING the excursion, the tool can retreat towards > the roughing point. ( think retreats to high ground ) > > Example: a 'circular orbit' is really a trace over a conical surface > the tip of the cone is the roughing point. The tool follows the > slope of the cone towards its base, then travels around the base. > IF there is a problem, the retract is towards the cone tip NOT > along the previous path. ( sky blue remember? ) > > theres more to this, i've written corner picking, square ,circular , > spherical, barrel and other orbits but they all follow the sky blue rules. > > 3) WEDM this is the only EDM that needs to retrace the old path. > And the progress is still true EDM, not > adaptive-slowed-down-slower-than-the-process-wants strategy. So the > short term is constantly changing. The long term allows for retracting > thru previous geometric commands. > > BTW, once this ( retract thru prev geometry) is needed, the process is > pretty much out of control and the action is NOT a strategy to make the > cut better. > > 4) EDM Grinding > i've only worked on a few edm grinders, and they really fall into > category 1. they really dont have a long term backup, as they have > pretty perfect flushing. I just never saw one back up far. > Yes they could use hal for stepover and drop, > like the hydro-mechanical trips and levers common on any wet grinder. > > anyway > please look at the picture > > the top trace is the immediate gap error value > ( summary, its 0-5V with 2.5V= null velocity) > > > > Ok, based on what everyone has said, I'm imagining the following > interface: > > * a HAL pin to allow / disallow reverse run > > the hal pin would need to be on the servo thread > and expect it to get banged a lot > > > * a HAL pin to command reverse /forward direction (with safe state change > > handled by TP) > > my elox agie and heidenhain used M3 or similar > Some used the 'spindle' to turn on the cutting power > Some had delay till the power was sensed before allowing 'edm motion' > > If the power was turned on while the machine was shorted, the current > simply shunts thru the work ( no damage usually and a noobie mistake) > and the system see it has already backed up to the start point, and > stops ( it began there and didnt have to move to get to fatal condition) > > > > * adaptive feeds of -1.0 to 0 trigger reverse run at the scaled feed rate > > (with safe state change handled by TP) > > i disagree with adaptive feed and will move on > > the velocity can be fed into a 'velocity curve' comp. > > with the error signal as input, two simple curves meet at > the 0 velocity point ( no error = no motion ) > the 2 curves are infeed and outfeed > > as the error moves away from the null point there can be > a 'dont care zone' with minimal velocity changes. > the dampens an overactive system > > further away there are 'pay attention' zones. > > I set mine up to run away fast > and to approach cautiously. > > > > * motion commands to switch direction (as implemented now) > > > > Am I missing anything? > > > > i hope you best of luck in this work > > i hope you dont work a lot on the TP side > without considering the process control side. > > because driving down the street should not > be primarily avoiding the telephone poles. > > that works but it aint good driving. > > regards TomP tjtr33 > > > > > > ------------------------------------------------------------------------------ > 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 > ------------------------------------------------------------------------------ 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
