John, I see you have been working on step pulse generators in EMC2. Did our assertions that PID was a trivial case work out in practice? maybe not trivial (I spend most of last weekend flailing around doing algebra before I figured it out) I'm not actually using PID I wound up writing the equations of motion (vel = integral of accel, pos = integral of vel), and setting some constraints, then solving for the accel that gets you to the desired pos and vel at the same time the result is a reasonable formula for accel run it thru limits and presto you can put a position step into that block, and the motor will do a smooth trapezoidal move to the new position based on the frequency and accel limits if you put a smooth move in (one that the motor is cabable of following), then it will simply follow it I have a question about jogs... what is the expected result if you change the jog speed in the middle of a long jog? should the speed change immediately, or should the change only affect the next jog command? Sorry, I just got confused. I thought that the planner did most of the work on figuring out velocity profile and you could just map velocity to step rate, assuming that acceleration was held to a reasonable value. How easily can you handle both, with some sort of flag? I can think of cases for wanting both... dunno which is proper. Jog, to me, has always been a fixed speed (ignoring accel/decel) until you stop. SteveStallings: the lowest level ("PID" & stepgen) needs to enforce accel and freq limits to avoid missed steps. Ideally the planner will never issue something that exceeds the limits, but... I have seen systems that allow a "rapid" button to be pushed while jogging, but I do not like them. for example, when you change directions, backlash comp is added to the _output_ of the planner, and the sum of planner output and backlash may exceed vel or accel limit this block ensures that the motor never loses steps (if you set the limits properly), instead you get a following error if the command is too fast for the motor I still feel that it should be the planner's job to enforce the limits on velocity and acceleration. I have no idea how the planner deals with backlash. it doesn't - it has no idea backlash comp even exists That makes life difficult. 8-( life for the TP is already difficult If TP does not know about backlash, that makes constant velocity a joke. not true the goal of backlash comp is to make an imperfect screw/nut look perfect to the higher level code. So the planner generates a smooth move for a perfect machine, and the comp adjusts it to correct for the sloppy screw the comp code simply produces a single number, that is added to the outgoing position command and subtracted from the feedback This ignores the time domain. The planner needs to know that extra time is needed for the accel/decel needed to take up hte backlash. why - there's nothing the planner can do about it when you are taking up backlash, the screw isn't touching either side of the nut, so the table cannot move True for the axis being compensated, but what about the other axes? you want to stop them all? * jmkasunich ponders Stop is the simple solution. Just wondering if any blending is possible. Usually the non-compensated is at the fastest part of its motion while the compensated axis is being reversed. This makes for significant error if not considered. well you can't stop them anyway... the time needed so move thru the comp (at max accel) is far less than the time needed to stop an axis that is moving at a higher speed you would have to slow down the "fast" axis(s) before you reach zero speed on the reversing one, then have them sit still while the reversing one takes up backlash, then accel them again if you don't start slowing the fast ones until the reversing one actually reaches zero speed, it's too late I'm afraid it would be: 1) hideously complicated That is exactly why I expected the backlash comp to be inserted into the "path" before the TP happens. 2) result in "bumps" as the machine slams to a stop at each quadrant of a circle for example the existing TP doesn't work that way a path that compensates for backlash has two 90 degree bends in it Bumps will happen if you do not stop the non-comp axis also, just different bumps. bump was a bad word - I was referring to a jolt as the actual tooltip velocity changes abruptly I need to talk thru a concrete example to think this out If the comp is inserted before the TP (think pre-distorted path) then at least you have the choice of blended or exact stop, whichever works best for you. I really hate backlash! "I really hate backlash" - we agree 100% there backlash will definetly cause errors... the question is how bad, and how well can we correct for them let's do an example one quadrant of a circle, X is the fast axis, Y is reversing Two quadrants needed to pass thru backlash point. quadrant is the wrong word - does the backlash point of a circle have a name? how about the "corner" of the circle? ;-) Gee, my circles have corners.... 8-) OK, so we have the first quadrant which is an arc. when it ends, the path needs a Y only move = to the backlash, then begin another arc for the next quadrant Exactly, and this occurs when X would be at max velocity normally. right so to follow that path, you would have to slow down the tooltip velocity If the correction could be inserted before TP, then X could be slowed (blended) in anticipation of the required Y moves. that's the bump I was talking about I don't like the idea of the tooltip velocity slowing down... suppose you are cutting 316 stainless The "bump" produced on the workpiece is the result of dwell time allowing the flex in the machine to relax, thus taking a "deeper" cut at the point of the dwell. that is another result of changing the tooltip velocity... I was thinking of 316's nasty tendency to work harden if you aren't taking a heavy cut If you are cutting a work hardening material like stainless, then eliminating backlash is the only solution. Backlash comp will not work. when cutting a circle, the tooltip velocity is normally constant, only the direction changes not true when Y slows and stops, X is still moving, and tooltip velocity never drops (if you do comp at the axis level) OK, so you translated the "dwell" problem into a "path error" problem. I'm envisioning the cutting of an external boss... i.e. cutter is 'outside' , are you both thinking the same thing, or opposite? yeah, but the path error is on Y, which is already moving very slowly - so a temporary stop isn't a very large error Inside or outside cut does not matter, the problem is the same for both. thalx: I was thinking of a circular pocket, but both are the same issue actually there can be differences related to climb vs. conventional milling... if you are climbing and you have backlash, Y won't stop, it will get sucked into the tool! :-( True, yet another issue that cannot be solved by compensation. before you can even think about backlash comp of any type actually working, you have to know that friction is greater than cutting and intertial forces I don't quite understand Steve's issue. You're not saying "keep tool deflection constant". I think you're saying "keep tool axis on track at the expense of time / chip-loading" I am saying the it is impossible to accomplish both at the same time while doing backlash comp. Choose your poison. agreed there... our difference is the poison we chose I consider backlash an axis (joint) imperfection, and choose to deal with it at the joint level To me, backlash compensation is being done while that axis would normally be dwelling, anyway. 1/10 or 1/100 difference in relative motion speeds at that tangent point, at least! exactly As much as I hate it, perhaps we should consider letting the user choose. Cut aluminum with "best path" cut stainless with "constant speed". Again, if the comp was done ahead of TP this would be a matter of turning exact stop on and off. btw, I'm not doing anything different than emc1 here... (I coded it a little differently for clarity, but emc1 does comp at the joint level too) eek! I was ignoring the kinematic implications! I mean, take a 'normal' (i.e. perfect) path... how many steps will the x axis go thru, while the y axis : 1) takes it's last step in its 'same' direction, 2) y doesn't move, 3) y takes its first step in the reverse direction? SteveStallings: emc1 and emc2 treat both backlash and lead screw error at the joint level... they try to make the joints look perfect for the higher level code (including kins) rather than expecting that already complicated code to deal with it I can see that solving backlash for non-Cartesian motion systems must be done at the joint level. thalx: exactly - during interval 2, the backlash comp moves thru the backlash distance running balls to the wall - max accel and velocity which by the way are also _joint_ limits eeek! eek!, Steve runs for the hills. Now, as a f'rinstance that may provide Steve with ammo for this argument - take a Lathe. You have a constant spindle speed dictating some things to you. no - it's good to have these discussions Thalx - Good point. Lathe threading code will need to play the game to avoid having a "backlash" moment in its synced path. right - but if you reverse the Z axis while cutting, something else is terribly wrong (Z is the one parallel to the spindle, right?) not true, think of cutting an O-ring groove in the face of the workpiece I meant "while cutting threads" Should be true for threading. Back in the lab, I had to cut o-ring grooves on a face - said grooves had a dovetail profile, i.e. wider at the bottom of the slot, than at the entrance. when cutting an o-ring groove, you advance, watching the dial - backlash has already been taken out... when you get to depth, you retract, and ignore the dial... backlash gets taken up as you begin the retract, but you don't really care thalx: wow, that's tricky manual or cnc? Not all grooves are cut with form tools. CNC enables profile tools to cut a path for the groove. Manual. But there's this topslide that you can swivel around for the cutting of each side.. So really just 3 separate grooving cuts. anyway back to steve's point... are you thinking of for instance a groove with a U shaped bottom, cut with a tool with a tip radius smaller then the bottom radius? Yes, part of the power of CNC is using profile tools (smaller radius) to create larger features. assuming that the tooltip is an exact (half) circle, that is no different than profile milling with a round endmill and tool radius comp if the tooltip isn't perfectly circular, then you need more sophisticated tool compensation (part of what needs done for lathe) but the same pros/cons of each type of backlash comp apply The lathe tool compensation get more complicated because the "tip" can be pointed in different directions, and it is important to know offset in two axes. Backlash issues on a lathe should be similar to a mill. right - I dunno who is gonna do that, but it needs done before emc is really "lathe ready" Then there is constant surface speed for face cuts on a lathe. yeah, the "big three" for lathe are CSS, threading, and tool comp HAL will also be very helpful because CNC lathes often have much more misc. I/O than a mill. I have no experience with "real" cnc machines of either type... what kind of I/O? tool turrets and such? barfeeders... Multiple turrets, powered tailstocks, barfeeders, collet closers, distributed multiple nozzle coolant (used for chip flushing), and even "live" tooling for cutting keyways and such. wow And that doesn't include dedicated cut-off slides, broken tool sensors, part ejection.......... those must require special dialects of G-code? Those aren't really lathes. They're just really complicated 12-axis mills with dedicated high-speed rotary tables. ;-) probably not too far from the truth! Some, but most is just extra M codes. Lathes, more so than mills, tend to be fully automated and run many parts until the stock runs out. While fully automated mills with pallet loaders exist, they are less common than lathes with bar feeders. we _really_ need to get a PLC integrated with EMC for that stuff I'll mention one thing vaguely on topic here... Moore Tool company makes a lathe for turning optics, aspherics. The tool itself is mounted on a rotary table, so that the tool stays 'normal' to the cut, thru its parabolic (or whatever) path. But few people will hope for that sort of support in the first release of EMC2! ;-) so you have three axis - X, Z, and B (sort of) could probably be done using kinematics (I think) anyway, we digress this started when we were discussing the new stepgen Yes. You mentioned the Big 3. sorry ;-) the idea behind the new stepgen... with ordinary servos and PID, the PID does it's best to follow the commanded position, if it can't, it lags behind, and if it lags too much, you get a following error... you can put a position step or unfollowable path into it if you want, and it will do it's best - but we try to avoid that in the planner I just wanted to make steppers work the same way, without the user needing to tune them Sound good. Does the step generator have its own initialization limits on velocity and accel? yeah, they are HAL parameters so they can be set from the hal config, and changed with halcmd the original stepgen (now renamed to freqgen) had the same limits freqgen takes a frequency/velocity command, so it needs to be used with a PID for position control stepgen has a non-PID position loop built in I knew there was a good reason I moved the PID function out into the HAL ;-) PID works well for linear systems, but when you add in non-linearities like accel and vel limits, other things can be better Since your life is not busy enough.... do you know how to do S curve acceleration? you mean position is an S, velocity is a trapeziod? I think I mean velocity is an S curve that can be very messy IF you are planning a single move ahead of time, it's not too bad IOW, go from zero speed here to zero speed there Agreed, but it seems this is the way to get the most performance from a stepper motor. steppers don't need S velocity (I don't think), just ramped velocity S velocity means ramped acceleration, aka jerk limit Not sure about this stuff. Stepper indexer manufacturers seem to claim S curvers as the holy grail. I dunno... it is related to the problem I was trying to solve... I think I have a paper (a thesis IIRC) about such motion planning around here that I was reading last weekend... It all started blurring together when my brains started dripping out my ears S velocity = ramped accel = limited jerk, you wind up with 7 IIRC distinct periods during the move accel ramp, accel coast, accel downramp, velocity coast, decel ramp, decel coast, decel downramp you can compute the lengths of each one sometimes one or several of the coast times go to zero, you need to treat those as special cases messy math Just what EMC needs, more messy math. another approach might be a quintic spline I was playing with those last week too Perhaps we already have most of the advantages in the new segqueue TP code. you can specify position, velocity, and accel at both ends and it generates a smooth curve between both the original TP and segmentqueue use trapezoidal velocity _however_, the cubic splines in the interpolator _might_ act to round the accel off, making them pseudo-S curves to be blunt, EMC's problem in a nutshell is that it has genius level algorithms and math, with horrible coding practices I thought the new TP code used quintic curve fits for its constant velocity control. IMHO, the more sophisticated the algorithm, the more important it is that the code be clear, so less than genius folks can understand and maintain it nobody really knows what the code uses... I've browse it, and don't recall seeing anything about quintics... but then again, maybe I can't see the forest for the trees Where is Les when you need him...... there's a _lot_ of trees in there and some brambles and poison ivy too Steve - I pointed John at this paper last weekend. Go to http://batman.mech.ubc.ca/~ial/publication/theses.html, and get the Sonja Macfarlane thesis. I think that's the one I mentioned earlier Steve (I orig. got it from Matt Shaver, btw...) I ran across this paper some months back, (previous on-line reference or maybe from Les). While the overall sounds interesting, the math is over may head. that makes 2 of us... I got the impression that if I really needed to I could struggle thru it, but for the problem at hand it wasn't appropriate I've seen some papers that I knew right from the beginnning I couldn't handle the math... Ok. How about the Rogier Blom paper? ..."Design and development of a real-time trajectory planner for the Enhanced Machine Controller" thalx: there is a segmentqueue.pdf in the doc directory of the emc2 tree... I was reading that last night, and again I think I could struggle thru the math if I was determined enough, but it would hurt I don't know if that is essentially the same paper as the one you are referring to I'll look, and let you know.. hey ray! Hi John. it was starting to quiet down.... are you here to raise a ruckus? * rayh grins Ray - You missed all the lathe mode and backlash debate. The HAL doc and pics look great. not much change lately - just added one component Sorry to be so tardy. What were the conclusions? conclusions? we never conclude things, we just discuss them! Conclusions, you want conclusions.. 8-) Is lathe code a priority? We concluded that backlash is a bad thing. 8-) conclusion: lathe needs three things: 1) non-circular tool shape offsetting, 2) constant surface speed, 3) threading we also concluded that nobody is working on those things Sounds like a good list, John. I'd add a few canned cycles to interp. ok, 4) canned cycles Steve. Backlash is a bad thing and comp -- even on Mazak is an iffy thing. I don't know enough about that part, but 4) seems like not so difficult as 1,2,3 agreed about backlash, but we do the best we can Did you consider writing a new interp for lathe? who me? hell no I do low level stuff Fred P suggested going through the interp and switching x and z for a lathe. axis names are the least of our troubles ;-) Or something like that. I'd have to go way back and look at that conversation. Right now tool comp only works in xy. I see... Still tool comp, cycles, and I/O are simple (at least to understand) compared to the things that interact with motion. I believe that you're right on that. I got the current sf to compile yesterday on bdi-220 but had to throw out the drivers for vti and vital. threading and CSS obviously involve motion... tool comp is also needed for CSS Yep. the annoying part is that if it wasn't for CSS, tool comp would be done entirely at the task level, and it would simply command a path that is corrected for the tool comp Is CSS for lathes related to feedrate for a fourth on a mill. dunno, perhaps, but only loosly CSS is simpler, cause you can assume that Y = 0 (tooltip at (or near) center height Okay. CSS is messy because it involves a motion command changing something normally only manipulated by the S word. that too... how would CSS normally be turned on and off? I'd think a g code would turn it on or off. and if on, Sword would specify surface speed, if off S would specify RPM? * rayh begins to look for the fagor books. g92 coordinate preset and setting of maximum s at constant surface speed g94 feedrate in mm/minute (inches/minute) g95 feedrate in mm/revolution (inches/rev) hoo boy - didn't even think about that part g96speed in mm/min (ft/min) at constant surface speed g97 speec in rpm * rayh wonders what all that means? a facing cut is a single linear move command to the motion controller, but not only does the spindle speed need to change during the move, the linear feedrate needs to change too if in g95 the existing TP will _NOT_ do that Grin, ain't it fun? I told you lathes were harder than mills! one of the things I'm trying to do with emc2 is divorce the TP from the rest of the controller. For instance, the existing controller uses the TP for jogs... it sets up a duplicate motion queue and queues a single axis move, then uses special case code to skip the kinematics I'm using a separate and simple planner for jogs - they aren't really that complex, you don't blend them, and all axes are independent Okay. I can see the problem with css. Does the same thing happen with any axis gearing? you mean for threading? Right or gear hobbing. CSS is not considered a tightly controlled parameter. Piecewise approximations are acceptable for spindle speed. actually the "gearing" needed for threading will also address feed/rev nicely right steve. Hobbing is just a bunch of related feed/rev ratios. hobbing involves syncing a rotary axis to the spindle, right? where threading involves syncing a linear axis to the spindle John, are you familiar with "the Frog"? Not sure if they're still in business or not. Sold 1-axis CNC drivers that you could plug together. heard of it, looked at the web page once a year or so ago, but don't recall much At one of our meetings, a guy brought one in. 1-axis CNC lathe. It only drove the X (or is it Z?) - the long axis of the lathe. One optical sensor for spindle angle - with this one little keypad, controlling the one axis, he succeeded in CNC-threading. I guess he wasn't threading to a shoulder ;-) he made an electronic threading gearbox I think he was, actually... you program the device for start/stop positions, #threads, and it just syncs to the spindle. Hopefully, it accelerates identically at each pass! ;-) Anyway, maybe one can think of it as a theta-home-switch... dunno if it would translate to hobbing or not. Probably not. we had a big arguement one Sunday about whether a single pulse per rev is adaquate for threading john, do you see degrees/rev different from feed/rev conclusion was: it depends on how good you want the threads to be and how fast you want to make them I remember that discussion. I see a difference... if you want to handle multi-start threads. you mean degrees/rev on an angular axis vs mm/rev on a linear one? then I think of them as the same Right. I see the same thing. even multistart can be done with a one ppr sensor if you are using a 1 ppr spindle sensor, then you are assuming that spindle speed remains constant over an entire revolution I see 'normal feeding', i.e. 5 thou per rev, as a subset of threading, i.e. "50 thou per rev w/ starting-point defined" so for a 2 start thread, you just delay for however long it takes for the spindle to turn 180 degree, then start the second pass Yes, absolutely. true about normal feed as a subset of threading, BUT... you _must_ have a spindle sensor for threading, where as in theory you don't need one for feed/rev if we treat feed/rev as a subset of threading, folks without sensors won't be able to do either Assuming re-entrant cuts... i.e. 10 passes to cut to full-depth... tiny deviations in alignment will create large differences in chip-load, much more likely to bog down the motor. thalx: you talking about threading or cutting? I say "subset", as in, "just like threading but without the starting-point defined" understood, but that's only one way to do it My assumption, of course, is that threading forces must be kept << motor capability. threading basically closes a position loop - carriage position locked to spindle angle feed/mm only requires a velocity match, and velocity can be estimated (base on comanded spindle speed, not actual measured spindle position) Ok. I will call "no contest". I'm thinking thoughts of an engineer-specified max. allowable surface finish... estimations not allowed! ;-) Me just over-complicating things, as always. I'm not sure we're talking about the same things... I agree that for threading you _must_ re-enter the same groove Now that I think back, on a lathe, BOTH threading and normal feeding are linked to the spindle. for normal feed/mm cutting, there is no need to re-enter the "groove" from the previous cut --- From an OOP perspective, both are 'helix grooves', one more constrained than the other. true - but for normal feed, 1) you don't have to look at the threading dial to start feeding, and 2) you can _also_ feed by hand if you want yes - I like the "more constrained helix" way of describing it but that assumes that the leadscrew is indeed synced to the spindle in velocity if not position (gears give you velocity, the threading dial gives you position) I think of both as being constrained by feed/tpi. But ... what you are saying is that the feedrate can slip, and it's ok. That's a mildly difficult pill for me to swallow... but only mildly. And it may indeed be ok. haven't you ever turned something down by just running the carriage by hand? BTW, when I'm cutting 8 tpi, I don't have to bother with the dial - I can go with wherever the halfnuts drop in! ;-) But yes, that's cheating. sure, chip load varies a little as you speed up and slow down the feed, but it's close I try never to, because it affects surface finish. But I do have a quck-change gearbox, and can get it "just so" by flipping a lever or two. you can do that because you have the gearbox for a CNC lathe, the spindle sensor (and code that uses it) is the equivalent of the threading/feed gearbox Yes, and that's a wonderful thing... it can do inch, metric, *whatever*... and be dead-nuts on, no approximations. without a sensor, it's like the leadscrew is driven by a separate motor with no defined relationship to the spindle so how do you do feed/mm with no sensor? not feed/mm, feed/rev No, I mean, w/ CNC, one can do anything, and it's dead-nuts on ... with a sensor, obviously. right, no disagreement there but many lathes won't have sensors. they obviously can't thread.... but should we tell them "sorry, you can't do feed/rev either"? No, we shouldn't. for threading you _must_ sync to actual spindle position, but for feed/rev, you can sync to commanded spindle speed But they should be able to do that, uh, 'unconstrained threading' ;-) The Hardinge toolroom lathes use an independent motor for feed rates. This means that one of the most respected toolroom lathes does not sync feeds to the spindle rotation. right - I was gonna mention the hardinge Isn't that a "2nd-operation lathe", however? No, the HLVH is a full engine lathe. nope... it does use a gearbox for threading but the DC motor lets you adjust feeds with a pot, rather than shifting gears HLVH - gearbox theading, variable speed DC motor for feeds so you can adjust feed on the fly for best chip load and surface finish Well, assuming 2 things, one could thread.... 1) you cut the thread in one pass, 2) cutting forces have little or no affect on motor speed. But I think those together are highly doubtful. just a little ;-) I think we are miscommunicating... I agree 110% that you must have a sensor for threading and if you have a sensor, then feed/rev is a subset of threading Ok, in that case (DC motor for feed), then I'll say, sure, it's comparable to a bridgeport w/ motor on x-axis. but if you don't have a sensor, we should have another algorithm for feed/rev that doesn't need it good point... lets use the bridgeport example for a minute spindle speed 500 rpm, table feed 0.500 ipm, feed is 0.001 per rev of tool, chip load 0.001 (assume a flycutter, only one cutting edge) I have in the past had to whip out a calculator to figure out where I wanted it set for a given finish w/ a flycutter... and wished it had numbers on that x-axis motor! if you increase the spindle to 1000 rpm and keep the feed at 0.500 ipm, chip load drops to 0.0005 ok. feed/rev simply automatically changes the feed to 1.000 ipm when you change the spindle speed to 1000 rpm, to maintain the same chipload it doesn't have to be perfect - maybe the vari-speed dial is off and your actually running at 990 rpm... the chip load is still pretty darn close to the same but for threading it _does_ need to be perfect, so you _need_ a sensor Yes. If you don't have physical means to tie the two motions together (i.e. geartrain). or electronic means (sensor) True. so we have a choice - implement feed/rev as a subset of threading, and it only works on lathes that have a sensor and can also thread or implement it using commanded spindle speed (independent of threading) and it works on any lathe with a computer controlled spindle speed Ok, let me reverse myself... threading is a constrained subset of normal feed. both are true but neither directly tells us how to implement either one I guess... given my experience with normal lathes, I just see them as "pretty much the same thing". You've got your head in the code... and you may feel the opposite. normal lathes always have the equivalent of a sensor (aka a gearbox), so you don't have to worry about the other case The TP does not (IMHO) get to dictate spindle speed or position - unlike in the mill paradigm w/ rotary-table work. true, except... for CSS, the controller does dictate the spindle speed although it is open loop, and may only be approximately what is commanded. I agree 100% that the TP never dictates spindle position actually on second thought, lathes with live tooling sometimes control spindle position to mill flats on parts, keyways, etc damn, lathes are complicated I don't know a single person that has a lathe that would be capable of handling CSS. EMC *ain't* gonna go changing belts in my Southbend, I don't care *how* much of a challenge you like! ;-) what if you have a VFD driving the motor on your Southbend? Dang, you read my mind! I do, in fact, have a VFD waiting for hookup to my SB. that's why I talk about "commanded" spindle speed... emc tells the VFD to go 1000 rpm, but the actual might be 1100, or 950, or whatever, depending on the drivetrain for feed/rev, emc can adjust tool speed to match what it thinks the spindle speed is, and get acceptable results But... you aren't gonna get CSS on a 4" diameter part, from center to edge. You lose horsepower more than, what, 15% change in motor speed? (I haven't used my VFD yet, just reading thus far) for threading, emc must know EXACTLY what the spindle speed and position are there are limits - at center you need infinite speed pro class CNC lathes use oversize motors and drives so they can deliver rated HP over a 4:1 or greater range Ok. Pretend the workpiece has a 1/4inch hole. pro CSS has a specified max speed, as you go towards the center, the spindle speed up till it hits max, then levels off even on your southbend, say you have a 1HP motor. the vast majority of cuts don't require 1HP Ok. So, I take it, what you are getting at, is that we'll all feel lucky if EMC2 handles feedrate, and forget about threading? heck no we need threading I'm just saying that feed/rev should be implemented using it's own algorithm, rather than saying "when we do threading, we'll get feed/rev for free" I have a 1/3HP motor in my 10" SB, static converter (running on single phase) and I stall the motor often. (So my actual HP is what, 1/2 or 1/3 or less of motor capability..) you need a bigger motor - I think the standard on those things was at least 1/2, maybe more. I have a 2HP in my 13" SB and 3/4HP on my Shoptask lathe (which I use more cause it's in the basement, not the garage) I believe mine is the orig. motor. Ok. Back to threading/etc. I would assume that, the normal case, would be a fixed spindle speed, and that EMC has to look at spindle rotation, and make sure the axes keep up - right for threading that is the only case That CSS is impossible. if you don't have a VFD, yes I would say that spindle-sync-signal would be the first bit of icing... maybe spindle speed control second. and at a fixed spindle speed, feed/rev has no meaning yes and no certainly spindle sync signal is _nicer_ but many folks with 3 phase motors and single phase power already have the VFD No, feed/rev is the most 'normal' way of specifying lathe feed. (At least for those of us who use QCGB for everything!) The sherline won't have an EMC-controlled motor anytime soon. ok, better way to put it: at fixed spindle speed, feed/rev and feed/min are more-or-less equicalent Ok. I always think in terms of surface finish - roughing cuts are 20-50 thou finishing cuts 5 thou and under." Sherline won't have a spndle encoder soon either I've seen a bolt-on one in action (re: Frog) btw, the sherline doesn't have a QCGB (does it have threading at all?) that's a 1ppr sensor for the frog, right? A bolt-on optical sensor is cheap, and easy. Replacing the motor driver, may be easy, but not cheap. Yes, 1ppr. so much of "easy" and "cheap" depends on your perspective I think it was a paper/cardboard disk, and a normal optical interruptor thingie from, say, inside a computer mouse. Ray works with "real" CNC lathes, and he was adamant that 1ppr was totally useless I have a 2HP lathe with a three phase motor, so I _will_ have a VFD on it It can get you going. I would say 1ppr >> 0 ppr! true Ray initially said "you can't thread with 1ppr", and eventually we settled on "you can't thread well and fast with 1ppr" as a pro, Ray isn't interested in anything that isn't "well and fast" 1ppr or more - gives you speed AND position. But as a sherline consultant, he's surely interested in anything that applies there. but only updates once per rev - which gets back to your comments about bogging down