[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.
>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? > > 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
