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.

rodw: The idea is to get better time resolution for the position at the index mark. When LinuxCNC sees the index bit, it only knows the index was hit sometime during the last servo period. The current position feedback will be close, but not correspond exactly to the position when the index was hit. The drive on the other hand can latch the position within "tens of microseconds" (quote from the manual of my drives), so the position latched by the drive will be more exact.

Well in that case, It seems to me option 3 just brings added complexity for no value. Wouldn't the same level of accuracy be achieved from internal homing?
Wouldn't our efforts be better directed towards getting linuxcnc to fully support external homing?

I made a start on an instance if Linuxcnc on this branch of my repo
github.com/rodw-au/linuxcnc/tree/rodw-home-external

Here an ini file setting HOME_EXTERNAL should jump straight to setting joint.N.index-enable to commence homing of a cia402 drive. We can control what happens from ther ewith conditionals based on that flag. If anybody could devise a way to test this, please clone it and give  give it a go (after checkout rodw-au-home-external branch),

I was planning on doing a pull request to linuxcnc  if this ever becomes useful.
 

Yes, internal homing should give the same accuracy. I guess it's a matter of taste: I like the idea of using the same homing procedure regardless of drive interface, and of LinuxCNC being in control. And if homing to probed index position can be done without any code changes I guess it could be argued that it's less complex.

Best would of course be to have support for both, so we can choose!

Well on first glance tens of microseconds sounds like an order of magnitude over linuxcnc  but is it?
The drives use velocity expressed as pulses per second and position in pulses. This is something I think you may be forgetting.

Lets convert that to mm per pulse for my drive. This will be the resolution of the drive.
The standard scale is 800 pulses per revolution and I will be using 5mm pitch ballscrews
The default slow speed homing velocity is 2000 pulses per second. That is the final homing velocity.
so distance per pulse = 5/800 = 0.00625 mm per pulse (6.25 microns). Thats 0.15875 inches.
Travelling at 2000 pulses per second, each pulse takes 0.0005 seconds or 500 microseconds

So tens of microseconds response is useless. 

Linuxcnc on the other hand will see 2 pulses per millisecond so its resolution = 0.00625 mm * 2 = 0.0125 mm (12.5 microns or 0.3175 inches)

So it can be seen at default settings, the internal homing is double the accuracy of linuxcnc, but how many of us have a machine capable of pulling those accuracy numbers?