EtherCat axis Homing strategies -> Offset from PDO 0x60BA

Hi experts,

as far as I know, the homing strategies for a cia402 axis can be devided in (at least) 3 main strategies:

1. everything via LinuxCNC
   the axis has some kind of homing switch witch is directly connected to the LinuxCNC-PC (for example via Parallel Port) or not directly (attached to the cia402 and looped through it - appears as hal-input in LinuxCNC) and LinuxCNC itself handles the Homing Motion and HomintPosition-Logic
   As configured in the ini-file, theres a coarse movement (state HOME_SET_COARSE_POSITION in homing.c) and a fine movement (state HOME_SET_SWITCH_POSITION in homing.c
2. everything handles the cia402 drive
   the homing procedure is configured on the cia402 drive, the homing switch attached to the cia402 drive.
   LinuxCNC calls the cia402drive and waits until it has finished its preconfigured homing procedure
3. mixed mode
   the homeswitch - or the RefMark of an analog Encoder - is attached to the cia402 drive; the cia402drive latches the homePosition, but motion is controlled by LinuxCNC
   some (or all) cia402 drives allow the cia402 to configure a touch probe functionality - either on a RefMark of the encoder, or an external switch (see PDO 60B9h - TouchProbe function) - in a way, that when activated, the drive-internal Position is stored in an seperated object (i.e. PDO 60BAh) when the TouchProbe is triggered. The clue is, that even in this activated mode, the motion is controlled by the master LinuxCNC, but the HomePosition is latched without the effects of the inaccuracy due to the ECat bus frequency.
   In order to realize the homingprocedure for LinuxCNC, the touchprobe has to be activated (maybe via hal-config) and the result of PDO 60BAh should be transfered back to LinuxCNC - probably into variable "offset" from homing.c

The question is now: does anyone have an idea, how the above mentioned strategy #3 can be realized or configured in LinuxCNC?

Thanks for the hints


 

I'm not even sure anything really needs to be done to support #3 which is really interesting.
Creating a hal pin is easy to do in the XML. This will appear under the lcec component.
Wouldn't you just home to index and adjust the final position in Linuxcnc using HOME_OFFSET in your ini file? 
On my drives, there are several inputs and their function is controlled by another register (again set it in xml)
You can also change the switch state from NO or NC in the XML. 
You may need to invert the state of the ethercat pin so it goes false on index.
Worst case, a small component that managed the index signal the same way cia402.comp does might be required.
 

3radfahrer wrote:

In order to realize the homingprocedure for LinuxCNC, the touchprobe has to be activated (maybe via hal-config) and the result of PDO 60BAh should be transfered back to LinuxCNC - probably into variable "offset" from homing.c

I think what needs do be done is to set joint->motor_offset = [0x60BA] (contents of the touch probe register) - joint->home_offset (HOME_OFFSET from INI file). E.g. record the relationship between the drive's idea of position and the configured home position. (If I understand the use of joint->motor_offset correctly.) I'm not sure if there is any way to do this currently.

[0x6064 position actual value] is a read only value, so acts partly like an absolute encoder, just with varying "offset" each power on. I think this is a new use case for LinuxCNC (but I hope someone can prove me wrong! ).

rodw wrote:

Wouldn't you just home to index and adjust the final position in Linuxcnc using HOME_OFFSET in your ini file? 

Interesting. How would you adjust HOME_OFFSET automatically during homing?

Wait, as rodw says what we're really doing is homing to index. Except instead of an index signal we trigger on latch status, and instead of recording position feedback we want to record the latched value.

It should be possible to use the latch status bit not only to set the joint index-enable but also to gate in the latched value from [0x60BA] into motor-pos-fb rather than the usual [0x6064 actual position] for a single servo period. Problem solved?

I'm not an expert on encoders and indexes, but you probably don't need to worry about the stored value. If you review homing.c  homing basically is applied to set the axis to position 0, then some housekeeping ocurrs such as applying home offset etc.

Perhaps the stored value could be used for instant homing if that housekeeping applied some dynamic home offsets based on the custom pin value. But I'm not sure how useful that wold be if the drive does not have persistent storage.

I did play around with adding a new in homing variable but did not really review to see if it was working. I wanted to jump straight to the start of the index processing to bypass any other extraneous precursor code.