EtherCat axis Homing strategies -> Offset from PDO 0x60BA

rodw wrote:

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.

No. As already described, the accuracy will be limited by the EtherCAT cycle time when normal "home to index" is used (option #1). Using #3, the accuracy is instead limited only by the drive's internal encoder update rate - in my case between one and two orders of magnitute better than LinuxCNC's servo rate. With 12.5 mm/s slow homing speed, the inaccuracy will decrease from about 2600 counts to perhaps 130 (if by "tens of microseconds" Omron means 50 µs), or from >0.01 mm to <1 µm - *and* allows a higher homing speed while doing so. A homing speed that can be configured as usual in the INI file since the motion is controlled by LinuxCNC. These are the benefits that #3 brings.

This is neither better nor worse than internal homing I guess, just a different flavour.

by Ethercat cycle time, I meant the actual ethernet time used by Ethercat (not the servo thread) which was estimated on one source to be about 153 Usec depending on the environment.

The only way I could see #3 was useful was if the drive had persistent memory of the probe position and the LCNC home offset was able to be reconfigured to use the difference between the current position and probe register position. This would be a form of immediate homing without any motion. Without persistent memory, you would have to seek to find the probe so you might as well use internal homing which is already supported.

Whether you edit the ini file or edit the xml file to establish the machine homing configuration is pretty immaterial in my view.

rodw wrote:

by Ethercat cycle time, I meant the actual ethernet time used by Ethercat (not the servo thread) which was estimated on one source to be about 153 Usec depending on the environment.

How would this affect method #3?

rodw wrote:

The only way I could see #3 was useful was if the drive had persistent memory of the probe position and the LCNC home offset was able to be reconfigured to use the difference between the current position and probe register position.

Please see this previous post for an idea on how to use the latched value.

I think it gets complicated to follow your suggestion. At the point the probe was set, I don't think motion ceases so when the probe signal fires.  The drive would have overtravelled before LCNC stopped it so you would have to change modes in the drive to seek to the probe position so you could pass the exact  position back to linuxcnc for it to be homed precisely.

If you use homing, motion is stopped at the exact point the sensor is triggered so just turning off the index-enable is sufficient for linuxcnc to zero to that position and home.

Setting the offset dynamiclly might be easier.

It would work exactly as Switch + Index homing, just with a more accurate position value for the index pulse. I don't know why you continue to complicate things so - it must be deliberate(!?) so I think I'm done here, unless the original poster gets back for a constructive discussion.

(I also note that you don't explain how EtherCAT cycle time would affect this metod - because of course it won't, since the latching is entirely internal to the drive.)

I'm not trying to complicate things but it is complicated if you want the desired accuracy!

I have spent the last couple of weeks working on internal homing of CIA402 drives so have a pretty good understanding of the topic. 
If the probe is still moving, you won't get the desired accuracy.

Say the probe triggers 0.1 milliseconds seconds into a servo cycle, the position won't be registered by linuxcnc for another 0.9 milliseconds during which time the axis will have continued to travel at our 12.5mm/second. This means it could be 0.0125 *.9 = 0.01225 mm out of position when the index is reset to zero the position. That's not what you are looking for.

Whereas using homing, the drive stops dead on the mark and is stationery for that 0.9 ms so when the index is reset, it is dead on.