EtherCat axis Homing strategies -> Offset from PDO 0x60BA

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?
 

I can measure distances of <0.01 mm using a dial indicator, and have preloaded ballscrews. I also don't think there's any such thing as a "standard scale"; e.g. my servos have 20 bit encoders (~5 nm resolution with 5 mm pitch screws) and expose that resolution by default over EtherCAT. While the accuracy of my machine will be nowhere near that, I do like the repeatability to be better than what I can measure, so the extra homing precision is useful to me.

The OP specifically asked about "the third option", so perhaps we should try to keep this thread on topic with a discussion on how this can best be implemented? That doesn't stop you or anyone else that prefers internal homing from working on that solution. You already have a thread where that is discussed, right?

Yes, but all the calculations I quoted still apply to option 3. I just used the standard values for my drives for reference You would have to choose your velocities carefully for probing.
Even with 20 bit encoders, your accuracy will be limited by the ethercat cycle time and possibly the traffic on the bus.

I still fail to see what benefit #3 brings for homing. Upgrading to absolute encoders is probably a better option.