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 <h...@igh.de>
Envoyé : jeudi 17 septembre 2020 09:26
À : BUSSIERES Vincent <vincent.bussie...@hemeria-group.com>;
etherlab-users@etherlab.org
Cc : Graeme Foot <graeme.f...@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-boun...@etherlab.org> on behalf
of BUSSIERES Vincent <vincent.bussie...@hemeria-group.com>
Sent: Thursday, 17 September 2020 07:54
To: etherlab-users@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.
--
Etherlab-users mailing list
Etherlab-users@etherlab.org
http://lists.etherlab.org/cgi-bin/mailman/listinfo/etherlab-users
