Re: [Emc-developers] suggestions to improve HOMECOMP/HOMEMOD custom homing infrastructure
> > Is there any plan of eventually removing internal homing and only using a > homing component? I know it is a big ball of mud in there but perhaps separating motion's > homing logic out from the motion module would be less code overall and also > allow custom homing schemes as well. Thats pretty much what Dewey has done. Homing.c has become a default homing component but you can now create custom homing components installed from the ini file or command line. Ref: http://linuxcnc.org/docs/devel/html/man/man9/homecomp.9.html HIs latest improvements allow you to use the existing procedures defined in homing.c which reduces the additional custom code you have to write. Before that you basically had to include almost all of the homing.c code in your new component. There are a lot of functions dealing with homing sequences and joint axes that generally don't need changing in a custom homing module. Rod Webster *1300 896 832* +61 435 765 611 Vehicle Modifications Network www.vehiclemods.net.au On Thu, 21 Apr 2022 at 05:52, Curtis Dutton wrote: > Is there any plan of eventually removing internal homing and only using a > homing component? > > I know it is a big ball of mud in there but perhaps separating motion's > homing logic out from the motion module would be less code overall and also > allow custom homing schemes as well. > > > > > > On Tue, Apr 19, 2022 at 8:50 AM Dewey Garrett wrote: > > > > > > 1. Could the normal component period variable be > > > implemented in a HOMECOMP? Currently its not supported. > > > > servo_period is included in the homing.h:homing_init() function: > > Ref: > > > https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/motion/homing.h#L43 > > > > A user-built homing module that supports custom homing > > functionality for some joints *and* conventional/legacy > > LinuxCNC functions for other joints has required > > replicating many parts of homing.c in the custom module. > > > > i have been working on a new branch that simplifies > > inclusion of code from homing.c to allow unmodified > > and/or augmented use of any of the base homing api > > functions. > > > > The example homecomp.comp has been updated to > > demonstrate methods to select conventional or custom > > api functions for each joint according to hal pin > > settings. > > > > Ref: https://github.com/LinuxCNC/linuxcnc/commits/dgarr/homebase > > > > (lightly tested, runtests passes) > > (The api (homing.h) is not changed) > > > > -- > > Dewey Garrett > > > > > > > > ___ > > Emc-developers mailing list > > Emc-developers@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/emc-developers > > > > ___ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] suggestions to improve HOMECOMP/HOMEMOD custom homing infrastructure
Is there any plan of eventually removing internal homing and only using a homing component? I know it is a big ball of mud in there but perhaps separating motion's homing logic out from the motion module would be less code overall and also allow custom homing schemes as well. On Tue, Apr 19, 2022 at 8:50 AM Dewey Garrett wrote: > > > 1. Could the normal component period variable be > > implemented in a HOMECOMP? Currently its not supported. > > servo_period is included in the homing.h:homing_init() function: > Ref: > https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/motion/homing.h#L43 > > A user-built homing module that supports custom homing > functionality for some joints *and* conventional/legacy > LinuxCNC functions for other joints has required > replicating many parts of homing.c in the custom module. > > i have been working on a new branch that simplifies > inclusion of code from homing.c to allow unmodified > and/or augmented use of any of the base homing api > functions. > > The example homecomp.comp has been updated to > demonstrate methods to select conventional or custom > api functions for each joint according to hal pin > settings. > > Ref: https://github.com/LinuxCNC/linuxcnc/commits/dgarr/homebase > > (lightly tested, runtests passes) > (The api (homing.h) is not changed) > > -- > Dewey Garrett > > > > ___ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] suggestions to improve HOMECOMP/HOMEMOD custom homing infrastructure
> 1. Could the normal component period variable be > implemented in a HOMECOMP? Currently its not supported. servo_period is included in the homing.h:homing_init() function: Ref: https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/motion/homing.h#L43 A user-built homing module that supports custom homing functionality for some joints *and* conventional/legacy LinuxCNC functions for other joints has required replicating many parts of homing.c in the custom module. i have been working on a new branch that simplifies inclusion of code from homing.c to allow unmodified and/or augmented use of any of the base homing api functions. The example homecomp.comp has been updated to demonstrate methods to select conventional or custom api functions for each joint according to hal pin settings. Ref: https://github.com/LinuxCNC/linuxcnc/commits/dgarr/homebase (lightly tested, runtests passes) (The api (homing.h) is not changed) -- Dewey Garrett ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
