> > I think that motion knows things about the required path that are > unavailable to HAL. For one, it knows the direction of travel whereas > HAL would need to compare subsequent position commands, introducing > lag at best and possibly worse problems at very low speed. > > This may be true, and serious technical issues may arise. With respect to direction not being available, that could simply be output to HAL via a pin if that is the only issue.
I think there might be an argument for having backlash compensation in > motion, and addign secondary corrections such as these with the > "offset" component. > > I am actively soliciting feedback as to the usefulness and desire for this change, so, if there is something to add, please do. It would seem though as the intention of HAL was to make LinuxCNC modular and flexable with as little or as much functionality as your machine needs. Having concepts like this hardcoded and forcing everyone to use the same model seems against the point of having such a great framework like the HAL. > > Second, it would set the stage to be more friendly for dual scale/motor > feedback, because it would give control over where the compensation is > added in the feedback loop. > > This sounds good in principle, but I would need to think about it > rather longer to work out whether it is important in practice. > > The dual feedback issue it helps solve is this. I have a Bridgeport mill with a DRO. Nothing unusual or fancy. I adder stepper motors to the X and Y handles to drive the table. Then I thought it would be great to use the DRO scales as positive feedback, so I wired those in as well. Once I got everything working, I used the DRO scales to create a screwmap of both X and Y to minimize lead error. So far, my story seems pretty typical and logical for the average LinuxCNC user. Here is where the problem occurs. I wanted to use the scale feedback as an input to motion so LinuxCNC would track the table position when the stepper drives were disabled. The only place to feed that information into motion is motor-pos-fb and it has the backlash/screw comp subtracted from it before it get to the kinematics. Because those compensations were subtracted from the scale position, the information going to the kinematics was never correct, and there is no current way to accommodate this with the way motion is written. Brian > -- > atp > If you can't fix it, you don't own it. > http://www.ifixit.com/Manifesto > > > ------------------------------------------------------------------------------ > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers > ------------------------------------------------------------------------------ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
