Gene your filter theory might well be right. Because you add a measurable delay in the loop.
The other thing I found is that the load inertia of a spindle is often badly matched to the motor inertia. This causes a real head ache setting up the pid. Feed forward of the signal might help in both cases, since then the feedback amplification needed is much less. Cant help you with all the variables you refer to. cheers, j. On Tue, Sep 1, 2015 at 9:12 PM, Gene Heskett <[email protected]> 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 > -- > "There are four boxes to be used in defense of liberty: > soap, ballot, jury, and ammo. Please use in that order." > -Ed Howdershelt (Author) > Genes Web page <http://geneslinuxbox.net:6309/gene> > > > ------------------------------------------------------------------------------ > _______________________________________________ > Emc-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-users > ------------------------------------------------------------------------------ _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
