Loading CCAT Driver for beckhoff PLCs

[Reisande]

Currently I only have access to Beckhoff devices which use a traditional CCAT backplane. I loaded the open source CCAT driver from Beckhoff, and had to follow these instructions in order to get it to load properly: Beckhoff/CCAT#3. This is currently running 4e337b7 on ubuntu 22.04. The full bus is an el 9410 with a combination of various beckhoff analog input/output slaves. Around 12 slaves total, with an EL1110 at the end and a cable wired for cable redunancy onto the second RJ45 port on the master. Attached is the wireshark capture and the log is very short so I am just posting it here:

thread 'main' panicked at examples/discover.rs:56:14:
Init: Timeout
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

ethercrab-logs.txt

[Reisande]

WKC on the second frame send looks good, but the
.0.. .... .... .... = Round trip: Frame is not circulating seems like an issue. I can try simply sending out more frames?

[Reisande]

Did some experimentation using SOEM as a baseline, and it looks like the redundant cable is breaking things. I will add the red_rx_rx job I have written locally and test with that instead. I'll also look to see if SOEM does anything special during discovery

[jamwaffles]

Thanks for the capture. I can see:

• There are indeed 12 SubDevices detected, which is good
• The second SubDevice in the chain (is it an EL9410?) has errored and won't go past INIT state, which is why the timeout occurs. I'm not sure why it won't go any further - that info might be in register 0x134 which should be printed to the console if you have at least RUST_LOG=ethercrab=error turned on (and a logger set up).

I have an EL9410 to throw on my test rig so I'll see if I can reproduce this behaviour.

[Reisande]

I think it is an elx9410, not an el9410. Not great considering I have EL devices afterwards but it is probably fine on a test bed. I did double check the wiring when I set it up, but it looks like that could be the issue. I did end up testing with an experimental build of cable redundancy (I am running into some weird cert issues with git so I can't push right now), and ethercat did make more progress which is really good.

This issue may be either because I am reusing the same rx frame on both instances, or I may have some bad concurrency logic on the future. I am getting packets on the CCAT interface, but not on the redundant ethernet interface,

[Reisande]

Yeah the logger is set up, I have tried a few different configurations but it looks like RUST_LOG=verbose gives me the most info, but the register isn't printed out. I am just duplicating the setup logic in the regular discover example. I am seeing that the frame count which doesn't receive a response is changing every time so it is possible that the bus is working, just too slowly. I can try slowing down the bus as well

[Reisande]

Ah, another issue is that we are sending out LRW frames which aren't supported on cable redundancy afaik.

[jamwaffles]

I'm unable to reproduce this with an EL9410, although I don't have any kind of cable redundancy set up - this is just MainDevice -> EK1100 -> EL9410. Which TX/RX task are you using? Is it just the normal tx_rx_task or are you using the XDP or io_uring variants?

[Reisande]

I refactored the standard tx_rx_task into a red_tx_rx_task and rewrote the poll task to simply send frames on both sockets, then receive frames on both sockets. It might be a better idea to simply make two futures instead which send and receive a copy of both frames on each cycle.

[Reisande]

Looking at the spec, I definitely have to do that