On Sunday 20 September 2015 11:28:51 Gene Heskett wrote: Update below.
> Greetings; > > I have an apparent nominally 30% difference between the requested > speed from the spindle's pid, and whats coming back from the encoder. > > Background: > > I have a limit3, named rvsaccel, between motion's speed-rps output pin > and the pid.s.command pin useing it as a maxaccel limiter. > > I have some hal stuff that feeds a small tickle value into the bias > pin of that pid, equ to about 20 rpm but dependent on the sign of the > signal from motion. Trimmable in the .ini file as FBIAS and RBIAS. > > Everything thru the pid is unity gain, but some more hal stuff also > sets the pid.s.maxoutout to 0.98 of whatever the 5i25's pwmgen.scale > is set to. pwmgen scale currently in the 28 range based on the top > speed of about 2800 when the drive is wide open. That way, a click on > the plus or minus button is supposed to be 100 revs a click > > The encoder disk has 67 slots, one of which is longer and is the > index, so the encoder scale is 67x4=268. > > But an MDI command of s1000m3, returns just under 20 rps average at > the encoder.0.velocity output, not the 16.666667 that came out of the > pid. > > Sure, I can bring up the pid.Igain which will forcibly correct it but > its way too slow to do it, so an m3-m4, or vice versa reversal results > in a huge overshoot in the opposite direction before it can settle at > nearly the correct speed again, as in if turning about 1005 revs fwd, > an m4 will cause it to run up to about 1600 revs before it settles to > around 1005 in reverse. By slowing down the rate of reverse with the > limit3, I can make it take 10 seconds to do the reversal, but the > magnitude, 60-65% of this overshoot does not change! Its just done in > very slow motion. The amount of Igain to achieve this is above unity, > up to 5.0 before instability sets in. The spindle speed is then VERY > stiffly maintained, perhaps more than needed so I use 2.0 to 3.5 > there. > > Smaller versions of the overshoot are seen in just changing the speed > with an s command, from 1000 to 100 actually results in a very > momentary stop, then resumes at the new speed, or from 100 to 1000 > will shoot up to 1500 or so before it settles. True in both > directions, so its symmetrical. And it is not affected by bypassing > my cobbled up encoder noise filter whose worst case latency to a new > valid output is 4 servo-threads=4 milliseconds, but it also reduces > the noise to 25% of what comes out of the encoder. > > So, is there a method to reset the pid's Igain to zero, or even > perhaps to change its sign, at least until a near module has indicated > its just reached the correct speed? > > OR a way to reset the scale of the pwmgen that will not restrict its > range, but which will match the requested to the result. > > This latter could be done with a mux2 switching the gain of a scale > module between the pid.output and the pwmgen.value in, switching the > mux2 from one preset value to the other according to a tally switch on > the high/n/low knob. This would require additional hal stuff to reset > the pid.s.maxoutput accordingly, getting even more complex and hard to > trace, and additional inputs to be configured and built. Not > impossible of course, but a PIMB* to do. > > This effect is seen regardless of the pwmgen "scale" multiplier used > as that avenue has been explored without seeing a trend toward > correctness. Maybe I am missing something so obvious its not been > considered? > > Suggestions please & thanks everybody. > > *PIMB, pain in my back, the disk collapse seems to be proceeding, > pinching nerves ever tighter. And that would require I go back to my > skyhook & deer hoist to get the driver box off the high shelf above > the operating computer. > > And the only place it might be a real problem is in doing some rigid > tapping at high enough revs that the table or head could not keep up > at the instant of the overshoot during the reversal at the end point > set. It was not a problem with the head in low gear at 300 revs while > doing some rigid tapping, driving a 10-24 tap last week. IOW I didn't > break the tap. ;-) > > Cheers, Gene Heskett I did find by gross changes in the pwmgen.scale that there was a detectable effect, and I wound up set at 46. This also required that I quadrupled the tickle bias for very low speeds, like 40 rpm. Then I was able to tweak FF1, FF2, Pgain and Igain, and just a red hair of Dgain, while watching the m4-m3 results on the halscope. Now, an m3 when it was turning 2G's in reverse, shows the pid.output and the encoder velocity converging to a flat line in about 400 milliseconds, with no overshoots. Amazingly, even if I allow rvsaccel to do it quick, the only effect is the clipping of the max + output of the PID, but the PID out, and the encoders velocity still meet as a flat line on the halscope with no overshoots. That was the desired action/result, and I obviously have a VBWSEG. ;-) We really really need a good tut on tuning this stuff. Thanks all. Now I need to make another bit of pcb into a tool contact, and rewrite the blanket-chest-3.ngc file to run a pointed roundover bit to complete the carving of those Green & Green joints in this blanket-chest. I s/b able to play in white pine by tomorrow afternoon. 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
