[etherlab-users] Measuring the frequency of master sending the frames to network

[Mohsen Alizadeh Noghani]

Dear Graeme,
Thanks for the excellent and detailed explanation. Since I'm already using
distributed clocks in my program, I think I just have to do capture the
packets by Wireshark and analyze the timestamps. I will look into
gavinl's patch for long-term analysis.
Best,
Mohsen

On Wed, Oct 3, 2018 at 2:49 AM Graeme Foot <Graeme.Foot at touchcut.com> wrote:

> Two options:
>
>
>
> 1) You can use wireshark on another computer.
>
>
>
> - Plug in a switch inline somewhere on your EtherCAT network, make sure it
> forwards without delay
>
> - Also plug your second computer into the switch, make sure you disable
> all protocols on the network card (but not the card itself)
>
>
>
> 1a)
>
> - In your application cycle call ecrt_master_sync_slave_clocks()
>
> - Run your application and use wireshart to log your data
>
> - Run the command:
>
> "C:\Program Files\Wireshark\tshark.exe" -r data.pcap -T fields -e
> ecat.reg.dc.systimeL > data.txt
>
> (replacing data.pcap and data.txt with your input and output filenames)
>
>
>
> 1b) If you have gavinl's patchset
>
> - In your application cycle call
> ecrt_master_64bit_reference_clock_time_queue()
>
> - Run your application and use wireshart to log your data
>
> - Run the command:
>
> "C:\Program Files\Wireshark\tshark.exe" -r data.pcap -T fields -e
> ecat.reg.dc.systime > data.txt
>
> (replacing data.pcap and data.txt with your input and output filenames)
>
>
>
> - Filter out the appropriate information from data.txt and analyse.  Note:
> wireshark will see each packet twice, once going out and once coming back
> in.  If the switch is before your reference slave then the timestamp will
> only be in the returning packet, if it's after then it will be in both.
>
>
>
>
>
> 2) analyse the info within your app
>
>
>
> 2a)
>
> - In your application cycle call ecrt_master_sync_slave_clocks()
>
> - get the 32bit clock value using ecrt_master_reference_clock_time()
>
>
>
> 2b) If you have gavinl's patch set
>
> - In your application cycle call
> ecrt_master_64bit_reference_clock_time_queue()
>
> - get the 64bit clock value using ecrt_master_64bit_reference_clock_time()
>
>
>
> - Analyse the results yourself in the app, or log to file
>
>
>
>
>
> Notes:
>
> - The wireshark message timestamp is not accurate enough by itself, hence
> using the distributed clock reference slave timestamp
>
> - EtherCAT frames are broadcast messages so you don't need to do anything
> special on the switch for your wireshark PC to be able to see them
>
> - See: https://www.wireshark.org/docs/dfref/e/ecat.html for a list of
> possible tshark ethercat fields
>
> - The EtherCAT master syncs reference slave using the lower 32bits of the
> dc clock.  If your application is running at 1khz then this value rolls
> over every 4.2 odd seconds, so gets more complicated to track long running
> time.  Gavinl's patchset adds the ability to read the whole 64bit timestamp
> using ecrt_master_sync_slave_clocks().
>
>
>
> Regards,
>
> Graeme Foot.
>
>
>
>
>
>
>
> *From:* etherlab-users <etherlab-users-bounces at etherlab.org> *On Behalf
> Of *Mohsen Alizadeh Noghani
> *Sent:* Tuesday, 2 October 2018 10:50 PM
> *To:* etherlab-users at etherlab.org
> *Subject:* [etherlab-users] Measuring the frequency of master sending the
> frames to network
>
>
>
> In motion control applications, smooth motion and small error often
> requires an update rate of at least 1 KHz.
>
> When defining a task in RTAI, we can set its execution frequency.
> Therefore, if we set the frequency to 2 KHz, the master is expected to send
> EtherCAT frames every 0.5 ms + jitter.
>
> Other than using a network probe (e.g. Beckhoff ET2000) connected to
> another PC and analyzing the timestamps, is there a reliable way for
> measuring this frequency? In other words, I want to stress test the master
> for a few hours and make sure that all frames are sent before the real-time
> deadlines.
>
> Best,
>
> Mohsen
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20181007/1ab740cd/attachment-0003.htm>