Hi Vincent,
You are going down the wrong path by stopping to send frames.
Torque setpoint is variable inside the drive and it doesn't disappear
just because you're not sending frames any more to update it.
The only one that will notice that the torque setpoint is junk when you
stop sending frames, is the SM watchdog that triggers after 100ms.
Thereafter the drive will need to do whatever it needs to do to stop the
drive, but without the help of the master.
On the other hand, what does stop mean? No torque, no movement or home
position? It quite depends on your application, any of which is
perfectly valid.
And this fallback strategy must be built into the slave any way. Just
think about the case when the ethernet cable is pulled. What will your
drive do then if it doesn't get help from the control application in the
master? In that case the drive needs some kind of backup strategy in any
case!
In my opinion you have 2 options in order of preference:
1) Let the control application in the master stop the motor, whatever
that means, but keep sending frames
2) If the master can't stop the drive because communication is ruptured,
the motor needs a fallback strategy to stop.
Richard
------------------------------------------------------------------------
On 9/18/20 9:40 AM, BUSSIERES Vincent wrote:
Hi Graeme,
I think it’s a good idea to split input and output into two different domains.
My drive is probably able to do that.
On the other side, I can’t swap the drive into velocity mode directly because
swapping can only be done when drive is in the state « switch on disabled ». So
I need to stop the drive, swap mode and restart the drive, it is not very
safety either.
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.
De : Graeme Foot <graeme.f...@touchcut.com>
Envoyé : vendredi 18 septembre 2020 01:06
À : BUSSIERES Vincent <vincent.bussie...@hemeria-group.com>; Sebastien BLANCHET
<blanc...@iram.fr>; etherlab-users@etherlab.org
Objet : Re: [Etherlab-users] dynamic PDO unmapping
Hi Vincent,
Some further thoughts:
- If your drive can handle splitting your input PDOs and your output PDOs into
two different domains (i.e. put the drives inputs into your common domain and
the drives outputs into its own domain that can be stopped) then you can still
read your drives status while not sending the outputs. The input domains
watchdog can then probably also remain active and the drive can handle a
communication loss.
- If you can map the operation mode request index/subindex (and maybe target
velocity, updated from your actual velocity) into your drives output PDO as
extra items, then you could continue all PDO communications (from a common
domain) and swap the drive into velocity mode and let the drives internal
controlled stop routine decelerate the motor. You then also shouldn't need a
custom routine installed on the drive.
Of course none of these options are actually safety rated as they all rely on
the EtherCAT master doing something. It might still be worth investigating
further a drive logic only solution (maybe similar to the second option above,
but where the slave logic puts the drive into velocity mode, so the torque from
the PDO may be ignored anyway).
Regards,
Graeme.
________________________________
From: Etherlab-users
<etherlab-users-boun...@etherlab.org<mailto:etherlab-users-boun...@etherlab.org>> on behalf
of BUSSIERES Vincent
<vincent.bussie...@hemeria-group.com<mailto:vincent.bussie...@hemeria-group.com>>
Sent: Friday, 18 September 2020 03:01
To: Sebastien BLANCHET;
etherlab-users@etherlab.org<mailto:etherlab-users@etherlab.org>
Subject: Re: [Etherlab-users] dynamic PDO unmapping
Dear All,
Thanks a lot for your help. I placed servo drive slave into its own domain.
Obviously I needed to desactivate heartbeat.
It may not be the best solution but it works....
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<http://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 : Etherlab-users
<etherlab-users-boun...@etherlab.org<mailto:etherlab-users-boun...@etherlab.org>>
De la part de Sebastien BLANCHET
Envoyé : jeudi 17 septembre 2020 12:29
À : etherlab-users@etherlab.org<mailto:etherlab-users@etherlab.org>
Objet : Re: [Etherlab-users] dynamic PDO unmapping
Hi,
I think that it would be preferable to stop the drive without
breaking/modifying the EtherCAT communication, so that you can continue to
monitor the drive when it is stopping.
Which servo drive do you have ?
If you have a Kollmorgen AKD,
- You can configure DRV.DISMODE to trigger a controlled stop when the drive is
disabled. In this case you can stop the motion by disabling the drive with the
ControlWorld Object (0x6040:0x0),
- You can also trigger a MACRO with a digital input. In this case it opens many
other possibilities.
Regards,
--
Sebastien BLANCHET
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<http://www.hemeria-group.com>
--
Etherlab-users mailing list
Etherlab-users@etherlab.org<mailto:Etherlab-users@etherlab.org>
http://lists.etherlab.org/cgi-bin/mailman/listinfo/etherlab-users
--
Etherlab-users mailing list
Etherlab-users@etherlab.org<mailto:Etherlab-users@etherlab.org>
http://lists.etherlab.org/cgi-bin/mailman/listinfo/etherlab-users
--
Etherlab-users mailing list
Etherlab-users@etherlab.org
http://lists.etherlab.org/cgi-bin/mailman/listinfo/etherlab-users
