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
