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.f...@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-boun...@etherlab.org> *On Behalf > Of *Mohsen Alizadeh Noghani > *Sent:* Tuesday, 2 October 2018 10:50 PM > *To:* etherlab-users@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 > > >
_______________________________________________ etherlab-users mailing list etherlab-users@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-users
