[etherlab-users] Kollmorgen AKD drive doesn't like to be last

Wed Nov 6 23:50:34 CET 2019

Yes, although if there is some slave with closed ports in the network then writing 00 will open that slave but not any slaves further downstream of it (the change doesn’t take effect until after the end of the current frame, and may take several more cycles to negotiate link after that too).

Having said that, all slaves should default to 00 (auto) anyway – that’s the reset state of the ESC.  Only if a slave has some other persistent firmware/configuration override (which hopefully would be documented) might that differ.  I’m not familiar with that particular slave, so I don’t know if that applies to it or not.

Gavin Lambert
Senior Software Developer

[cid:logo_compac_5dcf97ef-52f5-498c-8b9b-728410ddffaf.png]
[cid:compacicon_82e8a8c7-154a-4a32-9720-a5badb6258e0.png]<http://www.compacsort.com> [cid:facebook_fa85b924-53b9-45cc-8162-0564f64ec3a3.png] <https://www.facebook.com/Compacsort>  [cid:linkedin_4ec016ad-84fa-443c-85a3-b9615a4ccef8.png] <https://www.linkedin.com/company/compac-sorting-equipment/>  [cid:youtube_32142163-fc27-4aed-b14d-e8a377f98a6d.png] <https://vimeo.com/compacsort>  [cid:twitter_d89338d8-98c8-4b65-9a9e-7b1333160b0d.png] <https://twitter.com/compacsort>  [cid:insta2_1cd85de9-b3a2-4971-9904-52b2481a7c82.png] <https://www.instagram.com/compacsort/>

COMPAC SORTING EQUIPMENT LTD | 4 Henderson Pl | Onehunga | Auckland 1061 | New Zealand
Switchboard: +64 96 34 00 88 | tomra.com<http://www.tomra.com>

The information contained in this communication and any attachment is confidential and may be legally privileged. It should only be read by the person(s) to whom it is addressed. If you have received this communication in error, please notify the sender and delete the communication.

From: Hugh Sparks <hugh at csparks.com>
Sent: Thursday, 7 November 2019 11:33
To: Gavin Lambert <gavin.lambert at tomra.com>; etherlab-users at etherlab.org
Subject: Re: [etherlab-users] Kollmorgen AKD drive doesn't like to be last

Thanks for the quick answer. I'll try it ASAP. (I'm not at the customer site.)

I'm broadcasting a zero byte to register 0x101 (second byte of ESC DL Control) to all slaves. Shouldn't that make all ports automatic?
H. Sparks

On 11/6/2019 3:31 PM, Gavin Lambert wrote:

Try running "ethercat slaves -v" against one specific AKD slave (in a working network) and see whether its ports are configured for auto-close or manual close.  Compare it with other slaves, if possible.

Usually slaves should default to fully auto, so that they will loop packets back when there's no other downstream slave.  But they can be configured to manually keep a port closed even when they detect a new downstream slave (to avoid disrupting the network until you're ready to configure it) or to keep it open even if there's no slave (which is normally a bad thing, but maybe there's some reason it might be useful?).  Perhaps this latter is the case for your drives?

Gavin Lambert

Senior Software Developer

COMPAC SORTING EQUIPMENT LTD | 4 Henderson Pl | Onehunga | Auckland 1061 | New Zealand

Switchboard: +49 2630 96520 | https://www.tomra.com

The information contained in this communication and any attachment is confidential and may be legally privileged. It should only be read by the person(s) to whom it is addressed. If you have received this communication in error, please notify the sender and delete the communication.

-----Original Message-----

From: Hugh Sparks

Sent: Thursday, 7 November 2019 10:20

To: etherlab-users at etherlab.org<mailto:etherlab-users at etherlab.org>

Subject: [etherlab-users] Kollmorgen AKD drive doesn't like to be last

I have several Kollmogen AKD drives that work perfectly anywhere on my ring except the last position. If an AKD is at the end of the "row", it doesn't seem to be turning the frames around properly. Is this some configuration option I'm missing? I've never seen this behavior from other motor drives...

Thanks for any insights!

H. Sparks

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20191106/44a4fd47/attachment-0004.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo_compac_5dcf97ef-52f5-498c-8b9b-728410ddffaf.png
Type: image/png
Size: 11438 bytes
Desc: logo_compac_5dcf97ef-52f5-498c-8b9b-728410ddffaf.png
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20191106/44a4fd47/attachment-0035.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compacicon_82e8a8c7-154a-4a32-9720-a5badb6258e0.png
Type: image/png
Size: 1629 bytes
Desc: compacicon_82e8a8c7-154a-4a32-9720-a5badb6258e0.png
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20191106/44a4fd47/attachment-0036.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: facebook_fa85b924-53b9-45cc-8162-0564f64ec3a3.png
Type: image/png
Size: 1750 bytes
Desc: facebook_fa85b924-53b9-45cc-8162-0564f64ec3a3.png
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20191106/44a4fd47/attachment-0037.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: linkedin_4ec016ad-84fa-443c-85a3-b9615a4ccef8.png
Type: image/png
Size: 1855 bytes
Desc: linkedin_4ec016ad-84fa-443c-85a3-b9615a4ccef8.png
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20191106/44a4fd47/attachment-0038.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: youtube_32142163-fc27-4aed-b14d-e8a377f98a6d.png
Type: image/png
Size: 1970 bytes
Desc: youtube_32142163-fc27-4aed-b14d-e8a377f98a6d.png
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20191106/44a4fd47/attachment-0039.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: twitter_d89338d8-98c8-4b65-9a9e-7b1333160b0d.png
Type: image/png
Size: 20278 bytes
Desc: twitter_d89338d8-98c8-4b65-9a9e-7b1333160b0d.png
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20191106/44a4fd47/attachment-0040.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: insta2_1cd85de9-b3a2-4971-9904-52b2481a7c82.png
Type: image/png
Size: 1506 bytes
Desc: insta2_1cd85de9-b3a2-4971-9904-52b2481a7c82.png
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20191106/44a4fd47/attachment-0041.png>