[Etherlab-users] dynamic PDO unmapping
Richard Hacker
ha at igh.de
Fri Sep 18 10:16:07 CEST 2020
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.Foot at touchcut.com>
> Envoyé : vendredi 18 septembre 2020 01:06
> À : BUSSIERES Vincent <vincent.bussieres at hemeria-group.com>; Sebastien BLANCHET <blanchet at iram.fr>; etherlab-users at 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-bounces at etherlab.org<mailto:etherlab-users-bounces at etherlab.org>> on behalf of BUSSIERES Vincent <vincent.bussieres at hemeria-group.com<mailto:vincent.bussieres at hemeria-group.com>>
> Sent: Friday, 18 September 2020 03:01
> To: Sebastien BLANCHET; etherlab-users at etherlab.org<mailto:etherlab-users at 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-bounces at etherlab.org<mailto:etherlab-users-bounces at etherlab.org>> De la part de Sebastien BLANCHET
> Envoyé : jeudi 17 septembre 2020 12:29
> À : etherlab-users at etherlab.org<mailto:etherlab-users at 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 at etherlab.org<mailto:Etherlab-users at etherlab.org>
> http://lists.etherlab.org/cgi-bin/mailman/listinfo/etherlab-users
> --
> Etherlab-users mailing list
> Etherlab-users at etherlab.org<mailto:Etherlab-users at etherlab.org>
> http://lists.etherlab.org/cgi-bin/mailman/listinfo/etherlab-users
>
>
More information about the Etherlab-users
mailing list