Funny, I just did another on-line class that covered PID. The behavior you describe seems to be common. The class used an elevator example and said it was 1,000 kilograms and used a 1,000 kg counterweight and we assume zero fraction. The car would shoot up the building and with all that mass just keep going and oscillate forever and never stop at the 20th floor. Then they fix that and find another problem and fix that. In the end we have a working elevator but...
The next step is to see why PID is not very good at this. It is reactive and can't plan ahead. For example, it can't say "I am only a few floors away from my target I'd better apply the brakes. So now there is a way to do that with motion planning and optimizers. PID is just a poor way to do an operation like "move to THAT location". PID is a very good way to do "Please hold your location constant". For the format it is best o use a motion planner that can look ahead to the future. LinuxCNC actually does this. Not being a LinuxCNC internals expert, I see why maybe this is why we get advice to use a force or torque based PID rather than position-based. A location PID can work. The elevator worked but with performance far lower than desired the trick is to tune it. Start with all PID constant at zero. Notice that nothing moves. Then make P high until it oscillates then back down. Then set D to a larger and larger absolute value (D might need to be negative, depending on how things are set up). Finally to see that the system can not hold the set up on has a constant bias, so make I larger until that is fixed. This is very primitive and ad-hoc but generally works. The next level is to play with limits on output and the stored "I" integrated error total. I now know enough control theory to know what I don't know. What I don't know is a formal mathematically valid way to do a provably optimum "move to location". It SHOULD run the motor at the highest torque and current levels to accelerate and then to break and end up right on the mark and also observe any limits on speed, acceleration, or "jerk". and hit the mark dead-on first try. LinuxCNC should be able to do this. So the question is how to set up a "go to THAT location" in LinuxCNC On Tue, Dec 1, 2020 at 12:33 PM Gene Heskett <[email protected]> wrote: > On Tuesday 01 December 2020 10:49:41 Gene Heskett wrote: > > > On Tuesday 01 December 2020 03:36:14 Gene Heskett wrote: > > > Has anyone setup the at_pid to autotune at lcnc startup? > > > > > > If so, some good starting value suggestions would be appreciated as > > > I've not a clue as to good values to use. I think one could use a > > > pyvcp led to indicate the autotune is done and ready for use. > > > > > > It seems to me that it could be used to compensate for the weight of > > > the 160mm chuck, or lack of it, or the weight of the workpiece > > > mounted. Right now, its suffering hugely from windup, taking a > > > minute or more to sort of settle after I take my finger from one of > > > the [] keys. But I have not a clue what the scale may be, as I don't > > > actually have the motor driving the bs-1 yet, nor do I have a home > > > switch on it yet so I can measure the scale. > > > > > > Waiting on hardened 6mm redi-thread to mount the motor with. And a > > > better motor and vfd for the 6040 I'm making parts with. redi-thread > > > shoulda been here Friday. the bag of nuts from the same place came > > > Friday. Sigh.... > > > > > > Cheers, Gene Heskett > > > > Commented out that and index-enable and its running. Had 1.5" of snow > > at 7AM, and I now have 3" of snow at 10:45 local. > > > > Cheers, Gene Heskett > > And so far its made 1 move in one direction, set stuff to crazy values > and stopped, and has not made an effort to move to move the axis since > despite restarting from scratch a couple times. But, in going back to > the normal pid, I start to get the desired results until the motor > inertia causes a decel overshoot, which reverses the motor at pretty > decent rpms, killing the 350 watt psu which shuts down from the > overcurrent pulse and takes about 2 or 3 minutes worth of powerdown to > recover. Intolerable in service. > > I have > FF1=1, and > Pgain=250000, 500000 oscillates violently and if just moving a short > distance, the stop-null is a pid.error below .002xxxx in 95% of the > tests. I could tolerate that but not the psu shutdown. > > So what do I turn up in order to better decelerate it in anticipation of > the upcoming null/stop? And do I have to turn it way up? Dgain=0.2 did > not seem to have any of the desired effect, yet its way too much for > steppers, but does it need scaled way up like Pgain is? > > 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) > If we desire respect for the law, we must first make the law respectable. > - Louis D. Brandeis > Genes Web page <http://geneslinuxbox.net:6309/gene> > > > _______________________________________________ > Emc-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-users > -- Chris Albertson Redondo Beach, California _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
