On 02/04/2013 04:18 AM, EBo wrote: > On Feb 3 2013 10:21 PM, TJoseph Powderly wrote: >> EBo, your name rings a bell all the way back to Paul Corner EMC days, >> you been arounf here a long time i think > Yes. Paul's nastiness is why I completely disengaged from EMC for a > *very* long time. It was the type of two faced - stab you in the back - > interaction that the culture I come from tolerates a lot less than a > literal punch in the face. Interestingly enough I was being funded to > work on EMC at the time, and could have focused on it 40+ hrs/wk, and > the kerflufle caused me to just walk away... > > If that history bothers you, I can easily bow out permanently. no problem, i got along with paul, but it was minimal interaction. i know he could be difficult. i also think he was smart. hehe i'm an asshole first thing every morning, i try to get it out of the way early, and am not always successful. no problem, we can move on >> ... >> >> this constant velocity is totally unsuited to EDM, the finaly >> mechanical >> driving element better to jiggly and nervous, else it aint repecting >> the >> process >> uncover the final gear or screw on any real working edm and watch, it >> approaches a smooth forward motion but IS jiggly and nervous. >> >> ... > The EDM head I wanted to prototype, based on a some old work I saw > once, has the jiggly portions controlled via analog circuitry in an > internally closed-loop. All I would need it to do is either output a > pause, or an analog feedback that basically adjusts the speed overide > from where the user sets it down to 0 (full stop). That way it should > be able to fully integrate into LinuxCNC. the head had the capability of retreating and 'catching up' to the commanded position? like a backslide W controlled by Linuxcnc and a foreslide controlled by analog circuitry? clever, DieterHansen tried similar in early 80's.
re: jiggly, people get the silly idea that edm reverses, it doesnt, it goes to the correct position. you can think of it as reversing and totally miss the important bits. during any cut, the tool has zillions of in & out feeds. The huge, easy to notice ones are called 'going backward' or 'retracting'. these are gross and do not show the nature of the process. the nature of the process is to constantly adjust the position to enhance the process of discharging. the jiggly effect is constantly in action, as the gap state changes constantly, analoguously. a bit of removed material will chang the gap 'resistance' and the the correct position is new. a bit of clean dielectric enters the gap and again changes the corect position. The people trying to solve 'retracting' without this understanding are missing the point. and, i believe, will implement inadequate solutions. > BTW, I should add, that the EDM head I am talking about is a sink type, > and is self retracting a very small distance, but all of that is handled > by the head. That is how the current V/C feedback is maintained. DH's machine had less than a cm of travel. in theory less than the largest overcut ( oberflache ?) would be ok, so a mm would likely be ok this allows for piezo and other mechanisms as the parallel slide that advances the tool. ditto for orbitiing and the lateral axis. as well as piezos capability of nm motion. the speed that is needed for safe retraction is simply fast enough to reduce the damaging current flow enought ot save the workpiece so , the needed retract speed is simply the speed of electrcicity :) which means, the correct approach is not a better seat belt, (runaway speed) but better process control ( follow the process and you dont need to run away :) brushed dc motors have better low speed characteristics than ac digital ( old school 'rule', maybe not as true today) and very good low speed control ( hi acc, low vel ) is needed for edm ( very quickly get into position and then go slow :) >> mydynac repairs cnc edm for a group in sugar grove illinois 'edm >> network' owned by Ron Vogel ( iirc) >> >> the work done more recently by Scott Haase in WI >can< reverse and is >> limited to an upper and lower bound >> (same as mine) >> his uses O-word gcode, mine is hal based ( limits sets by mcodes, and >> motion implemented thru 'offset' hal component ) >> his o-word may be easier to debug, dunno, but for immediacy, hal >> should >> prove mpre responsive because its 1 less layer of control > If I can find an old wire fed, or other industrial EDM, then I can see > spending a lot of extra time on a project like this. i've got a friend who restores AGie WEDMs . if you want i can ask. also, an old trick was a 'crossbow' , mounted on head for a 'baloney slicer' ( wedm in only 1 axis ) on one side of head, a supply wheel with fresh wire, on the other, a takeup spool in between were two ruby/diamond (like) guides and power contacts feeds ( carbide usually) Hirschmann and their predecessor SystemH nee Istema nee Imea made them in Switzerland UI Chicago had a couple old AGie single axis machines that they used to sliced crystal, also had a HiV generator ( rlc discharge ) AG AB model, with FS generators modified ( FIneStuffe ) these had Istema crossbows a stepper and a tensioning (drag) device would be enuf for simple work tension to keep the wire straight, the edm force can easily bow the wire between the guides modern machines use PID tensioning loops (and detect wire breakage ) >> and for the edm gap voltage -> arduino -> threshold comparison -> hal >> -> >> motion loop of Mr Haase >> well there many layers removed by directly connecting a window >> comparator to a hal 'offset' comp > If I do the arduino thing, it will be completely independent of > LinuxCNC and not an addition to it. yes, let the arduino be a data device, not a control device subordinate to hal. too many control levels is not good. or let the arduino be a controller and hal a 'poser' i want to let the 84mHz arduino collect window comparator data during a servo period, and only during the discharge time ( the part of the ontime after the ionization occurs , as in isoenergetic pulses ) this would simply be a count of opens/cuts/lows ( the lows could be shorts or simply 'too close' ) the window comp actually puts out 2 values, the 3rd is assumed when the device is polled and neither pins are active. the 3 values could have weights ( a low could be worth more than a high) the 3 data would be evaluated to recommend an InFeed or OutFeed or SitStillJustWait info to hal based on the >preceding< servo period this free up the hal side to just respond, no thinking neccesary it also allows things to happen without thread rate limitations > I have some experimental code I wrote over a decade ago, when I was > taking PhD level courses in Computer Aided Geometric Design, which > converts standard G-code into an abstracted motion splines. The intent > was to eventually implement the low level as a NURB, but started with > Bezier splines because I had several implementations of them at the > time. sound very interesting, another list memeber Dave Engvall was looking for a way to 'smooth' a path. sounds like the idea might be applicable > Part of that design was to incorporate a fully runtime polymorphic > parser (which allows you to overload things like how comments were > handled and different interpretations of the g-coded standards -- which > allows you to run very old g-code for a machine without modification on > a more modern machine/retrofit). All of the last part could also load > user definable modules at startup, so you would not have to > recompile/reconfigure the program to use different constructs. Anyway, > I let that effort fall by the wayside... > >> <out of sequence> >> >> the idea of orbitining is to use the distance moved away from the >> 'roughing point' to feed a sine and cosine generator >> and use that value to move X&Y along the surface of a circular cone. >> As >> the Z motion increases, the circle increases ( and drops ) >> if the process sees a redcuced input signal , ALL axis collapse to >> the >> that 'roughing point'. the orbiting is part of a strategy to refine the surface finish and dimension as the final dimension and surface is approached, the energy is reduced according to strict data tables this is 'roughing to finishing' 'schruppen to schlicten' the >sequencing of energy levels< ability is neccesary before the ability to orbit orbiting itself, tries to eliminate the nee for different size tools. a roughing operation has a large oberflache and need a larger untermass ( gotta be more smaller than final dimension w respect to finishing tool ) the finishing tool conversely is larger than rougher, yet both are smaller than desired dimension. making tools of precise size, yet differnt dimensions is harder than making ONE size and exaggertating the volumetric size by interpolation thus, orbiting is a time saver and ease of operation. > I will have to think on this. I can see that it could be used to > produce a similar effect to adaptive clearing (and share the tool ware > over a much greater area). For the moment I have no interest in this, > but I can see the benefit of the functionality. > > EBo -- > > regards 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
