[Etherlab-users] dynamic PDO unmapping

[Richard Hacker]

Just one more thing to think about when choosing the strategy "stopping 
to queue domains": The slave has a watchdog to monitor SyncManager 
activity triggered by the output domain. If this watchdog times out 
(typically 100ms), it usually means some sort of communication failure. 
Either the control application has crashed or some form of network 
failure (cable cut, etc)

Not queuing the domain is simulating a communications failure and 
waiting for the slave watchdog to catch it... not really the intended 
use of the watchdog.

------------------------------------------------------------------------

On 9/17/20 10:14 AM, BUSSIERES Vincent wrote:
> Thank you for your answers. I'll try to place each slave into its own domain and I'll keep you informed of the result.
> 
> To my mind, the best solution, would be the servo slave itself, when it detects a fault condition, should go into a state where it ignores whatever values the master is sending. I have already asked to the slave vendor, I'm still waiting for his answer. I don't this it will be possible
> 
> Best regards
> 
> Vincent BUSSIERES
> Responsable Technique Logiciel
> 
> 
> ZE Ma Campagne
> 36, Impasse Félix Nadar
> 16000 ANGOULEME
> Tel: 33 (0)9.72.40.35.08
> www.hemeria-group.com
>  Afin de contribuer au respect de l'environnement, merci de n'imprimer ce courriel qu'en cas de nécessité.
> Ce message et les fichiers pouvant être attachés sont confidentiels, réservés à l'usage unique des destinataires et n'engagent HEMERIA sous aucune forme que ce soit.
> This email and any files transmitted with it are confidential, intented solely for the unique use of the recipients and don't commit HEMERIA.
> 
> 
> 
> 
> -----Message d'origine-----
> De : Richard Hacker <ha at igh.de>
> Envoyé : jeudi 17 septembre 2020 09:26
> À : BUSSIERES Vincent <vincent.bussieres at hemeria-group.com>; etherlab-users at etherlab.org
> Cc : Graeme Foot <Graeme.Foot at touchcut.com>
> Objet : Re: [Etherlab-users] dynamic PDO unmapping
> 
> Hi
> 
> Excellent suggestion with the domain!
> 
> In my opinion however, I would not consider changing states (to PREOP), stop sending data (domains) and the like a very good control strategy.
> It is like breaking all ties the slave has with the master. It leaves the party to go cry on its own.
> 
> Configuring the EtherCAT communication during startup is an expensive process, requiring setting up slave FMMUs and SyncManagers using register access, and maybe even PDOs using even slower CoE communication via mailbox. Once set up, the hard work is done and EtherCAT communication becomes very cheap during cyclic operation.
> 
> Much more elegant is to have the slave choose a different source for its inputs with a switch in that specific case and leave the communication intact. In this way the master can continuously watch what the drive is doing -- not a bad thing to have!
> 
> Richard
> 
> ------------------------------------------------------------------------
> 
> On 9/17/20 3:25 AM, Graeme Foot wrote:
>> Hi,
>>
>>
>> As far as I'm aware you would need to place each slave into its own domain and then not queue the domain for the slave you want to skip.
>>
>>
>> Otherwise if a domain is queued, the whole domain data is sent.  I think you would need to deactivate the master and reconfigure all the slaves to change the domains and exclude a slave from it.
>>
>>
>> Another option you could investigate is to see if you could stop the slave responding to the PDO's at the slave end.  One option would be to place the slave into PREOP.  It may take a number of cycles to transition, and the slave probably won't continue to run your embeded program so it's not a great option.  Otherwise the slave may have some SDO's that control whether it responds to the incoming PDO information, but not likely and also has SDO delays.
>>
>>
>>
>> The best option would be the first one (with multiple domains) as you have a small number of slaves.  Each domain will add a little extra overhead to the frame, but as there are few slaves they should all still fit fine in one ethercat frame.
>>
>>
>>
>> Regards,
>>
>> Graeme.
>>
>>
>> ________________________________
>> From: Etherlab-users <etherlab-users-bounces at etherlab.org> on behalf
>> of BUSSIERES Vincent <vincent.bussieres at hemeria-group.com>
>> Sent: Thursday, 17 September 2020 07:54
>> To: etherlab-users at etherlab.org
>> Subject: [Etherlab-users] dynamic PDO unmapping
>>
>> Hello,
>>
>>
>> I'd like to unmapp PDOs dynamically or to stop sending PDO data to a particular slave.
>>
>> My EtherCAT network includes 6 slaves, among them digital inputs / outputs modules and servodrives modules.
>>
>> I have developped safety functions embeded into the servodrives modules. For instance, in case of emergency stop, the embeded program reads digital safety emerency input and configures a torque setpoint to stop the motor very quickly.
>>
>> The problem is that EtherCAT master sends PDO frames continuously to all the slaves, in particular torque setpoint PDO to servodrive. Therefor the setpoint configured in embeded program is replaced by the one sent by EtherCAT master.
>>
>>
>>
>> So I'd like to know if it is possible to stop sending temporarly PDO to a particular slave or unmapp these PDOs.
>>
>>
>>
>> Best regards
>>
>>
>>
>> Vincent BUSSIERES
>>
>> Responsable Technique Logiciel
>>
>>
>>
>> [1572337113342]
>>
>> ZE Ma Campagne
>>
>> 36, Impasse Félix Nadar
>>
>> 16000 ANGOULEME
>>
>> Tel: 33 (0)9.72.40.35.08
>>
>> www.hemeria-group.com<https://webmail.nexeya.fr/owa/redir.aspx?C=GK_Bq
>> KCZef7LtPZnqnd_LGYr1NG9sz4Smy3iKIwO-pXqtJC7VgzXCA..&URL=http%3a%2f%2fw
>> ww.hemeria-group.com%2f> P Afin de contribuer au respect de
>> l'environnement, merci de n'imprimer ce courriel qu'en cas de nécessité.
>>
>> Ce message et les fichiers pouvant être attachés sont confidentiels, réservés à l'usage unique des destinataires et n'engagent HEMERIA sous aucune forme que ce soit.
>> This email and any files transmitted with it are confidential, intented solely for the unique use of the recipients and don't commit HEMERIA.
>>
>>
>>
>>
>>
>>
>>
>>