Unfortunately when a stepper looses synchronisation, one needs to 'stop' the motor for the poles to realign and then you can move the motor again. I cannot see how a motor travelling at a velocity near its maximum capable velocity can loose just a single step with out stopping altogether. Steppers with encoders could benefit when there are lots of short reversals, and a step (or many) might be lost when the motor cannot accelerate and decelerate due quickly enough. Your workpiece might still show evidence of missed steps but it is likely that it won't be ruined as the cutter will be machine away 'less' when it stops on a reversal. Clear as mud?
I think (but I'm not sure) that the algorithm used on the Mesa card is a hardware step generator and that the delta frequency (commanded frequency versus the actual) is proportional to the error, as the error increases, the frequency can be increased to compensate. The following error will stop the machine if it becomes too great. The PID loop controls the actual frequency proportionally to the error. Greg ----- Original Message ----- From: "andy pugh" <bodge...@gmail.com> To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net> Sent: Monday, November 29, 2010 4:07 PM Subject: [Emc-users] Stepper Musings > Prompted by a query on the forums on the age-old question of using > encoders with steppers, I started wondering about wierd and wonderful > ways to make it work. > > The issue is that steppers just don't have the right characterstics to > work in a servo loop, as trying to run them harder to recover a missed > step will probably make things worse. > > So, I pondered the idea of using a PID with a unity feedforward term > and a negative PGain, so that as long as there is no error the system > works as a normal stepper setup, but if there is a missed step then > the error * Pgain would back the velocity off a bit. I think the > drawback of this is that there is nothing to claw the error back, > though perhaps a slow I with a higher limit than the P might do it. > > Probably a more promising idea is to not attempt to recover position > immediately, but to link the output of a PID to the > motion.adaptive-feed pin, so that any missed steps result in the > system backing-off the feedrate.You would probably want a slow-I PID > as a separate component to claw back the missed steps once the > feedrate has slowed enough. > > Any thoughts? > > -- > atp > "Torque wrenches are for the obedience of fools and the guidance of wise > men" > > ------------------------------------------------------------------------------ > Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! > Tap into the largest installed PC base & get more eyes on your game by > optimizing for Intel(R) Graphics Technology. Get started today with the > Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. > http://p.sf.net/sfu/intelisp-dev2dev > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users -------------------------------------------------------------------------------- No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.449 / Virus Database: 271.1.1/3275 - Release Date: 11/23/10 19:34:00 ------------------------------------------------------------------------------ Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! Tap into the largest installed PC base & get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
