Dear Gavin, Thanks for the suggestion. I don't have access to the pins, and I'm not sure if it's practical to identify each frame by its start or end signal for even a few seconds on an oscilloscope (the rate of transmission is too high). But I will try this method if all else fails. Best, Mohsen
On Wed, Oct 3, 2018 at 4:19 AM Gavin Lambert <[email protected]> wrote: > If you have hardware access to a slave then you can also hook a scope or > other monitor to the ESC pins which indicate sync pulses or SOF/EOF (packet > arrival). This is probably easiest if you have a custom slave or if the > particular slave you’re using exposes these for diagnostic purposes; > otherwise I don’t recommend trying to crack an off-the-shelf slave open to > try to access these signals. 😊 > > > > *From:* Graeme Foot > *Sent:* Wednesday, 3 October 2018 12:20 > *To:* Mohsen Alizadeh Noghani <[email protected]>; > [email protected] > *Subject:* Re: [etherlab-users] Measuring the frequency of master sending > the frames to network > > > > 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 > <https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.wireshark.org%2Fdocs%2Fdfref%2Fe%2Fecat.html&data=02%7C01%7Cgavin.lambert%40tomra.com%7C7fd3e029a6144a91fc0608d628bd96f4%7C4308d118edd143008a37cfeba8ad5898%7C0%7C0%7C636741192100743022&sdata=mAIOwRdHbZDk2mim4zVEMgoMtPz%2FAMSWUCQPmHXUh0o%3D&reserved=0> > 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 <[email protected]> *On Behalf > Of *Mohsen Alizadeh Noghani > *Sent:* Tuesday, 2 October 2018 10:50 PM > *To:* [email protected] > *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 [email protected] http://lists.etherlab.org/mailman/listinfo/etherlab-users
