[Emc-users] UK suppliers of stepper motors and drive electronics
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? 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? 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??? 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. 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. 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) 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. For example, you say As for redundancy, since EMC takes encoder feedback, there isn't
Re: [Emc-users] UK suppliers of stepper motors and drive electronics
[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
Re: [Emc-users] UK suppliers of stepper motors and drive electronics
Am 13.02.2008 um 11:41 schrieb [EMAIL PROTECTED]: 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, but steppers are different ;-), normally, PID works with a output signal from 0 to +-100%, but steppers are working as steppers, this mean, they only can do steps and not power. (I hope i can explain it clearly). The only way i could think to overcome this problem, is a logic in between EMC and the stepper driver who convert the PID output to more (and faster) or less (and slower) steps to the stepper driver. But still, if the stepper motor looses steps, the stepper is running out of sync, and would not come back, especially if you tries harder (more and faster steps). I could only recommend use servos with digital scales, or steppers without. I have seen some steppers with resolvers and feedback logic integrated, they could also behaves like servos, but still, then I would go to real servo drives. Hansjakob 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? 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??? 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. 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. 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
Re: [Emc-users] UK suppliers of stepper motors and drive electronics
On Wed, 13 Feb 2008, Dave Engvall 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. 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. I'd just like to point out that EMC2 can theoretically do this already with the 'adaptive feed' input. An increase in following error would reduce the feed requested by the motion module. This will oscillate without a lot of tedious tuning, or an analytical understanding of the control dynamics. Also, the traditional step/direction interface leaves much to be desired. If you do decide to write your thesis on it after all, please cite me as a reference :) -fenn - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] realistic expectations?
Hi all, While this list is essentially a list for EMC controller discussion an occasional passing word on precision and accuracy might be appropriate. Definitions: accuracy : the ability to hit the blueprint values precision: your repeatability You can adjust your code to hit the spec dead on but only if you have a VERY accurate way of measuring your part independent of the machine you made it on! Now after you get accuracy you can start to worry about the variability (scatter) around the target value. Here is where you get to play with statistics both on the production end and on the measurement end. Do many of do this; I suspect not. We make parts that are good- enough. That is good enough for the intended use. If they don't fit we try again. IMO - only those in a production mode worry much about dimensions to spec. Control issues: On servo machines you really have two values to worry about. Position of the bed ... and most of the time 0.0002 or 0.0001 is way better than the tightness of the machine. Ten times that might be more realistic. The other is machine velocity usually taken off an encoder and used in the PID loop. Experience tends to indicate that this can and should be a high as you can get and not over-run the max frequency for either the encoder or the encoder counter. Often these are the same device and you use what you can afford. High counts/machine unit tend to help the quantization error and lead to better control. OK you're next. Dave - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] UK suppliers of stepper motors and drive electronics
[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
[Emc-users] EMC history
On Wednesday 13 February 2008 15:40, Stephen Wille Padnos wrote: 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. Really http://www.isd.mel.nist.gov/personnel/kramer/pubs/RS274NGC_3.web/RS274NGC_3TOC.html Section 1.2.2 RS274 is a programming language for numerically controlled (NC) machine tools, which has been used for many years. The most recent standard version of RS274 is RS274-D, which was completed in 1979. Section 1.2.3 The NGC architecture has many independent parts, one of which is a specification for the RS274/NGC language, a numerical control code language for machining and turning centers. The specification was originally given in an August 24, 1992 report RS274/NGC for the LOW END CONTROLLER - First Draft [Allen-Bradley] prepared by the Allen-Bradley company. Section 1.2.4 In 1995 the EMC project collaborated with several industrial partners in an open-architecture machine tool controller project known as VGER (a name, not an acronym). This project retrofitted an SNK 5-axis machining center with an open architecture controller. NIST provided the RS274 interpreter for this project [Kramer4]. It was intended to be able to interpret some existing programs for the SNK machine which were written for its former Fanuc controller [Fanuc]. Thus, the RS274/VGER Interpreter took Fanuc flavored RS274/NGC code as input. From that, and other references (both in assorted documentation and original source code), I would conclude that the EMC interpreter does NOT conform to any ratified stansard - It *may* be based on documented behaviour of a common (in 1990-4) control system that *might* be compliant in part with a recognised standard. The current extended interpreter certainly does NOT conform to any published standard (i.e. as issued by DIN, ISO, EIA, or any other official body) - A subset of instructions may be compliant, but that is all. As for the claim that Many of the commercial controls are based on EMC2 code, that is stretching things a bit - Mach1/2/3/4 may have it's roots in the original EMC interpreter, and there *may* be a few other hobby level controls out there that appear to be similar. Although there is a simulator mode (something you won't find on any commercial control You really should look at the current offerings from the likes of Heidenhain and Seimens - I'm sure even the top end Fanuc controls would offer simulation and/or preview modes. - 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. Parts of the core code run in a realtime environment - For example, trajectory planning, PID, and IO. Parsing of assorted files is non-realtime, done in user space (unless someone has been screwing around with the code). It is used on machines from tabletop lathes to 20-ton machining centers. I have EMC running on a desktop mill, but not emc2. There is no hobby-class controller that uses feedback. None. I fear you will lose a bet - Last I heard Mach3 can use feedback with a suitable IO card. The least expensive commercial controller I know of with feedback is in the $5000 range. With the value of the US dollar being so low, $5K would be close. Certainly, there are a number of commercial controls available on the market under $10K. 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. Odd that... There are over sixty names listed on the Sourceforge site. Perhaps you would be so kind as to tell us who currently has access to the repository (including anyone not listed at Sourceforge). - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] UK suppliers of stepper motors and drive electronics
Kirk Wallace wrote: I think Tormach has a fairly compelling argument for steppers here: http://www.tormach.com/document_library/TD30204_DesignAnalysis.pdf Starts on page seven, though I think the whole document is worth while. Second that - I read the whole thing a few weeks ago. Its not often that you can review ehe engineering tradeoffs and such that go into a machine design. John Kasunich - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
