[etherlab-dev] Support for multiple mailbox protocols

[Knud Baastrup]

Thanks for the good explanations Gavin, that is really helpful for the general understanding of the EtherCAT Master!

I have tested a bit on below scenario in my current setup and prepared this small attached patch that await the SDO dictionary fetching to be completed for a given slave (if SDO Info is supported by the slave) before the slave is set ready for external SDO requests. It is simple and works very well in my setup.

I have also reproduced scenario 1 from the bug report  http://lists.etherlab.org/pipermail/etherlab-dev/2014/000377.html . I reproduced the error by initiating a ethercat rescan (using ethercat tool) a number of times with around 10 seconds interval and realized that the problem is caused by the EtherCAT slaves mailbox that contains some old invalid data that were never fetched because the slave was suddenly disrupted. The new scanning will use an internal SDO request to fetch the assigned PDOs (1c12), but the slave will return the data it had prepared just before it were disrupted. I believe we need to fix this in the master and ensure that the master “empties” any full mailboxes before it starts to fetch the assigned PDOs. I think this can be done by sending a check diagram and then fetch and discard the data for any slaves left with a written mailbox. This operation could be done with a new state in the fsm_slave_scan FSM. Any other suggestions?


Regards Knud


From: etherlab-dev-bounces at etherlab.org [mailto:etherlab-dev-bounces at etherlab.org] On Behalf Of Jun Yuan
Sent: 1. juli 2014 11:12
To: Gavin Lambert
Cc: etherlab-dev at etherlab.org
Subject: Re: [etherlab-dev] Support for multiple mailbox protocols

I missed that part with slave->config->sdo_configs. You're right. The ecrt_slave_config_sdo* functions is protected against concurrent CoE mailbox conversation. Yet still, the etherlabmaster may have concurrent CoE mailbox conversation with ecrt_master_sdo_download/upload functions on the one side, and the coe dictionary fetching and slave->config->sdo_requests on the other side.
I agree with you that it seems the "realtime" SDO requests and the SDO dictionary fetching should belong to fsm_slave. And even with the current etherlabmaster, the "realtime" SDO requests also have to wait when the SDO dictionary fetching ec_fsm_master_state_sdo_dictionary is being executed. Maybe we could break up the SDO dictionary fetching into small parts to allow "realtime" SDO requests and slave->sdo_requests to be handled between them. SDO dictionary fetching should have a low priority.
Regards,
Jun

On 1 July 2014 05:15, Gavin Lambert <gavinl at compacsort.com<mailto:gavinl at compacsort.com>> wrote:
On 30 June 2014, quoth Jun Yuan:
> The slave's CoE FSM instance is not controlled by the master FSM, but
> by the slave FSM itself. The slave FSM is responsible for the CoE
> requests in ec_slave_t issued directly by the user via the function
> ecrt_master_sdo_download, ecrt_master_sdo_download_complete, and
> ecrt_master_sdo_upload. These functions can be executed either in
> the user application before the master's activation, or in the
> terminal in whatever time.
>
> The master's CoE FSM instance, on the other hand, is responsible for
> the CoE requests which should executed in the background by the
> master FSM, such as automatically fetch slaves' coe dictionary while
> master is idle, those in the slave->config->sdo_requests, which could
> be issued via the ecrt_slave_config_sdo functions (which should be
> configured during the master's activation), or via the function
> ecrt_slave_config_create_sdo_request (which can be issued afterwards
> in the user application's RT thread)
Actually the ecrt_slave_config_sdo* functions set up slave->config->sdo_configs (not sdo_requests); sending of these is managed by fsm_slave_config, which in turn is managed by fsm_master in such a way that it can't occur concurrently with anything else, AFAIK.  (fsm_slave is disabled until set_ready is called, which occurs later, and fsm_master waits for fsm_slave_config to complete before entering the idle state, which is where the other SDO requests are processed.)

It does seem odd that fsm_master processes slave->config->sdo_requests (from ecrt_slave_config_create_sdo_request), while fsm_slave does slave->sdo_requests (from ecrt_master_sdo_*) and also all the *other* non-SDO ecrt_slave_config_create_*_requests.

The fsm_master code seems older; maybe it was just never moved once fsm_slave was created?  It does mean that "realtime" SDO requests don't have to wait for set_ready, but I can't think why that would be desirable given that it doesn't apply to the other types of realtime request, and given that AFAIK the set_ready calls are all made before fsm_master enters idle anyway.

Actually I'm not sure why fsm_slave shouldn't be made responsible for both of those things (config->sdo_requests and SDO dictionary scanning).  Doing that would avoid the CoE concurrency issue altogether.  (One downside is that all kinds of requests would then be delayed until the dictionary scan completed, unless this was made less monolithic.  One advantage of Frank's locking patch over this is that it would still allow other requests [except create_sdo_requests, unless they were moved to fsm_slave] to interleave with dictionary scanning, albeit at a slower rate.)

Regards,
Gavin Lambert


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20140701/284b0fa6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ethercat_152_sdoinfo.patch
Type: application/octet-stream
Size: 1601 bytes
Desc: ethercat_152_sdoinfo.patch
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20140701/284b0fa6/attachment.obj>