Another thing to watch for is the physical layout of the cables. It’s best to use shielded cables (and make sure that the devices at both ends are properly earthed). But even then, pay close attention to where the cables are running and in particular keep the network cables physically separated from power cables or other cables that are likely to generate a lot of electrical noise.
It's also important to pay attention to the bend radius limits of the cables – and if a cable has *ever* had its limit broken, it may have damaged the shield, so you should replace the cable. Regular ethernet networks tolerate lost packets with retransmits, so you can get away with sloppy wiring (although it does cause performance loss). EtherCAT networks are much less forgiving. Gavin Lambert Senior Software Developer [cid:logo_compac_5dcf97ef-52f5-498c-8b9b-728410ddffaf.png] [cid:compacicon_82e8a8c7-154a-4a32-9720-a5badb6258e0.png]<http://www.compacsort.com> [cid:facebook_fa85b924-53b9-45cc-8162-0564f64ec3a3.png] <https://www.facebook.com/Compacsort> [cid:linkedin_4ec016ad-84fa-443c-85a3-b9615a4ccef8.png] <https://www.linkedin.com/company/compac-sorting-equipment/> [cid:youtube_32142163-fc27-4aed-b14d-e8a377f98a6d.png] <https://vimeo.com/compacsort> [cid:twitter_d89338d8-98c8-4b65-9a9e-7b1333160b0d.png] <https://twitter.com/compacsort> [cid:insta2_1cd85de9-b3a2-4971-9904-52b2481a7c82.png] <https://www.instagram.com/compacsort/> COMPAC SORTING EQUIPMENT LTD | 4 Henderson Pl | Onehunga | Auckland 1061 | New Zealand Switchboard: +64 96 34 00 88 | tomra.com<http://www.tomra.com> The information contained in this communication and any attachment is confidential and may be legally privileged. It should only be read by the person(s) to whom it is addressed. If you have received this communication in error, please notify the sender and delete the communication. From: Graeme Foot Sent: Tuesday, 5 November 2019 10:45 To: Ignacio Rosales Gonzalez <naro...@gmail.com>; etherlab-users@etherlab.org Subject: Re: [etherlab-users] Diagnostics, crc and phy errors Hi, It looks like it is just a dodgy link between device 5 and device 6. To resolve, try the following (depending on what you have handy and assuming your drives are linked by patch cables): - Unplug and replug the patch cable at both ends a few times (to try and get better contact) - Take out the patch cable and use contact cleaner on the ends and the ports - Toss the patch cable and replace (and use contact cleaner if you have it) The incoming port shows phy errors if the link to the prior component is lost for a long enough time that the phy can detect the drop. If it’s slightly less dodgy than that, a bad cable, noise or other then it can just show up as crc errors. I don’t know for sure, but if the transmit wires have a dodgy connection but the receive wires are OK, for example, it could only show up as a phy / crc error in one direction. It is unlikely to be an error on device 5 itself (unless the eth port is damaged). If the device itself has a problem I often see the two devices either side of it with errors, with no error on the problem device in the middle. e.g. (modifying your example): 2019-10-31 16:24:08.476 P0 P1 crc phy fwd crc phy fwd 0:D2 CoE Driv 0 0 0 0 0 25 1:D2 CoE Driv 0 0 25 0 0 25 2:D2 CoE Driv 0 0 25 0 0 25 3:D2 CoE Driv 0 0 25 0 0 25 4:D2 CoE Driv 0 0 25 0 93 25 5:D2 CoE Driv 0 0 0 0 0 0 6:D2 CoE Driv 0 98 25 0 0 25 7:D2 CoE Driv 0 0 25 0 0 25 8:D2 CoE Driv 0 0 25 0 0 25 9:D2 CoE Driv 0 0 25 0 0 25 This usually indicates that the device in the middle repowered / reset, so the devices either side report the error, but the device causing the problem loses its count when it repowered / reset. This is the case I have often found with bad Beckhoff ELxxxx modules. Regards, Graeme From: etherlab-users <etherlab-users-boun...@etherlab.org<mailto:etherlab-users-boun...@etherlab.org>> On Behalf Of Ignacio Rosales Gonzalez Sent: Monday, 4 November 2019 11:55 PM To: etherlab-users@etherlab.org<mailto:etherlab-users@etherlab.org> Subject: [etherlab-users] Diagnostics, crc and phy errors Hello everybody, I've suffering some errors in two machines. In both of them the dmesg shows the same [ 2093.602142] EtherCAT 0: Domain 0: Working counter changed to 18/111. [ 2093.608661] EtherCAT 0: 6 slave(s) responding on main device. [ 2093.640855] EtherCAT 0: Scanning bus. [ 2094.939242] EtherCAT 0: Bus scanning completed in 1332 ms. [ 2094.939248] EtherCAT 0: Using slave main-0 as DC reference clock. [ 2097.856277] EtherCAT 0: Domain 0: Working counter changed to 0/111. [ 2097.876311] EtherCAT 0: 37 slave(s) responding on main device. [ 2097.876312] EtherCAT 0: Slave states on main device: SAFEOP, OP + ERROR. [ 2098.032585] EtherCAT 0: Scanning bus. But logging the output of the new command ethercat crc I obtain different behaviours, In one of them the crc counter and phy counter of one of servos practically go up at same time. In the other only the phy counter in one servo is increased: 2019-10-31 16:24:08.476 P0 P1 crc phy fwd crc phy fwd 0:D2 CoE Driv 0 0 0 0 0 25 1:D2 CoE Driv 0 0 25 0 0 25 2:D2 CoE Driv 0 0 25 0 0 25 3:D2 CoE Driv 0 0 25 0 0 25 4:D2 CoE Driv 0 0 25 0 0 25 5:D2 CoE Driv 0 0 25 0 93 25 6:D2 CoE Driv 0 98 25 0 0 25 7:D2 CoE Driv 0 0 25 0 0 25 8:D2 CoE Driv 0 0 25 0 0 25 9:D2 CoE Driv 0 0 25 0 0 25 The easy solution obviously is try to reconnect all wires and change servos, but could anyone explain whats the difference between the two cases and give me some ligth in order to solve this kind of problems? For example in the the second case the phy counter is incremented in P0 of servodrive 6 and in P1 of servodrive 5. Is this a symphtom of an error in connection between 5 and 6 or an error of the servodrive 5? Kind regards Ignacio Rosales
_______________________________________________ etherlab-users mailing list etherlab-users@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-users
