Gene, You say you were using a limit3. Did you have limit3.maxv or limit3.maxa set to limit the acceleration? Since the input is a rotational velocity you only want to limit rotational acceleration which would be maxv. maxa would limit the change in rotational acceleration causing overshoots. I propose that you try limit2 with just the maxv parameter to limit the acceleration/deceleration of the spindle.
I could be way off though. Jim On 9/1/2015 2:12 PM, Gene Heskett wrote: > Thinking that a direct motor reverse is a bit brutal on both the motor, > and probably explores the current limit facility built in the Pico pwm > servo amp, I tried adding a limit3 between the signal from > motion.spindle-speed and the input to pid.s.command, which was formerly > a direct net in the .hal file. > > Without it, a spindle reversal from 1000 rpms is accomplished in just a > fraction of a second. > > But while it did slow down the turn around of the spindle, I am getting a > huge overspeed in the new direction until it settles back to the > commanded rpms. Not at all usable IMO when the spindle may be turning > 350 revs driving a 4-40 tap in a G33.1 cycle, and the reversal runs the > spindle up to 2850 revs. The head keeps up, but still it looks > dangerous to me. It literally goes wide open and jerks the tap out of > the hole, in perfect synch, beautiful threads. A larger tap would be > self cleaning by spinning itself clean. Now theres a grin causing > thought. :) > > One of the things I did in hacking up this filter, basically a 4 stage > shift register with all 4 stages feeding a triplet of sum2's, with a > weighting scale factor of .2500 so basically the final sum2's output is > the updated average of the last 4 encoder transitions, unforch this > results in single value being clocked thru the sample_holds by the > servo-threads repetition cycle when the spindle is turning slow enough > that we get the same reading several times in between transitions. > > Thats pretty slow as the encoder disk has 268 edges per revolution. So > at low speeds, the filter degenerates into whatever the last edge > transition set into the 5i25's registers by clocking that value all the > way thru the shift registers the S_H's are in about 5 milliseconds. So > I made a hold signal out of a comparison between the encoder out and the > S_H's first stage out. But, and this is what I think is actually biting > me, the encoder and the S_H's have to have a conv_float_to_s32 and vice > versa wrapped around them. > > So I may as well just go ahead and either junk the whole idea, or figure > out something that does not need all the float to s32 and vice versa. > > Sample_hold is s32 except bit "hold", and the man page doesn't even say > what state is hold & what state is fall-thru. > > comp is float, incompatible with the S_H > > Sum2 is float, incompatible with the S_H > > So the processing chain is too long and likely in the wrong addf > sequence. But it would be a huge help if we had a float version of the > sample_hold. > > Any chance of that ever happening? > > I'll test the theory that the filter delay is the culprit by bypassing > the filter. > > Another possibility is that at the instant of polarity reversal going > into the .command port of pid.s, a reset signal could be slammed into > the pid.s to cancel any effects of the spindles overshoots in the wrong > direction, the lack of which is causing a windup in the pid. Halscope > should be able to show me that I would think. But how to generate that, > I haven't a clue, but that almost HAS to be the cause of the > windup/catchup. > > A 2nd question then, pid.s.error-previous-target, bit in, should be what > for a velocity loop such as a spindle? Currently set true, by pncconf & > I haven't touched it. > > Anybody else got a better idea? > > Thanks all. > > Cheers, Gene Heskett ------------------------------------------------------------------------------ _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
