On Mon, Jul 27, 2015, at 11:29 AM, Brian wrote: > On Mon, Jul 27, 2015 at 10:34 AM, Sebastian Kuzminsky <[email protected]> > wrote: > > > I agree with Andy, backlash compensation belongs in Motion, since that's > > where the trajectory is planned. > > > > Motion can insert a backlash compensation "move" when a joint changes > > direction, and compensate for the time that the backlash move takes by > > not moving the other joints (except that possible backlash moves on > > other joints may happen at the same time). > > > > > An external hal component that tried to do that would have to capture > > and buffer all the joint waypoints that Motion was generating during the > > backlash move, then when the backlash move is finished either try to > > catch up to Motion (which would violate the accel & vel that Motion had > > planned), or stay behind Motion from then on out (which would introduce > > lag on things that immediately affect the trajectory, like Feed Override). > > > > > Looking at the code, this does not appear to be the case. As it appears, > backlash is ramped in and added to the joints position target without > affecting the movement of any other joints. See "control.c" line 1871. > Yes, this means a joint executing a backlash move will lag behind its > target position until the backlash move is complete. Can anyone else > confirm this?
I believe you are correct. Look at the diagram here: http://linuxcnc.org/docs/html/code/Code_Notes.html#_block_diagrams_and_data_flow In particular, note that the screw comp module is computing velocity using a d/dT calculation. I cannot vouch for the accuracy of that drawing. I drew it, and I wrote the corresponding code - so it was accurate at that time. But the code was written about a decade ago, and it is quite possible that other folks have improved it since then. > Regardless, the point I would like to address right now is whether it would > be a welcome change or not. Its technical feasibility can be determined > during its implementation. Obviously we want everything to work correctly > and logically. In principle, making things more modular is always good and welcome. But in practice, the technical feasibilty does come into play. If the only way to pull screw comp out of motion is to add several more HAL pins to motion so that the screw comp module can be aware of motion internals, then perhaps it shouldn't be pulled out. Referring back to the block diagram, I can see one specific issue that would need to be resolved: See the box labeled "motor offset", which is summed with the screw comp output? That value is determined during homing and stuffed into that box by the homing routine. It needs to be added to output (and subtracted from feedback) on the motor side of the screw comp block, so that screw comp knows the absolute axis position, not the more-or-less "random" motor position. (Motor position varies depending on where the axis was when the power was turned on.) Another implementation detail is how to get the screw comp data to the compensation component. Realtime HAL components don't have a clean way to access files (such as a file that contains a screw compensation curve). Motion gets a variety of data from user-space already, and the screw comp data piggybacks on the same data structures and user/realtime communication link. A stand-alone screw comp component would have to solve that problem another way. > > Brian > ------------------------------------------------------------------------------ > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers -- John Kasunich [email protected] ------------------------------------------------------------------------------ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
