[etherlab-users] Xenomai 3 and RTDM's Net drivers.

[Edouard Tisserant]

Hello EtherLab users !

EtherLab's EtherCAT master is being ported to Xenomai 3, and this is now
getting ready :

https://hg.beremiz.org/etherlabmaster/

I also added a new device : devices/rtdmnet.c. It is really similar to
devices/generic.c, but it uses RTDM's Net drivers instead of Linux
drivers. This new device still needs fixing, and only works in idle mode
for now - working on a fix right now.

Pre-existing devices/*.c haven't been tested. My current test bench is a
freescale imx6, with xenomai 3.0.7, using RTDM's FEC driver. Feedback
from other targets/devices would be welcome.

@Florian : keeping compatibility with Xenomai2's RTDM wasn't a priority,
and I only focused on porting to Xenomai 3. Maybe is it still possible
to be compatible using #ifdefs. If this or anything else prevents you to
merge, please tell.

Best regards,

Edouard Tisserant



___
etherlab-users mailing list
etherlab-users@etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-users

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

[Mohsen Alizadeh Noghani]

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 
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 ;
> etherlab-users@etherlab.org
> *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
> 
> 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  *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/

Re: [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  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  *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