[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. From: http://en.wikipedia.org/wiki/PID_control
"A PID controller attempts to correct the error between a measured process variable and a desired setpoint by calculating and then outputting a corrective action that can adjust the process accordingly." That is exactly what EMC's PID loops do, when running a servo motor. If the motor position feedback starts to fall behind the command, the PID loop asks the motor driver for more torque or speed (some drives do torque control, some do velocity control). Assuming that the driver and motor has more to give, it does so, and the motor catches up to the command. The problem with PID and steppers is that when a stepper looses a step because of too much torque load, it is already at its physical limit - it has nothing more to give, and a PID loop asking for more isn't going to get it. > 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. > >> 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? That is the definition of motor control - change the motor torque so that velocity and/or position becomes what you want it to be. > > 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. > > >> 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??? It might, depending on the machine configuration. And the vast majority of "professional" controls will do the EXACT same thing in that situation. Exactly what happens when a coupling breaks depends on the overall system design. EMC supports a whole range of machines, from the simplest hobby stepper system to industrial grade servo systems. Stepper systems (ALL stepper systems, not just EMC) are inherently open loop. The control has no way of knowing whether the motors and axes are responding to its commands. You can usually "run" a stepper based control with the drives and motor turned off or not even installed. The next step up is a closed loop servo system, with encoders on the motors. Again, this could be EMC or any other control that can run closed loop servos. The control knows where the motors are, and will correct errors when it can. When it can't (for example, if the motor is overloaded, or something is solidly jammed), it will trip on a "following error". Following error mean that the difference between commanded position and actual position has exceeded a user specified limit. With feedback from the motor the control only knows that the motor is where it is supposed to be. It has no way of knowing if the axis is where it belongs. If a coupling breaks, EMC or any servo control with motor encoders will continue to run. You could go one step farther and put the feedback device on the machine table itself. And yes, this will tell you when your coupling breaks - you will get a following error, because the commanded position will be changing due to g-code, and the table won't move. But when you do this, you WILL experience PID tuning difficulties if you have significant backlash, because the backlash introduces non-linearity and hystersis in the system transfer function. The designers of industrial machines are well aware of this. That is why most machines still use encoders on the motors. Some machines use multiple feedback devices - if you have an encoder or analog tach on the motor AND linear scales on the axes, you can potentially get the benefits of scales while using the tach or encoder to improve tuning stability. But backlash will still be a problem - any professional machine builder who tries to sell a machine with several thou of lash in the screws by saying "the scales will correct for it" won't be in business for long. >> 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. > >> 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. You gotta be kidding. You either greatly overestimate the ability of computers, or greatly underestimate the ability of humans. A g-code program tells the control ABSOLUTELY NOTHING about whether it is in the cut or not. It tells NOTHING about depth of cut, cutter overlap, climb or conventional milling, etc. All it says is where to put the cutter. No matter how smart the control (and it would have to be smart indeed to do the things you are talking about), it can't figure those things out without information about the part and the blank - information that is NOT in the g-code, and information that a human gets by a quick glance at the machine setup. > >> 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. Calling something crap while at the same time demonstrating that you don't really understand what you are criticizing will tend to get peoples backs up. > For example, you've got the gimp, and you've got photoshop. > > It isn't about whether one is free as in beer or one can be modified, it is > about which one is > actually productive for those who wish to edit images only, and have no > interest or talent in > coding. Photoshop creams the gimp. The gimp is only free if my time is worth > nothing, eg > editing images is a hobby, not a job of work and not competing with a job of > work for my time. > > 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) It sounds like you have realtime vs. non-realtime control confused with open-loop vs. closed-loop control. EMC is definitely realtime. EMC can do open-loop OR closed-loop control. The machine builder decides which one he wants. That is you. But you started this by looking for stepper motors, which are inherently open-loop. > I hope this is not so and I'm wrong, because if not EMC is no use to me. > > 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. You don't need to code your own. EMC can do lots of things that you are not giving it credit for, WITHOUT coding. (If you want to do coding, you can make it do even more.) From here it sounds like you either haven't read the docs, or haven't understood them, or you have unrealistic expectations for ANY control system. It doesn't matter whether you are using EMC or Fanuc or any other control, it is NOT going to be a turnkey item. Integrating the control to the machine requires engineering knowledge. If you have more sophisticated goals you will need more engineering knowledge. Stepper systems on desktop mills are fairly easy, and we have tools to do almost turnkey configurations for those situations. Full servo systems with encoders on the motors are more difficult, and nobody really enjoys doing PID tuning. But we have numerous users who have managed to do the systems integration and are getting the results they want. Servo systems which combine encoder or tach feedback from the motors with scale feedback from the machine table are currently the "bleeding edge", but some of us are experimenting with that, and I suspect that as long as the machine is fairly tight it can be made to work. Steppers plus scales is another bleeding edge approach, one that in my opinion doesn't have much to offer. It comes up fairly often because precisely because it is inexpensive, and the "cheap hobbyists" you seem to disparage so much are attracted by it. So far, nobody has succeeded. I suspect that IF it can work, it will require customizing EMC's PID loop. EMC's modular nature actually makes it pretty easy to substitute a custom loop. But steppers plus scale is not, and will likely never be, a turnkey setup. > > 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... If you are sufficiently perverse, you can have EMC using one form of feedback to do the control, and use another form of feedback to display position to the user. IMO that will make you like the man with two watches - you never really know what time it is. The control and the display should be using the same measurements, regardless of what sensor they are coming from. > 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? EMC was initially written (in the mid 1990s) to use servo control ONLY, with encoders (or scales, on a tight machine). Steppers were added LATER. The "cheap coder" at that time was a PhD working for the US Government with a shop full of very expensive machines to experiment on. Before you start taking cheap shots at something its good to have your facts straight. > 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... > > 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"? And how many think that a linear scale that displays numbers to a few microns is suddenly going to allow a stepper machine to make chips to that same level of accuracy? > 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, 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, > which is a shame, but this isn't a hobby when you start spending hundreds of > pounds on > materials. It's not the way the code is written. It is the physics and the control theory. I suggest you contact Fanuc or Haas or one of the other high end control makers and ask them about steppers plus scales. You'll have to pretend to have very deep pockets to even get them to talk to you, and I sincerely doubt the conversation will last long after you mention steppers. Then try calling Centroid, and ask them about steppers and scales. They probably won't hang up on you, but they won't want to do steppers plus scales either. They will sell you a $9000 or so servo based system (with encoders on the motors). It is fairly close to a turnkey system, I think all you need to do is mount the box and connect the motors. Then call Mach (Artsoft) and ask about steppers and scales. They will tell you the same thing, then sell you some fairly inexpensive closed source software, which supports steppers or open-loop step/dir servos only. If you really want to use steppers and scales together, thats fine. It can be fun to explore new territory. EMC is the most flexible system out there, and probably the only one that would let you experiment with such a configuration. But you said you want to make parts, not experiment. In that case, choose either open loop steppers, or conventional closed loop servos, and start making chips. Regards, John Kasunich ------------------------------------------------------------------------- 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
