EtherCat axis Homing strategies -> Offset from PDO 0x60BA

rodw wrote:

Yeh, I fully understand the probe and how to access the data from the drive *snip*

And yet you invent objections like the "ethernet cycle time", that the probe position will be off due to the motor continuing its motion and so on. Either you don't have a clue (which after all the messages I've written here to explain this to you would be quite a feat!) or you're actively spreading FUD for some strange reason.

rodw wrote:

I'm not going to be wasting time on it *snip*

Great!


Edit: BTW, congratulations on the trolling, you're really good at it!

Well, please report back when you have a working homing solution using the probe with evidence of improved accuracy.

I am offended by being called a troll. Its clear we have different views but there is no need to stoop to name calling!

BTW, I think  do know what I'm doing...
Here is an Ethercat Cycle Time Calculator I used earlier today:
forum.linuxcnc.org/ethercat/44508-ethercat-installation-summary
Its not something I invented.

Here is a recent thread of mine about ethercat configuration
forum.linuxcnc.org/ethercat/44508-ethercat-installation-summary

Here is the repository I created referred to in that thread
github.com/rodw-au/linuxcnc-cia402

Here is a current thread with a lot of  discussion between Dominic and I  about cia402 homing and improvements I made to his cia402 component
forum.linuxcnc.org/ethercat/43459-ethercat-newbie-guidelines

Here is my recent Linuxcnc Branch modifying homing.c and adding a new Ini file homing parameter to further support cia402 homing
github.com/rodw-au/linuxcnc/tree/rodw-home-external

So while I might be a relative newcomer to  Ethercat, I have done my homework and I know what I am talking about.
Based on that homework and listening to other points of view on this thread (clearly not something you have bothered with), I am of the opinion opinion that using the probe will not improve homing accuracy. In fact, I believe it will not match cia402 internal homing accuracy.

But I've been proved wrong before so I look forward to the evidence (not opinion) that proves me wrong here!

 

accurate homing at probe is another opinion and can be handled in an standalone comp.

take a look at my ax5000 class or at our class_enc.c ...

1. set the drive/encoder latch/probe enable bit.
2. lcnc moves the drive
3. the drive gots its probe signal an stored the actual encoder value.
4. the drive sets its latch/probe ready bit.
5. read the latch/probe register. raw_value!
6. in the same cycle you give lcnc the ready edge ( important : in the thread order in front of motion) read the actual feedback value, calc the raw diff to the probe/latch value, add it to the probe/latch position ,
7. finished, this is the 1000% accurate Position. (like internal homing, but controlled by lcncs motion)


this can also be handled by the index-enable pin and needs no modification the lcnc source.

Thank you, db1981! Nice to have a working example. I don't know why rodw was so keen on shooting this idea down. Very strange.

2 Days not online, and such a "hot" discussion about my question. I didn't want to get someone offended...
But thank you all for your answers and suggestion.

Just from reading, the suggestion from dp1981 describes exactly my intention and seems to be the solution. Can you tell me, where I can find your files? Than I'll have a look at them. no need of modification of the lcnc sources sounds also very good

accurate homing at probe is another opinion and can be handled in an standalone comp.

take a look at my ax5000 class or at our class_enc.c ...

1. set the drive/encoder latch/probe enable bit.
2. lcnc moves the drive
3. the drive gots its probe signal an stored the actual encoder value.
4. the drive sets its latch/probe ready bit.
5. read the latch/probe register. raw_value!
6. in the same cycle you give lcnc the ready edge ( important : in the thread order in front of motion) read the actual feedback value, calc the raw diff to the probe/latch value, add it to the probe/latch position ,
7. finished, this is the 1000% accurate Position. (like internal homing, but controlled by lcncs motion)


this can also be handled by the index-enable pin and needs no modification the lcnc source.

 

arvidb wrote:

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.
 

Exactly these are the desired benefits.
On more thing is, that I have a rotationstage with an incremental encoder with reference-mark attached on the rotor of the stage. So mounting an switch to the stage and attaching the switch to lcnc is "3 steps back"
mapping the reference-mark as home-switch for lcnc would take the internal reference-mark, but with following problem: the referencemark has a "width" of only a few AngularSeconds. That means, that I have to extremly reduce the homing-speed to be sure, that lcnc "sees" this mark.

Therefor the intention of #3: why I should map the reference-mark on the home-sw in lcnc and have to slow down referencetravel when #3 can provide me a faster and more accurate solution.

rodw wrote:

...
So while I might be a relative newcomer to  Ethercat, I have done my homework and I know what I am talking about.
Based on that homework and listening to other points of view on this thread (clearly not something you have bothered with), I am of the opinion opinion that using the probe will not improve homing accuracy. In fact, I believe it will not match cia402 internal homing accuracy.

But I've been proved wrong before so I look forward to the evidence (not opinion) that proves me wrong here!


 

Regarding the improvement of accuracy:
If the pos-fb of the axis is realized by "counting revs of motor and multiplying with the pitch of the spindle" - you talked about 6.25microns step-resolution - and use a proximity-switch as index in combination with a slow homing-speed, you may be right: the effect on better homing accuracy of #3 wont be visible.
If you use dedicated scale on the axis with an reference-mark on it, I am pretty sure, that there will be an improvement of homing accuracy and repeatability

If it is realy neccessary to have the optimal accuracy for homing, especially on the machines most of us use, can of course be questioned. But this question was not the intention of my op.
 

I think it is more important to improve the homing strategy.  especially for portal axes.  At the moment, master and slave axes are looking for index signal at the same time.  Therefore, you need to adjust the mark in the same place to avoid bended machine.  I would like to see improvement on this point.  maybe first look for master, then slave and finally go to offset.

-Can you tell me, where I can find your files?

:look at linuxcnc-ethercat/src

Hi Dominik,
thanks for the files

just for my understanding:
with

... and can be handled in an standalone comp...

do you mean to add a new *.c for my drive to the "linuxcnc-ethercat/src", refere on this implementation in the "lcec_main.c" and compile linuxcnc-ethercat?
If yes, this is the "clean" implementation of the drive as a native driver I would not need to use the generic anymore, right?Or is it much more simpler, and I can do this all in the hal-configuration?
 

db1981 wrote:

accurate homing at probe is another opinion and can be handled in an standalone comp.

take a look at my ax5000 class or at our class_enc.c ...

1. set the drive/encoder latch/probe enable bit.
2. lcnc moves the drive
3. the drive gots its probe signal an stored the actual encoder value.
4. the drive sets its latch/probe ready bit.
5. read the latch/probe register. raw_value!
6. in the same cycle you give lcnc the ready edge ( important : in the thread order in front of motion) read the actual feedback value, calc the raw diff to the probe/latch value, add it to the probe/latch position ,
7. finished, this is the 1000% accurate Position. (like internal homing, but controlled by lcncs motion)


this can also be handled by the index-enable pin and needs no modification the lcnc source.