On Feb 13, 2008, at 7:40 AM, Stephen Wille Padnos wrote: > [EMAIL PROTECTED] wrote: > >> On 12 Feb 2008 at 18:03, [EMAIL PROTECTED] >> wrote: >> >> >>> EMC can do PID just fine. It's steppers that can't. Steppers lose >>> torque as the speed increases. There is no way around this, it's >>> just >>> the physics of the motor. >>> >>> >> >> Did someone rewrite the spec for PID? >> >> > No, of course not. It's still just a mathematical combination of the > command and feedback positions with some weights thrown in.
PID is still PID and emc extends this with further corrections: FF0 (offset), FF1 (feedforward velocity) and FF2(feedforward acceleration). The classical control theory for emc comes from "Automatic Control Systems", BC Kuo, et al. ISBN 0-471-13476-7 I hope your calculus and DiffEQ is better than mine. ;-) > >> used to be a way of correcting a system or process in just the >> same way that an operator >> would, and it certainly didn't require any more torque, just a >> wait state. >> >> > Sure, but there is no decision-making in a typical PID calculation. > It's a formula which gives some result based on the inputs. In EMC2, > PID is actually PIDFF - it includes command feedforward terms, > which can > be very useful in getting good servo response. > >>> PID loop will attempt to correct for a >>> lagging motor by requesting more "effort" from the motor. >>> >>> >> >> When did this become the *only* option PID had, more torque and >> overspeed? >> rant on: Because that is the definition of PID. You are not going to like this answer: but if you insist on using steppers in the performance zone that they are not engineered for then write a stepper-only module that lowers velocity when following error starts to increase. The better solution is to engineer the stepper system correctly and run it within its limits. If you can't live with that spend the money for servos. good luck. end rant Dave >> > It may not be the only option, but it's the one that makes sense. If > the motor lags behind, then more force/power is needed from that motor > to meet the path requirements. Remember, it's a simple sum-of- > products > equation, it will not give you one kind of answer sometimes and > another > kind of answer other times. > > There is another option when an axis can't keep up, and that is to > reduce the requested feed rate. EMC2 has the capability of doing > this, > but I don't know of anyone who has successfully tuned a system to > do it. > >> I'm not trying to be funny here but I've used a lot of these >> technologies in the past, and yet, >> when it comes to EMC I'm starting to get the impression that some >> things are done >> differently. >> >> I'm not quite sure why, I'm not even sure they are, but it is the >> impression I'm getting, and I >> hope I'm wrong. >> >> > Don't worry, you are wrong :) > EMC2 uses PID just like any other system uses PID. If you can tune a > system that uses steppers and only scales for feedback, please write a > wiki page (at <http://wiki.linuxcnc.org>) so others can learn from > your > experience. > >>> Even if the motor just loses a step or two which is >>> detected by the scale, you can't get it to catch up - it's >>> already at >>> the limit of its power envelope or it wouldn't have fallen behind >>> in the >>> first place. >>> >>> >> So, wait state, you surely aren't telling me that EMC will simply >> carry on thinking it is >> machining a part if the coupling between a motor and leadscrew >> fails??? >> >> > Of course not. There is a maximum following error setting, and EMC2 > will stop if any axis deviates from expected by that amount. > >>> You had an incorrect assumption in your original email: that using >>> linear scales will eliminate backlash issues. >>> >>> >> NO, it won't eliminate it, but it will eliminate it from >> calculations, as it gives true position, not >> estimated position, then add fudge tables. >> >> > Although the feedback is absolute (or close enough that we won't argue > it here), the motor position isn't. Cutting forces and inertia will > affect the relationship between motor position and scale feedback. > Even > though the software won't have to deal with it, there is still > backlash > ("an uncertainty in machine position" as it was pointed out in other > emails). If the table coasts a little too far, a "normal" PID > response > would be to try to move it backwards. Since the I term integrates > error > into the output signal, the more backlash you have the more the I term > will wind up between the time the motor gets a motion command and the > feedback starts to change. Once the table starts moving and the error > goes down, the I term will start to be reduced, but it will not go to > zero immediately. It's likely that the table will overshoot the > intended position in the other direction. The cycle will begin again, > with the sign reversed. This oscillation will be very difficult to > tune > out. > > Note that I didn't need to mention EMC2 at all in that last paragraph. > This is a problem endemic to any system that uses PID and losely- > coupled > feedback. Again, if you have a method that can be used to tune this > type of system, I really want to hear about it, and I really want a > wiki > article to tell the 300 other people who have asked about it how > it's done. > >>> This isn't true at all. >>> Backlash is an uncertainty in machine position. If you're climb >>> milling, the cutter will tend to pull the table "ahead" of the >>> motor. >>> When conventional milling, the cutter will resist motor motion. >>> It's >>> not possible for the control to know which type of cutting is taking >>> place at any given time, and it may even vary within a move, so >>> there's >>> no way to "compensate" for it. >>> >>> >> eh, it is working from a tool path with a defined depth of cut and >> cutter overlap from last pass, >> direction of beds is also knows so "knowing" whether you are >> cutting on the climb or the chip >> is as trivial a logic problem as it is for a human operator. >> >> > The machine tool is working with a tool path, there is no > indication of > where any stock is being removed. The CAD and CAM applications do > know > that, but the machine controller does not. It may be possible to > "figure it out" in some simple cases, but when the control is doing > complex 3D shapes, it may not be all that easy. At the moment, EMC2 > does not care about which side of the tool is being used to cut, > except > when cutter diameter compensation is on. > If you can figure out an algorithm to predict how backlash will > affect a > cut, I'm sure we can find someone to add it to the code. It would > need > to work in all cases though, and not take too much calculation > (obviously we can't do FEA of the entire machine in realtime). > >>> Additionally, de-coupling the feedback >>> from the motor, especially through a drive with backlash, will >>> make the >>> system very hard to tune. The PID integrator will "wind up" as the >>> motor starts to spin to take up the backlash, but the feedback won't >>> change until the motor is already moving. The motor will slam >>> the table >>> into motion, at which time the PID starts to wind up the other >>> way. The >>> result is - you guessed it - oscillation. This is very hard to tune >>> out. >>> >>> There has been some discussion recently about using both encoders >>> and >>> linear scales, but there isn't any software to do that yet. I think >>> this is the "different method of machine control" that Kirk is >>> talking >>> about. >>> >>> As for redundancy, since EMC takes encoder feedback, there isn't >>> really >>> any need for a DRO - the EMC display is actual position. >>> >>> >> >> Listen, I know from experience that my words have a tendency to >> get people's backs up, and >> I don't want to do this, members of this list have been extremely >> helpful and extremely nice. >> >> But. >> >> I'm getting an awful suspicion here, and that awful suspicion (and >> I dearly hope I'm wrong) is >> that EMC is going to suffer the same problems of many open source >> projects, it's crap. >> >> > Well, this kind of statement might be the reason why your words > tend to > "get peoples backs up". > You have misinterpreted almost everything I've said about the physics > and PID control problem as problems with EMC, which may make you think > it's a hunk of crap. > >> For example, you've got the gimp, and you've got photoshop. >> >> [snip] >> >> > You could try gimpshop :) > >> I'm starting to suspect that EMC is a project that started out, >> not to emulate the commercial >> equivalents, but built bit by bit to do various things on the >> cheap, I'm starting to suspect that >> EMC is not a realtime machine control system, but rather an >> offline (non realtime) simulator >> that relies on assumption (I sent signals to move X 1.01 mm, >> therefore I shall assume it has >> moved 1.01 mm) >> > Actually, you have it backwards. Many of the commercial controls are > based on EMC2 code. EMC was originally developed at NIST and was > public > domain. It was part of a standardization project for machining > languages, and was written as the reference implementation of the > newly-developed RS274NGC standard. > Although there is a simulator mode (something you won't find on any > commercial control - why bother, nobody would buy one just to stick it > on their desk), EMC2 is very much realtime - to the limits of the PC > it's installed on. It is used on machines from tabletop lathes to > 20-ton machining centers. > > As for the assumption of motion, that is exactly the reason that > people > use steppers - one step = some amount of motion, no feedback required. > This is how all hobby-class (<$1000) controllers work. > >> I hope this is not so and I'm wrong, because if not EMC is no use >> to me. >> >> > Again, good news - you're wrong. > >> Please don't do the "well that's open source buddy and you can >> always code your own >> solution cos after all it is free software" thing on me, I'm not >> actually here with my primary >> concern being paying as little as possible or preferably nothing >> for software, I'd be quite >> prepared to pay for EMC, and as a long lime linux user I dig open >> source (can't code myself >> but there we go) but at the end of the day when it comes to all >> forms of software I'm looking >> for a tool to do a job, and I don't mind paying for a good tool. >> >> > I'm willing to bet that EMC is the only feedback-enabled control > software you'd be willing to pay for. If you can afford anything else > that does feedback, then you could easily afford new ground ballscrews > (or a new machine, really). There is no "hobby-class" controller that > uses feedback. None. The least expensive commercial controller I > know > of with feedback is in the $5000 range. You will still have tuning > problems with loosely-coupled feedback, though the commercial controls > will be easier to set up for dual feedback (encoder/tach + scale). > >> For example, you say "As for redundancy, since EMC takes encoder >> feedback, there isn't >> really >> any need for a DRO - the EMC display is actual position." and I'm >> sort of, what??? encoder >> feedback is only actual position if it is measuring actual >> position, eg linear scales... >> >> > Actual position within the measurement error of the machine. With an > encoder, the error band is the backlash band. With a scale, it's > defined by the scale design. Your scales have 5u resolution, but > +-10u > absolute accuracy. This is certainly better than an encoder and > lots of > backlash, but it's still not "exact". > >> Is this simply a case of linear scales used to be frighteningly >> expensive so the EMC coder >> ignored them and went with the cheap option, and then started >> fudging around to try to fix the >> problems associated with going the cheap route? >> >> > Heh - "the emc coder". EMC was developed by a few PhDs at NIST, then > added to by about 20-30 developers over the last 10 years. We have > programmers, machinists, electrical engineers, machine > retrofitters, and > machine manufacturers contributing to EMC2 now - I think you should > read > a little of the history of the project before you assume that some > idiot > in his garage "just forgot" to add something you think you want. > > As for the scales, they have the same output as an encoder - > quadrature > incremental position. Incidentally, it looks as though these are just > linear encoders, not absolute glass scales. You'll need to deal with > zeroing / homing just the same as if you had rotary encoders on the > motors. > >> I'll grant you that rotary encoders on the leadscrews can be >> pretty accurate, emphasis on >> "can", if you retrofit with class 5 rolled ballscrews and scrape >> the ways, but if you're using >> trapezoidals fuhgeddabadit... >> >> > Check the price of a Centroid, Fanuc, and Haas controller, then take > another look at EMC2. > >> Again, I'm not trying to give offence, but I'm wondering what sort >> of people are members of >> this list, how many are turners, how many are coders, how many are >> hobbyists, how many >> think that an encoder set up that displays numbers accurate to a >> few micron is suddenly >> going to allow you to make chips to that same level of "accuracy"? >> >> > There's a wide cross-section - programmers, engineers of various > sorts, > hobbyists, mathematicians, machine makers, machine-shop owners, etc. > Hmmm - it sounds like you're the one who thinks the linear encoder > will > suddenly make your machine more accurate. I've been trying to tell > you > that it's very difficult to get that system to work, and you seem > to be > telling me that it's easy. Please clarify if that's not what's > happening here. > >> Yesterday I bought the DRO and sino scales as I said, the whole >> package with everything >> (extras) thrown in and a couple of other items was just under 500 >> quid, an hour later I >> ordered a sheet of 10mm 5083, it cost just about as much as the >> basic dro and scales, for >> me my time is money and for me materials are money, if EMC isn't >> going to save me time >> then I'm better off paying money for commercial closed source >> software, >> > You're making the incorrect assumption that the software is the > limitation here. > >> and if EMC is going >> to try to force me to work wihin arbitrary parameters like you >> can't use linear scales and >> steppers because of the way the code is written then EMC just did >> a kcad and gimp on me, >> >> > You added the "because of how the code is written" part, nobody else > ever said that. We've said that the physics/mechanics are the > problem. > >> which is a shame, but this isn't a hobby when you start spending >> hundreds of pounds on >> materials. >> >> > Or thousands on a commercial control. > >> Again, many thanks to all who have replied to my queries before, >> much appreciated. >> >> cheers >> > Any time, but please try to look at the history of the project before > going off on the developer in his basement. > > - Steve > > > ---------------------------------------------------------------------- > --- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
