Ed wrote: > I think I found some configuration snafus in the setup for > rotary axes... > > Situation: a Sherline-class mill with a rotary table, > starting with the stepper_xyza sample files. > > The standard_pinout.hal file has two definitions for > parallel-port pin 9: > > linksp Astep parport.0.pin-09-out > linksp spindle_on parport.0.pin-09-out > > That seems to be a simple copy-and-paste blooper, so I > commented out the spindle signal to get the table moving.
Yeah, that was probably copied from a three axis config. I'm fixing it now. > The sample inch.ini file defines the rotary axis thusly: > > [TRAJ] > ANGULAR_UNITS = degree > DEFAULT_ANGULAR_VELOCITY = 30 > MAX_ANGULAR_VELOCITY = 90 > > [AXIS_3] (incorrectly commented as "Third axis") > TYPE = ANGULAR > MAX_VELOCITY = 90 > MAX_ACCELERATION = 360.0 > STEPGEN_MAXVEL = 99.0 > STEPGEN_MAXACCEL = 396.0 > INPUT_SCALE = 40 > > I assume those units are degrees per second, which would > correspond to a top speed of 5400 deg / sec, a snappy pace > for a rotary table: 15 rpm. I think you mean 5400 degs/min. You assume correctly. Ninety degrees per second is snappy indeed, and as you found later can't be achieved. > > However, in MDI mode, > G0 A10 > > takes about 8.5 seconds for 10 degrees, about 1.2 deg/s or > 70 deg/min, nowhere near the limits in [AXIS_3].. > > Further tinkering on real hardware produced similar results > and, I think, shows the problem. > > I added steplen / stepspace / dirsetup / dirhold parameters > to the stepper_xyza.hal file to slow the step rate down to > my controller's 8000 step/s ability: a 140 microsecond step > period based on a 20 us RT thread. That works correctly for > the linear axes, which slew at 0.4 in/s, a speed entirely > peppy enough for my simple purposes. > > My rotary table has 160 steps per degree, so I changed > INPUT_SCALE to 140 and fired it up, knowing it'd take some > tuning. Why not start with 160? 8000 steps per sec / 160 steps per degree = 50 degrees per second flat out. > A dialog box informed me: > STEPGEN: Channel 3: The requested maximum velocity of 15840 > steps per second is [OK] > The last part of that message seems to be chopped off, but > the meaning is clear enough. The untruncated message should be in the system log (it came from the stepgen component which is a realtime thing running in kernel space). Use dmesg to see the whole thing. I'm not sure how that dialog works or why it was truncated. > Pressing [OK] produces: > STEPGEN: The maximum number of steps possible is 7411 per > second [OK] > > The value 15840 is exactly 99 * 160, so it expects to > produce steps at the maximum rate set by STEPGEN_MAXVEL. > The value 7411 is pretty close to the rate I expected with > the stepgen pulse settings. > > I changed [AXIS_3] to: > MAX_VELOCITY = 40 > MAX_ACCELERATION = 25 > STEPGEN_MAXVEL = 45 > STEPGEN_MAXACCEL = 28 > INPUT_SCALE = 160 > > I picked MAXVEL = 45 because 45 * 160 = 7200 is less than > the 7144 step/s limit. > > With those values the rotary table chugs along at 10 degrees > in 17 seconds, about 0.6 deg/s. The actual rotation amount > is correct (A10 turns 10 degrees), so the scale factor is > OK. > > Now, it turns out that I also set [TRAJ] MAX_VELOCITY = 0.6 > to limit the linear axes to something rational. Changing > that to 6.0 increased the rotary table speed to 6 deg/s, 36 > deg/min. > > Ah-HA! > > Conclusion: > > Somewhere inside the trajectory planner, the overall linear > axis velocity limit [TRAJ] MAX_VELOCITY is applied to the > rotary axis, where it should be using [TRAJ] > MAX_ANGULAR_VELOCITY. > > I don't see any obvious place to fix that in the HAL file, > although I'm sure it's a one-liner for the right person... > I think there should also be a separate acceleration setting > for the angular axes (DEFAULT_ and MAX_ANGULAR_ACCEL, > perhaps?), as the linear acceleration limit will likely be > painfully slow after the velocity cap Goes Away. Either > that or just use the per-axis ACCEL settings with no global > planner limit. > > Am I on the right track with all this? > If only it was that simple. Mixed angular/linear moves have been an issue in the past. Although I thought a pure angular move would use the proper feedrate. Others probably are more familiar with that issue than I am. Regards, John Kasunich ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
