On Monday 08 July 2013 10:57:36 andy pugh did opine: > On 8 July 2013 05:21, John Morris <j...@zultron.com> wrote: > > Also, > > > > spindle acceleration and reversal control is not as precise as other > > motion components. Nothing we can do about the uncontrollable! > > My feeling is that spindle reversal is very nearly a zero-jerk motion, > so isn't a problem. > > The jerk is at spindle start and when the spindle changes from > constant speed to begin the deceleration phase, and the transition > from acceleration to constant-speed.
That is/was one of the considerations when I setup the original spindle control for my toy lathe. I, by using the limit2 module in the path that leads to pid.x.command, limit the rate of change such that from the pid to the motor and back from the encoder, has a much higher bandwidth than the controlling signal getting through the limit2 module. This has the side effect of putting a cap on the amount of jerk, and thereby a cap on the controllers amps to the motor. I've had it dancing a few times without tripping any breakers, in this case a 9 amp, probably thermal type. I hadn't considered it but I'd have to assume from this discussion of jerk, that a lowpass could actually be a better function in that it would convert the commanded speed change steps into something that more closely resembled what we in the broadcast business, call a sine-squared function, which is the equ of beginning, and ending the commanded speed profile at the excursion tips of a sine wave. Very high slew rates in the center of the change but relatively gentle in terms of beginning and ending jerk. I should play with that as it would appear to reduce the apparent ringing I can see in the halscope as it approaches the set speed, and or overshoots a bit due to pid windup, and could result in measurably faster response by hammering the drive harder in the middle of the acceleration, but tapering off as the final requested speed is approached. > Given that finite-jerk is a "nice to have" and that (nearly) every > LinuxCNC installation in the field is running happily with unbounded > jerk, I think it makes sense not to try to limit jerk in coordinated > moves. Totally agree. IMO the place to exert any 'jerk' control, is in the path of the axis, in this case the spindle, that everything else is slaved to. That leaves the individual axis's performance during a backlash take up move as probably the biggest jerk in the system. That, for me, has not been a problem since several years now that the backlash moves have been constrained by the individual axis accel and velocity limits. Several years ago, the backlash moves were apparently unconstrained, and were done so fast the motors ignored them resulting in loss of position. Here, its quite noticeable in my Z during a g33.1 move as the z motor jumps perhaps 10 degrees, but is completed by the time the chuck has rotated 2 or 3 degrees in the opposite direction. That seems to be a non-problem. > I have tried writing a finite-jerk motion planner for a laser raster > system, and it is hard to even hit a known destination position > without calculating ahead in time. As spindle-coordinated motion in > inherently a reactive rather than predictive mode the choice is > between following the required path or limiting the jerk. (noting that > following the correct path does not necessarily exceed jerk limits). Good discussion, all. Cheers, Gene -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) My web page: <http://coyoteden.dyndns-free.com:85/gene> is up! My views <http://www.armchairpatriot.com/What%20Has%20America%20Become.shtml> A computer without Windows is like a fish without a bicycle A pen in the hand of this president is far more dangerous than 200 million guns in the hands of law-abiding citizens. ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
