Since I only needed to subtract the reference slave's time in each cycle
from the previous fine, method 2a worked very well. So in the cycle, I have,
#ifdef MEASURE_TIMING
ecrt_master_reference_clock_time(master, &t_cur);
printf("%" PRIu32 "\n", t_cur - t_prev);
t_prev = t_cur;
#endif
1- How is the time given by *ecrt_master_reference_clock_time() *affected
by the synchronization process? Since I'm syncing the slave's clock in each
cycle, I'm afraid that this would render this method biased in a way.
2- This
<https://drive.google.com/file/d/1rxn1oh0qfaJJi0S_hXkK6wkpe_kO1LMU/view?usp=sharing>
is the result of analyzing the value of *t_cur - t_prev, *which shows a
jitter of about 20 microseconds. Does this value match your experience?
It's certainly much lower than I expected. (I'm using a kernel without
PREEMPT_RT and the process has the maximum priority with FIFO scheduler)
Best,
Mohsen
On Sun, Oct 7, 2018 at 10:29 PM Mohsen Alizadeh Noghani <
m.aliza...@gmail.com> wrote:
> 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
