On Tuesday 09 July 2013 00:11:10 Gene Heskett did opine: > 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. > To continue this thread, I went out and whacked at the hal file, converting the limit2 module that was controlling the rate of rise and fall of the requested spindle speed, to a lowpass module.
Setup with a gain of 0.005, and with an s1000m3 in effect, typing an m4 initiates the reversal, it takes about 2.5 seconds or a hair more to stop, then the same rpms are achieved in reverse in maybe 1.25 seconds. So the difference is nothing short of amazing because with the limit module, it took 2.5 to 3 seconds to get back up to speed, with cabinet shaking jerks at the beginning of the acceleration. My guess is that the jerk has been reduced by a noticeable amount. The high middle of the run up acceleration did disclose that the drive belt was loose enough to hop several teeth, so I had to diss that far enough to get to the adjustment screws & put a few thou of downward tilt to snug up the belt. Now, if I could get the dynamic braking to stop it that fast, and by the same rules. That would take an active load, and I have not found any transistors that can handle that in the analog domain due to Second Breakdown. But I'm thinking. 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> There's no sense in being precise when you don't even know what you're talking about. -- John von Neumann A pen in the hand of this president is far more dangerous than 200 million guns in the hands of law-abiding citizens. ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
