Sounds interesting, although a rolling buffer would probably be more generally useful (for all but the startup case). This is basically what EC_DEBUG_IF does; other than being disabled by default, why wasn't that suitable?
The method that I usually use to debug traffic issues is to insert a dumb hub/switch between the master and first slave, and additionally connect another PC running Wireshark to spy on the traffic. (For best results, disable the TCP/IP bindings on the monitoring PC to avoid injecting non-EtherCAT packets, although EtherCAT nodes will ignore these anyway.) And it's reasonably portable; you just need an extra network cable and some power, no software changes at all. You can go even better by adding a dedicated network monitoring device (which guarantees not to accept packets from the monitoring PC), but I find that the above is sufficient for most purposes, especially since EtherCAT packets are sent as broadcasts. 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> 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: etherlab-dev <etherlab-dev-boun...@etherlab.org> On Behalf Of Graeme Foot Sent: Tuesday, 11 June 2019 13:41 To: etherlab-dev@etherlab.org Subject: [etherlab-dev] pcap logging patch Hi, In case anyone is interested I've attached a patch for an EtherCAT comms logging function: /features/pcap/0001-pcap-logging.patch This will cache the first 30mb (defined under PCAP_SIZE) of EtherCAT comms traffic to memory in pcap format. It adds a pcap command to the ethercat tool utility, which also has a reset option to clear the cache and continue logging. I know there are already other debug options, i.e.: - Debug level 2, will print the EtherCAT comms to syslog direct - EC_DEBUG_IF, which creates a local IFACE port that gets the EtherCAT comms traffic mirrored to it (to be logged in wireshark locally or from a remote computer if the debug IFACE is bridged to a real IFACE) - EC_DEBUG_RING, will print the EtherCAT comms to syslog if Debug level > 0 Warning: EC_DEBUG_RING uses the do_gettimeofday() method. This is not safe to be called from an RTAI realtime thread. It will freeze your system if you only have one CPU. It should use jiffies instead. None of the options above really suited my situation as I wanted to track down intermittent startup issues at client sites. The Syslog rotates too quickly and has other information in it and the Debug IFace option was not suitable to set up at a client site. Regards, Graeme Foot Kinetic Engineering Design Ltd.
_______________________________________________ etherlab-dev mailing list etherlab-dev@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-dev
