Long initialization of Ethercat on servo drive SV660N

I asked Grok:
the official linuxcnc Ethercat driver at github.com/linuxcnc-ethercat/linuxcnc-ethercat does not currently support EoE (Ethernet over Ethercat) drives such as the SV660N drive. Can you suggest modifications to the code to enable EoE support?
And he gave a very comprehensive answer.

Its far to comprehsensive to share on the forum due to formatting but I saved hos answer to markdown and converted to pdf which is attached

 

I think they all describe steps to bring data in and out of the drive, steps that are missing in the lcec case. SOEM mentions fragmentation/defragmentation. Not more complex than that. I haven't found out if the hardware I have can be used for a prototype.
I'll keep searching.

Did anybody get it to run with Rods guide??

E.

endian wrote:

Did anybody get it to run with Rods guide??

E.

I don't think it works.  The master is meant to sense if of EoE is available but 2 things collide.
1. There is a bug affecting this drive in the ethercat master
2. the Linuxcnc  driver does not support EoE

I think without the bug it should fall back to supporting non-EoE mode but its a long time since I looked at this.

It's the same for all EoE-enabled slaves, not just this one.

Ethercat master creates a handler, documentation page 104  docs.etherlab.org/ethercat/1.6/pdf/ethercat_doc.pdf

Creation of EoE Handlers
During bus scanning (see section 5.4), the master deter-
mines the supported mailbox protocols for each slave. This is done by examining the
“Supported Mailbox Protocols” mask field at word address 0x001C of the SII. If bit
1 is set, the slave supports the EoE protocol. In this case, an EoE handler is created
for that slave.

The queue in the EoE handler needs to be processed by the EoE state machine. And that is what doesn't happen.
The queue gets filled up and everything stops. Lcec should process the queue regularly when
in cyclous mode, to get packets in and out. That's the code that need to be in place and I think
that is what grok and Chatgpt both are proposing. And also kworm identified that.
Three out of three, majority win right?, so I think that's what's needs to be done.

There is no disabling of EoE support in the Ethercat master code. As in the quote above, if byte 0x38 (word 0x1c) is "1"
in the right place, EoE handlers are created, queue gets built up and everything stops.

What people do are 
1. Read out the eeprom and change that "1" in byte 0x38 to "0" and write back the new eeprom contents to the drive.
Ethercat master will then identify no support for EoE and go on with that track.
2. Disable EoE altogether in the Ethercat master with ./configure --disable-eoe during build.
The outcome is the same as above. No EoE processing, no queues that build up.

So what is broken and what isn't? Don't fix what isn't broken. It looks like the Ethercat master is broken, but that is not the case.
It is doing its part. Lcec on the other hand doesn't do what it should do to make EoE work. Lcec should regularly
process the EoE queue that are being built up. That's what needs to be added.

I have looked at what I have and I don't have any equipment with EoE to practice on. 
I can always buy one, it's an interesting enough task, but EoE servo drives seems to cost multum.
And I haven't really found one. Looks like I'll be standing on the sidelines cheering.


 

Ran into a Yaskawa Servo with EoE that needs that have EoE disabled.

Time to open an issue  github.com/linuxcnc-ethercat/linuxcnc-ethercat/issues/458