On Mon, Jul 27, 2015 at 11:48 AM, andy pugh <bodge...@gmail.com> wrote:
> On 27 July 2015 at 17:29, Brian <turbo94must...@gmail.com> wrote: > > 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. > > I think that in this case the backlash feature is where it belongs. > > motion is a loadable HAL module. It is entirely possible to have > configurations that don't use it (I sometimes do exactly that). There > probably are things that are in the motion module and shouldn't be, > but I don't think that this is one. > > For other types of backlash comp there are other ways to do it. For > example I believe that non-compensated positions are available on > other HAL pins, if needed. > If you want to create a parallel method of compensation for specific > circumstances then feel free, my only objection is that there might be > more useful uses for your time. > (Removing compensation from motion would break existing configs, and > that might be unwelcome) > > In the event that backlash comp stays, then a few HAL pins should be created to make available the information and functionality I am trying to achieve. This shouldn't break anyone's setup (not irreparably anyway). In your particular situation it might be possible to close the loop > properly with velocity-mode stepgens and PID, but that is a discussion > for a different thread. > > My goal is not to close any control loops, and moreover, this would likely suffer from the same underlying limitation: Currently, there is no provision for position feedback that is not subject to backlash comp. ------------------------------------------------------------------------------ _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
