[Etherlab-users] dynamic PDO unmapping

[Richard Hacker]

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_BqKCZef7LtPZnqnd_LGYr1NG9sz4Smy3iKIwO-pXqtJC7VgzXCA..&URL=http%3a%2f%2fwww.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.
> 
> 
> 
> 
> 
> 
> 
>