Yes, velocity control. There are two basic ways to go. Decide what you are going to measure. Decide based on how fast the motor runs at lowest speed and the the PID loop period.
Method #1. Count the number of encoder ticks. Every PID loop interval your error signal is the courted number of ticks minus the expected number of ticks. You speed is measured in "ticks per period" This works well if speed always is more then a couple hundred ticks per period and works very poorly if at thelowst speed setting you only get a few ticks per period. Best if about a thousands or so. Method #2 Capture the system timer at each encoder tick and then subtract the last tick's time and computer seconds per encoder tick (or nanoseconds per) and The motor speed is then "average period per encoder tick" Or "time per tick" Even PID loop period you reset average. This works best if you only have a few encoder ticks per PID loop cycle. and the Error signal is the average measured tick period minus the expected period. Obviously you need a timer resolution 100 times better then the encoder tick period even at the fastest motor speed. Microseconds work but some times nanoseconds are needed. The goal is to have at least three digit speed numbers. the PID algorithm wants decent resolution in the error estimate. If yo have a low resolution spindle encoder and it is moving slow and you sample at a fast rate like 20Hz. and use method #1 the error will always be either -1, 0 or 1. An the controller will never work But if you measure nanoseconds you will always have fine resolution in the error and will alway be able to detect some error, no matter how small. So FIRST check to see how good you system is at measuring velocity. Adjust the PID loop period and the method of measurement (#1, tick count or #2 tick period) If you can't get god error estimates PID can never work as it depends on an error signal. It is easy to see why people like 2,000 count optical encoders, the controller gets LOTS of good data. I think in your case, maybe use a longer PID loop period and make corrections one;y 10 or 5 times per second and low gain. You need good stability and enough time per PID interval to collect accurate speed data. The longer loop period means you can average longer and reduce noise in the velocity measurement On Mon, Oct 30, 2017 at 3:44 PM, Gene Heskett <[email protected]> wrote: > On Monday 30 October 2017 15:20:35 andy pugh wrote: > > > On 30 October 2017 at 17:49, Gene Heskett <[email protected]> wrote: > > > Which is computationally less cpu usage 1, a 6 pack of mux2's, or > > > another pid with separate settings and just one mux2 to select which > > > pid gets sent to the spindle servo? > > > > PID is not very CPU intensive, neither is mux2. I wouldn't really > > worry about either. > > > > You can see how much CPU time each module uses in HAL. > > > > The "lincurve" component was intended specifically for this type of > > situation, which is why it has outputs of the r/w style that can be > > connected directly to the pre-2014 PID gain pins (which for no good > > reason were bidirectional) > > > > But in this case mux2 seems more appropriate if it is a simple switch > > between states. > > > Between pid.sh.output and pid.sl.output. When I get everything else > working again. Probably not yet tonight as I had to come and do > something about an empty skillet for dinner. > > However, I suspect that your problem is that you are trying to use P > > on a controller that only really needs FF0 and I. > > A dc powered spindle is a velocity servo I think, so I been trying to > follow John Thorntons wiki article from 2012 where he describes tuning a > axis servo in the velocity mode. Is this the wrong approach for a > spindle that needs to have quite stiff control? > > And I just found his other description of spindle tuning, where its all > FF0 and Igain. That one however doesn't describe the hardware setup at > all, nor does it have any halscope pictures. I suspect that the spindle > John was calibrating was being driven by a vfd, which is inherently a > pretty stiff drive. > > But when I get it back to where I can run it (I'm in the middle of moving > the spindle power control sequencer from the 5i25 P3 to the same on P2, > which feeds a different bob in a different box. And reconnecting it to > where I can use an A axis with those pins, and while I am up on the > ladder, I'll get the individual boxes bolted together to prevent another > short that blew a chain of 5i25's). > > I really ought to build another, even bigger box, at least another 3" > deeper, and 4 or 5" taller so the A driver could fit inside it. Unforch > that would take another half a sheet of 1/8" alu plate to go with the > close to half a sheet I have on hand. > > So many projects, so little 'extra' time. :) > > 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 > -- Chris Albertson Redondo Beach, California ------------------------------------------------------------------------------ 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
