On Monday 30 May 2016 13:35:35 Peter C. Wallace wrote: > On Mon, 30 May 2016, Gene Heskett wrote: > > Date: Mon, 30 May 2016 12:47:26 -0400 > > From: Gene Heskett <[email protected]> > > Reply-To: "Enhanced Machine Controller (EMC)" > > <[email protected]> > > To: [email protected] > > Subject: Re: [Emc-users] PID tuning 7i92 stepper > > > > On Monday 30 May 2016 09:19:25 Peter C. Wallace wrote: > >> On Mon, 30 May 2016, [email protected] wrote: > >>> Date: Mon, 30 May 2016 7:07:14 +0000 > >>> From: [email protected] > >>> Reply-To: "Enhanced Machine Controller (EMC)" > >>> <[email protected]> > >>> To: "Enhanced Machine Controller (EMC)" > >>> <[email protected]> Subject: [Emc-users] PID tuning > >>> 7i92 stepper > >>> > >>> So I never did get to tuning the PID for the 7i92, now that other > >>> things are working sensibly, this is next on my list. > >>> > >>> So I tried to follow: > >>> http://gnipsel.com/linuxcnc/tuning/servo.html > >>> > >>> Plotted .ferror, .joint-vel-cmd, .motor-pos-fb > >>> > >>> I see the .joint-vel-cmd, but .motor-pos-fb never moves from 0, > >>> even if the scale is tiny. Axis move just as intended. .ferror > >>> is just noise under 10u. Looks like quanitization noise. > >>> > >>> Am I missing something? Is there a different procedure for the > >>> unique 7i92 PID loops? > >>> > >>> 1KHz servo thread, and: > >>> > >>> # PID tuning params > >>> DEADBAND = 0 > >>> P = 1000 > >>> I = 0 > >>> D = 0 > >>> FF0 = 0 > >>> FF1 = 1 > >>> FF2 =0.00013 > >>> BIAS = 0 > >>> MAX_OUTPUT =0 > >>> MAX_ERROR =0.0005 > >>> > >>> Danny > >> > >> axis.N.motor.pos-fb has to be changing with a move or you would get > >> a following error > >> > >> Note that HalScope has a bug that causes it to not look at new > >> signals until you stop and start the DAQ ( this means you must set > >> the run mode to stop and back to the desired display mode after > >> adding a new pin,signal, or parameter trace ) Maybe this is whats > >> happening > >> > >> > >> There's really no tuning involved, those values are fine > >> > >> P= 1/servo period in seconds > >> > >> FF1=1 > >> > >> FF2=seconds between position read and velocity write > > > > I have been using the servo-thread loop time, eg for a 4 kilohertz > > servo-thread, FF2 = 0.00025, or for a 1 kilohertz servo-thread, > > 0.001. But by this definition I just realized that this figure would > > not change with the servo-thread rate as long as the machine can do > > it, and it appears the machine in question isn't the least pushed by > > 4 KHz rate. glxgears runs ok on another workspace, as does > > konversation or firefox, none display any lags while LCNC is > > running, and moving the machine. > > > > So, how is this "time thru the loop from read to write" to be > > measured Peter? Is there a timer that we can reset and start at the > > read, and snapshot at the write that could be displayed on a > > halmeter to give us an elapsed nanoseconds "swag" display on this? > > Its possible with DPLL based configs but not currently implemented in > the driver (also the time is so short with PCI/PCIE cards that its > really not important)
My addf does the read first, then all the processing and the correction write last in the same servo cycle, so the elapsed time isn't so trivially short as to be instant. Everything read that needs action is still processed between the read and write addf's. So its not the read/write times of the card, near as much as all the tap dancing hal does with that data before it writes the result back to the card that mentally concerns me. I have the vision of zeroing and starting a timer, then doing the read and all the hal dancing, then snapshotting the timer after the write and putting in on a hal pin the halmeter could display. > > I am thinking this might be one of the reasons I can't use very much > > Pgain with either spindle. I have enough Pgain for a good "stiff" > > drive but its nowhere near 1/servo period in seconds, else it > > oscillates, on the lathe, hard enough to break drive parts. > > The 1/servo-period P gain applies only to perfect 1st order control > loops (the hardware stepgen is a nearly perfect 1st order system). A P > gain of 1/servo-period means that any detected error is corrected in > the next period. This does not work with general servo or spindle > controls as they have way too much phase lag to allow that much P gain So it seems, too much inertia, particularly in the lathe with its relatively massive chucks. And I expect the relativly coarse timing info delivered by an optical sensor that can be considered as quantized to the last edge that passed is effectively tons of noise. I wrote a filter that averages the last 4 edge times to get the instant velocity, and that amount of noise reduction has been quite helpfull. But it also intros a time lag, equ to a max lag of 5.3 degrees rotation, not much in comparison to the mass of the spinning parts, so the net result has been quite positive for me. I also wrote a gizmo that tells me, if I watch it with a halmeter, how much spindle overtravel there is at the in the hole end of a G33.1 for rigid tapping. The mills spindle, if not drive restricted, can do a full reverse in maybe 100 milliseconds at 200 rpm. But I have found I nust profile that reversal drive with a limit3 to stretch that reversal, else the axis doing the following is overrun, generating a following error. However since this takes place at near zero speeds, the MAX_ACCEL's can be cranked up quite a bit since the stepper has full power available at that point to both takeup any backlash and keep up with the spindle accelleration in the opposite direction. At 1000 spindle revs in backgear, the overshoot is over 4 turns, but at 200, its half a turn. A smaller tap, allowing the backgear to be in high, and those times shrink about 40%. > >> (FF2 is not very important and could just be set to 0 for the > >> majority of machines ) > >> > >> > >> > >> Peter Wallace > >> Mesa Electronics Thanks for any ideas here Peter. 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> ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
