Back
[00:38:19] <steves_logging> steves_logging is now known as steve_stallings
[03:15:51] <steve_stallings> steve_stallings is now known as steves_logging
[14:28:20] <cradek> grumble grumble
[14:31:18] <rayh> yup.
[14:38:15] <skunkworks> backlash still has issues? or was it fixed in head? (I try to stay away from backlash)
[14:38:52] <cradek> there is a new backlash algorithm in head/2.1 but it's relatively untested
[14:39:32] <skunkworks> hmm maybe he could test it :)
[14:45:53] <skunkworks> how did you guys end up fixing it? I remember none of the solution where liked. something about adding a line segment at each reversal.
[14:46:10] <rayh> We really should build that accel overhead thing into the step generator.
[14:46:15] <cradek> I've said it before and I'll say it again: motion should avoid all these headroom issues by requesting slightly less than the constraints itself
[14:46:45] <cradek> rayh: yep, it's stupid to make every user deal with it when it's a problem that we can easily fix
[14:47:17] <cradek> coordinated motion already asks for 95% of constraints to avoid this -- the only remaining problem is free motion (jogs, homing)
[14:47:26] <rayh> Could it be a param with a default.
[14:47:53] <cradek> not easily, since it's one of the ones read by substitution in HAL and there's no support for defaults with that scheme
[14:48:03] <rayh> Is this a HAL level problem or are we just trying to solve it there?
[14:48:54] <cradek> I think the problem is we're limiting vel and accel in two places, and floating point precision problems make them not quite agree about what the limits are
[14:51:00] <cradek> I'm afraid we have another looming problem which is how these stepgen limits interact with the new backlash compensation code
[14:51:12] <cradek> I/we should test that I guess
[14:51:47] <cradek> I think the fix is to have separate limits for regular motion and backlash "motion", the sum of which are within machine constraints
[14:54:41] <skunkworks> I suppose the backlash could be taken out at a faster vel/acc than the actual motion - because in effect your not moving the table only the lead screw.
[14:55:54] <cradek> maybe I'm wrong about needing separate limits -- when you apply backlash correction, the axis is pretty much stopped
[14:55:54] <rayh> But we don't know what mass we are trying to move during backlash.
[14:57:01] <rayh> a small 23 motor and 1/2 leadscrew is quite different from a 25mm screw and 1500 ounch inch motor.
[14:57:35] <rayh> can't type
[15:41:30] <rayh> cradek, The only question I've got about backlash comp is whether it finishes before the axis reaches max vel or if there is likely to be some overshoot.
[15:42:16] <rayh> I'm thinking of two commands like this
[15:42:20] <rayh> g0 x1
[15:42:21] <rayh> g0 x0
[15:42:52] <rayh> These serve no useful purpose but are worst case of backlash application.
[15:43:37] <rayh> the visible surface finish worst case is at the quadrants of a circle.
[15:44:30] <rayh> These visible quadrant switches will look different for climb and conventional cuts.
[15:47:58] <skunkworks> * skunkworks still trys to stay away from backlash :)
[15:48:27] <cradek> darn, ray left
[15:49:05] <cradek> there are all sorts of problems with his x1x0 case. for one thing if the machine is fast, it will "throw" the axis to the other side of the backlash, so you have an overshoot
[15:49:15] <cradek> then, the backlash comp has to move the mass of the table back
[15:49:28] <cradek> (violating your assumption that it will be turning just the screw)
[15:49:37] <skunkworks> good point
[15:49:46] <skunkworks> yeck
[15:49:52] <skunkworks> yeck yeck yeck
[15:50:04] <cradek> but worse, the planner is already wanting to accelerate at maxaccel back the other way, so there's no accel left for the backlash "move"
[15:50:34] <skunkworks> how does the circle work - does adding backlash comp - cause a circle to be 'exact stop' at the quadrants?
[15:51:07] <cradek> I don't think it will stop the fast axis at a quadrant
[15:51:15] <skunkworks> or is it some how 'blended'
[15:51:41] <cradek> it will just move the "stopped" axis, starting at the quadrant point, until it's in the right place
[15:52:12] <jepler> if you want to know what it looks like, you can add backlash to your sim configuration and use halscope to graph the motor-pos-cmd and joint-pos
[15:52:35] <cradek> true
[15:52:40] <jepler> If I understand correctly, motor-pos-cmd (a pin) will include the backlash, and joint-pos will not
[15:52:47] <jepler> (joint-pos is a param)
[15:52:54] <jepler> I don't know what it looks like myself
[15:53:04] <cradek> I don't either
[15:53:06] <skunkworks> ooh - good idea.. I just hope I don't have to use it.. It seems like there is no good solution.
[15:53:26] <cradek> there isn't, but you can do useful things in some cases anyway
[15:54:06] <cradek> so I'm back to thinking we need separate constraints
[15:54:42] <cradek> in ray's test case, the axis is accelerating at maxaccel through the entire stop and reversal, you can not add compensation there
[15:55:35] <cradek> and if you wait until "later" (the cruise phase of the second move) you're off the path if the program is slightly more complex (a Y move too)