On Tuesday 07 November 2017 00:54:07 Nicklas Karlsson wrote: > > Greetings; > > > > Some things in the man 9 pid page are too well hidden in the > > mathematical "jargon". > > > > So can we clarify a few things? > > > > like: > > pid.N.command-deriv float in > > The derivative of the desired (commanded) value for > > the control loop. If no signal is connected then the derivative > > will be estimated numerically. > > > > What for instance, would/should be connected here, and what would be > > the desired result of such a connection? And in this context, what > > is a derivative? > > Derivative is how fast the signal change. It may be estimated > numerically by using the difference between different values but > resolution might be a problem but it might be it's available by > measurement.
And we get right to the heart of the problem. This then /should/ be available from the encoder, but would likely be subject to the granularity of the encoder, which is over 1 degree of motion before a change is detected. 1.34328358208955224 degrees TBE as it has 67 slots or 264 edges per rev. In my attempts to get rid of the noise in the velocity output, which at the encoder output, has a 4 step noise component that is a 3/1 ratio between the minimum and the maximum value and varies somewhat with the rotational position of the disk due to residual backlash in the machine that made the disk, and about a 5 thou eccentricity in its mounting, and is many times the variations I see in the duty cycle and quadrature errors of a realtime external oscope looking at those signals. The periods stay well within in the 5% total variation from 50% in duty cycle, and quadrature errors aren't more than 5%, so I fail to see a cause for a 3/1 ratio of the instant velocity coming out of the encoder while it has turned 7 degrees. It to me is Way the hell out of proportion to the nominally 2 or 3% period errors I see on a 100 mhz dual trace scope. So I have constructed a fifo out of mux2's and sum2's and one comparator to generate the fifo's clocking signal when there is a difference between the last servo-thread velocity sample, and the current one, which to me indicates an edge has gone by in real time. By backwards addf'ing them, causes the last stage to be updated from the 3rd stage, then the 3rd stage is updated from the 2nd stage, repeat until the present signal value is stored in the 1st stage. Then those 4 frozen values are sum2'd with a.25 gain setting in the first stage of sum2's, which feed a 2nd sum2 to get a unity gain signal whose peak to peak noise is 1/4 what it is at the encoders velocity pin but is 2 encoder edges later. In my former configuration, this "noise" reduction allowed Pgain to be raised to around 4x what it took to make it oscillate without this "filter". The statement has been made to me that the encoders velocity output is a heavily noise filtered output. But that implies a time lag which isn't there. I fail to see why a 2 or 3 percent error in duty cycle and or quadrature results in so much noise. There simply is no way in hell that spindle can be moving at 200 rpms on one servo-thread sample, and 600 rpms on the next sample one millisecond later while its filtered display on a pyvcp tach dial says 400 rpms. Thats physically impossible due to the mass of spinning material involved. One could expand the size of the fifo, but eventually the lag in seeing a real change in the velocity due to a tap starting to actually cut will become a factor in the Nyquist response causing even more instability since thats a direct Pgain input in any feedback calculations. That of course is self defeating. The man page says I might be able to use some FF1, but 0.05 makes the whole thing oscillate at about 3 Hz. And I'm talking stopped to 500 revs, 3 times a second when 300 is requested. So, how does one get a velocity signal out of an encoder with perhaps a 5% peak to peak noise component for a 5% error in input signal timing? Good question, that... And I certainly have not found an answer. 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> ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
