Nicklas, this will be a pretty big brain dump so please read on. This is where Dewey's work comes in to solve your problem. You can now write a custom homing component and install it using halcompile. You need to start by reading the homecomp docs http://linuxcnc.org/docs/devel/html/man/man9/homecomp.9.html Then refer to the sample code https://github.com/LinuxCNC/linuxcnc/blob/master/src/hal/components/homecomp.comp You also become familiar with homing.c https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/motion/homing.c Homing starts in homing_init() https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/motion/homing.c#L1411 You might also like to review Dominic Braun's cia402 component https://github.com/dbraun1981/hal-cia402 for CANOpen/CIA402 related stuff.
homing_init() in homing.c has been reworked so the default code is moved to base_homing_init() This allows a custom version of homecomp to totally rewrite the homing code in homing_init and other procedures who have base versions in homing.c So a custom homing module for CANopen devices might live in a file called canopen_home.comp and contain its own version of homing_init() that starts the homing process and just waits until the drive signals homing is completed, then set the joint.N.homed pin to true. Dominc has some useful stuff in his component and triggered homing using joint.N.index-enable But Daniel and I found this was not enough, changes to homing.c was required. Then Dewey released his custom homing module we are discussing here. Dominic's code has two functions read_all() and write_all() to transfer data to and from ethercat slaves. I think this could be quite a useful technique. I think this could be replicated in canopen_home.comp by extending void read_homing_in_pins() and write_homing_out_pins() and creating any additional CANopen pins at the joint level. I did attempt this and got close as I could init the homing process but cancelling it did not restore the correct state and I did not proceed due to time constraints. I will say working in a homecomp becomes quite complex because you have to deal with all joints at once so additional data (and pins) must be stored in static custom_home_local_data customH[EMCMOT_MAX_JOINTS]; ref: https://github.com/LinuxCNC/linuxcnc/blob/master/src/hal/components/homecomp.comp#L96 By comparison the cia402.comp only needs to deal with one joint per instance. My work on this is here https://github.com/rodw-au/ciahome but after I started, Dewey made a lot of changes to simplify writing a custom homing module. In the version I was working with every procedure in homing.c needed to be included in the comp by using the base procedures in homing.c. This is no longer required. You only need to redefine the procedures you want to redefine. So my work needs to be rewritten to follow the current code base. I hope this helps. It would be awesome if a more experienced developer could have a go at this. Daniel and I will be cheering from the side lines. I do have a CIA402 test rig set up so I am happy to test subject to time constraints. You have my email address. Rod Webster *1300 896 832* +61 435 765 611 Vehicle Modifications Network www.vehiclemods.net.au On Thu, 28 Jul 2022 at 20:12, Nicklas SB Karlsson <n...@nksb.eu> wrote: > tis 2022-05-03 klockan 13:09 +0100 skrev andy pugh: > > On Tue, 21 Sept 2021 at 15:35, Daniel Dempsey <sqmathl...@gmail.com> > > wrote: > > > > > Will try to sort out the rest of homing.c this week and hopefully > > > test on > > > the weekend when the shop is quiet. > > > > This has been sat in my inbox for months awaiting a reply. In the > > meantime, Dewey has introduced a system whereby LinuxCNC can be > > configured to support a custom homing scheme. Have you seen that > > work? > > > > Here is a sample homing component: > > > https://github.com/LinuxCNC/linuxcnc/blob/master/src/hal/components/homecomp.comp > > The docs for that component: > > http://linuxcnc.org/docs/devel/html/man/man9/homecomp.9.html > > Some commands are limited then not homed and guess motion module tell > Linuxcnc this. Looking into my .hal file there is however neither an > input to tell motion it should home nor an output connected somewhere > to Linuxcnc GUI then it is homed. Not sure what is part of the motion > module but could see it is named motmod in my .ini file. > > Pretty sure there is a problem in motion module as it always do the > homing by itself running the joint(s) setting the offsets. There is a > bit output pin in motion module indicating if homing but no possibility > to tell motion module it is done by externally and not possible tell > motion module homing is done or in an error. There is most certainly > also a need to tell motion module if home offset is added or not by > device itself then homing is completed successfully. > > > Reading CANopen document homing procedure. At first device have to be > set to special "Homing mode". There i an input bit to tell device start > or continue homing. There is also three status bits, it is in > particularly possible to tell i homing is: in progress, failed or done. > Device also do add an offset internally so should not be done by motion > module and it should also expect offset is added position to position > then homing is completed succesfully. Might be possible to access > position with or without added home offset but are uncertain. Even > though device could do homing by itself I found it work great use the > homing procedure builtin into Linuxcnc. There is however a problem > index pulse on encoder usually is to short to detect by Linuxcnc. > > > Nicklas Karlsson > > > > _______________________________________________ > 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
