EtherCat axis Homing strategies -> Offset from PDO 0x60BA

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.
 

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.

 

Okay, so the problem here is that you haven't read the original post thoroughly and also not looked up how the touch probe function works in these drives. From the original post: "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."

This function latches the current position value within tens of microseconds of when the "probe" (in this case the index pulse) is triggered. This 32-bit position value can then be read back from [0x60BA] and fed to the joint's motor-pos-fb pin during the servo period where index-enable is also set high.

All this is described pretty well in the original post and in my post that I linked to recently. If that's not enough, please download the "Omron Accurax G5 with EtherCAT" manual to see nice timing diagrams that describe what happens internally in the drive, and what data is available over EtherCAT.

Yeh, I fully understand the probe and how to access the data from the drive but to retain that level of accuracy and pass it back precisely to a coarser system like linuxcnc is not as simple as one would think.

You can't just change the feedback to another position as there is a risk of following errors ( I have seen plenty of those in my experiments).  More importantly, Ignoring any home offsets set (which are applied after the index is reset), Linuxcnc does not seem to use the current position when homing to index. All it does is zero the position when the index-enable is reset (back to zero).This will happen on a servo thread cycle. You would have to somehow account for the difference in current position in the servo thread and the probe position registered since the last servo cycle. You could do this either seeking back to the probe position or calculating an offset to it and incrementing HOME_OFFSET somehow. Neither method is trivial.

So all in all, I think option #3 is not a viable option when a much simpler purpose built solution exits in option #2. To me #3 is trying to revert from a round wheel to a square one. I'm not going to be wasting time on it and will focus on enhancing homing.c if its required to better support CIA402 homing methods. I'd really like to implement torque/stall based homing to remove the need for home sensors. That would be cool and arguably more accurate and more repeatable than using proximity sensors.