All my machines - steppers and servos are running pid. I think Peter forgot to mention - The reason PID is recommended is because it handles latency spikes way better. We have seen situations where a latency spike confuses the hell out of position mode stepgens. (ymmv)
On Thu, Oct 28, 2021 at 4:42 AM Gene Heskett <[email protected]> wrote: > On Wednesday 27 October 2021 14:35:30 Ted wrote: > > > Greets - although I haven't read every post of late, I've been an LCNC > > follower since we had BDI's of EMC; LCNC has been my platform of > > choice for many projects. > > > > Like many, I started with software stepgens driving open loop > > steppers, and although my shelves are full of them, I typically reach > > for a Mesa board and position-capable servos these days. I have a > > particular love for Yaskawa and Allen Bradley drives, and Yaskawa or > > Fanuc motors. Typically I end up mixing brands from ebay finds when we > > hit the 3Nm mark (or 500w, whichever comes first), so for my own gear, > > it's never a perfect numerical match, but with appropriate care it > > functions fine. > > > > I recently decided to redo my lathe (a Tsugami NCM, 6" chuck, 2" bore, > > 12 station turret, 6 station live) which I had a rather old (perhaps > > 2.3) LCNC on, more to work on a custom glade gui, as well as try and > > stay more up to date, particularly with the RT kernel changes. (Yes, > > it was that old). > > > > The prior command path was LCNC Axis gui -> motmod -> Mesa Stepgen > > position mode, quadrature out -> AB Ultra 100 drive in position > > follower mode -> AC servomotor with encoder -> drive encoder output > > electronically geared 1:1 -> Mesa Encoder input, scaled in inches -> > > LCNC axis feedback. Effectively that was a closed loop stepper system, > > wherein the feedback came from the encoder (motor) shaft - and this > > all worked well. It sounded like a servo (velocities didn't sound like > > a stepper), it acted like a servo and its following was really close > > both in time and position. Enough for the things I was cutting. (ok, > > it held +/- 5 tenths in 12L steel) > > > > In having read some past posts, it became clear that the old config > > files I had were not going to be easily translatable, so I gave > > Stepconf a try (something I haven't used in years). Although it > > generated "working" configs, I was really puzzled by the inclusion of > > PIDs and their connection in the command chain, despite the fact I was > > still using the Mesa stepgens. > > > > I figured it must have been an update I missed, perhaps a > > higher-performance path with the new motion planner (recalling I did > > skip a lot of the posts during the early PathPilot discussions), so I > > just went with it. > > > > I was completely unable to get either axis to respond consistently. > > Sometimes the drive would fault because of improper quadrature state > > (namely changing pulse states while disabled), or it would move 0.5 > > inch one way, then 1.0 inch the other way, despite scaling matching > > the real world. Sometimes on an 0.1 move it wouldn't move at all, and > > would wait for my FERROR to get almost limited out then it would snap > > the full distance. > > > > I'm not new to PIDs; in an earlier time between steppers and position > > servos, I used to enjoy the task of tuning both torque and velocity > > loops. (preferring velocity, though). However I have not until now > > observed both pid error and command increase in the same direction > > before, wherein the PID just seemed to be oblivious. > > > > I chalked it up to the possibility that my servos and drives, although > > mismatched but working prior, may have reached their useful life. > > Other potential electro-mechanical variables such as connectors could > > easily be the culprit, so I decided for another upgrade - a pair of > > brand new Bergerda 1500w servos. > > > > Those arrived a week back; I'm very happy with them. After mounting > > and checking appropriate defaults, I wrote a quick hal config so I > > could test the base pulses-per-inch for drive against the > > newly-installed glass scales I decided to add to the mix. With this > > combination, I expected that there really weren't any assumptions - > > the glass scales have a known resolution, wherein the > > drive->motor->screw although numerically believed to be known, may > > have been a little off due to age or manufacturing tolerances. however > > things like rotor pole counts, internal electronic gearing and actual > > screw pitch were no longer going to be of issue. > > > > Without too much trouble I found base scale, velocity and accel from > > the Mesa stepgen (51010 scale, 9.0 vel, 7.0 accel) - which gave me > > more than acceptable rapids, and the 5um glass scale has an encoder > > scale value of 5101.0. Mathematically, yes, it should have been 5080 > > or some multiple, but clearly there is a small amount of error in the > > system compared to my other metrology gear. That might get tuned > > closer to the mathematical real once I get the ability to cut again. > > > > However, in using a clean new StepConf generated config, with the > > above values, the system just seems to want to drift into oblivion on > > its own. Similar PID discontinuities as described above. No amount of > > simplicity in tuning (even down to PID=1,0,0, FF0=1, FF1=0) would > > cease the drift. This isn't microns of drift - it's tens of > > thousandths per second (1-5mm / sec or so). This is also the first > > time I have observed the PID output to remain locked at 0 if FF0=0. > > Thus my knowledge of LinuxCNC's PID module config is clearly outdated. > > > > > > So here's the big question - is there some major change that would > > prevent me from using the Mesa stepgen mode 0 (position) without the > > PID and use the glass scale as the feedback source? Is there a change > > to the motion planner that doesn't try to get the position to track > > continuously anymore on its own, and is that why the PID is in place? > > The PID just seems to be a clunky insertion just to force the stepgen > > to run in velocity mode, so unless I completely missed the reasoning, > > I'm not sure why the extra effort. > > > > Much obliged, > > > > Ted. > > I have 4 machines ranging from a 7x12 lathe, an 11x54 Sheldon lathe, and > a couple 4 axis mills. Only one machine is using PID's and I'm > considering removing them. All axis motors are driven by steppers, one, > the sheldon, by 3 phase stepper servo's. Those are a breath of fresh air > and within their current tech limits with a choice of 1, 2, or 3NM, all > in nema23 frames, I am very pleased with them. If I live long enough, I > will likely put them on everything. Dead silent at surprising speeds and > at least 2x faster than regular 2 phase steppers. They slso have fault > outputs that you can hal couple to shut down linuxcnc if they hit > something that prevents their moving as commanded. The next machine to > get that conversion will be my G0704 mill as I made an A axis for it > from a chinese BS-1, the PID's ability to reverse if it overshoots is > being a PITA, tripping the servo motors psu by trying to reverse it when > its turning the armature of the driving motor the other way, which > crowbars its psu, shutting it down for about a 3 minute cooldown. The > stepper servo corrects its own errors in such a situation without > complaints as long as the TP knows its accel rates, which are phenomenal > IMO. The motors builtin encoder goes only to the driver box, while > linuxcnc is getting the stepgen output for feed back. The encoder error > determines the motors driving current, so the motor runs around 50C > cooler than a 2 phase stepper with its fixed current when it doing > normal g1 moves. > > On the G0704, the only really usefull PID is in the spindle driver, which > combined with a PICO pwm-servo driver, is hitting the OEM motor hard > enough to double its horsepower to around 2, and can if I dance on the > m3/m4 keys, reverse it from 3k fwd to 3k reverse (or vice versa) in > under 400 milliseconds. I am doing that reversal on 3 machines by > sequencing the reversal in hal and controlling the accel, even though 1 > has a vfd, if programmed correctly, I can reverse the 8" chuck on the > sheldon from 500 fwd to 500 reverse or vice versa in just over a second > and about 3.5 turns of overshoot. At 100 revs, a good rigid threading > speed, the overshoot on the sheldon is .25 turns, I have stuff in the > hal file to measure that and display it in turns and distance moved in > real time. No PID's in the sheldon config as its all being done by a pi, > at first a pi3b, now a pi4b, and its loafing. I did that just to see if > I could, and I'd run the whole lot of these on pi's if the interfacing > was cheaper. The pi's, with monitors use less than 20 watts. > > PID's are great for spindles, but if there is a vfd, its not really > needed, all I need the spindle encoder for is thread timing. And that's > indepedent of having a PID in the path since the threading follows the > spindle encoder and doesn't care if the motor is working hard even if > it stalls. > > Whats not to like? :o) > > My $0.02 Ted. Other will no doubt disagree. > > 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, 1940) > 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 > _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
