Hi have made a wee bit of progress with the spindle controls on the lathe, but lower speed performance is still sorely lacking.
Current pid.s settings Pgain 125 Igain .05 FF0 100 FF1 20 maxoutput is set 1% below the pwmgen scale to keep it from hitting 100% duty cycle. Since this is a parameter, I cannot put the gearchange bewteen the pid and the pwmgen because the pwmgens scale and the pid.maxoutput limits must be maintained. pid.s.bias is the product of watching the abs.piddir outputs, which is fed from the motion.speed-rps output via a limit2 for speed ramping control. It is developed by using a abs.piddir.is-positive > bit_u32 >u32_float fed into a sum2.in0. Conversely reverse is an identical chain of is-negative > bit_u32 >u32_float fed to sum2.in1 Then since the bias isn't at pid input level but added to the output the scaling of sum2.gain0 =60.0 and sum2.gain1 = -60.0. So the output is fed to pid.s.bias with a polarity matching the command input, basically to overcome friction. It actually works fairly well as I do get quite close to matching speeds in both chuck rotation directions. But, I have a speed bias in favor of higher than requested all the way from wide open down to a s30. s5000 = 1407 s1300 = 1366 s1200 = 1267 s1100 = 1164 and it follows a reasonable straight line down to s100 = 112 s50 = 60 s30 = 40 and at s29 it stops because thats less than the minimum duty cycle so no pulse is delivered. No big deal as that is too slow for useful work in high backgear anyway, and gearchange ATM is in-circuit but running at its default gain of 1.0 on both inputs. Thats tomorrow project. Now, I have noted that changing the pid.s.maxout and and pwmgen.scale seems to also function as a method of matching speeds obtained to the requested speed and will do a bit more of that tomorrow. I have also developed a method that watches the pid.s.error and uses a sum2 feeding back on itself to keep an incremental error count that I will eventually use to switch the gearchange.sel line, basically scaling up the pid.command so as to minimize the error accumulation. I will be doing the gear shifting in the head by hand, and use the accumulated error, which can accumulate to rather large figures over time to switch the gearchange in an attempt to equalize the running error. More drive at the slower speeds is sure in order due to the loss of torque when the motor is only doing 150 rpm. But!!!!!!!! I had to change editors from gedit to geany because gedit was snatching 10 to 15 character snippets of the file and inserting then at several other places in the file, totally mucking with variable names and such. At about 1 in 20 saves I'd guess. Has anyone else had a similar problem with gedit? Its a PIMA when it happens, to have to do all that edit, restart lcnc to get the next error's line number so you can re-edit and fix it till it will actually run again. It can be 20+ minutes to fix it all again. And it totally screws with this old farts train of thought. Suggestions welcomed of course. Thanks for reading & I hope I've not muddied the issue too badly. 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> US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
