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 -- "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
