[etherlab-users] Slave lost forever after power cycling
Joachim Sällvin
joachim.sallvin at corpowerocean.com
Tue Feb 18 12:02:33 CET 2020
OK, many thanks for all your suggestions.
I will try them, but I'll be out of office for a while so it may take some time. I'm using IgH EtherCAT master 1.5.2 35e7f0841303. Any suggestions on what to read to gain deeper knowledge about "station addresses" etc?
Best Regards,
Joachim Sällvin
________________________________
Från: Gavin Lambert <gavin.lambert at tomra.com>
Skickat: den 18 februari 2020 00:23
Till: Graeme Foot <Graeme.Foot at touchcut.com>; Joachim Sällvin <joachim.sallvin at corpowerocean.com>; etherlab-users at etherlab.org <etherlab-users at etherlab.org>
Ämne: RE: Slave lost forever after power cycling
FYI, to expand on that last point a little: as I understand it, there is an ambiguity in the EtherCAT protocol between “station addresses” and “alias addresses”. The master usually uses the latter for identification and the former for communication, but there is a brief period during initial bus scan where the slave does not yet have a station address and will only respond using its alias address. (Or the absolute ring position, which is the mode used to set the station addresses in the first place.) But the EtherCAT protocol itself does not distinguish between these two address types.
Additionally, even once the master configures a station address, the slave might still answer to either of its station address or alias address. And if it does have dipswitches then it’s up to the slave itself whether the switches overrule the alias or vice versa.
Usually, this is not a problem when all the slaves reboot at the same time or if your aliases are very different from the station addresses, but if there’s a collision between the station and alias addressing with a slave that’s rebooted by itself then you could potentially get cross-talk where the master receives responses from the “wrong” slave.
As it happens, Etherlab uses the one-based absolute ring position (1..#slaves) as the station address, so these are always small numbers and ideally should be avoided when choosing alias addresses.
I believe TwinCAT uses a different range for station addresses, though it’s been a while since I looked at it. (Possibly somewhere around 1000..+#slaves, IIRC?)
Gavin Lambert
Senior Software Developer
[cid:logo_compac_5dcf97ef-52f5-498c-8b9b-728410ddffaf.png]
[TOMRA]<http://www.compacsort.com> [Facebook] <https://www.facebook.com/Compacsort> [Linkedin] <https://www.linkedin.com/company/compac-sorting-equipment/> [Youtube] <https://vimeo.com/compacsort> [twitter] <https://twitter.com/compacsort> [instagram] <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: Gavin Lambert
Sent: Tuesday, 18 February 2020 11:39
To: Graeme Foot <Graeme.Foot at touchcut.com>; Joachim Sällvin <joachim.sallvin at corpowerocean.com>; etherlab-users at etherlab.org
Subject: Re: [etherlab-users] Slave lost forever after power cycling
While I’m not disputing that it might work like that, this sounds a bit backwards. Assuming that the “parameters” are SDOs, these are usually temporary until reboot while “ethercat alias” updates the EEPROM and is usually permanent.
Actually, it seems quite suspicious that in the example below there are still four slaves after power cycling, but that you appear to now have a duplicate AL1930.
If you’re not using the unofficial patchset, it might be worthwhile trying that out.
If you are using the unofficial patchset, something else you could try is to add --disable-sii-cache to your configure options and rebuild. The cache is something which (if it goes wrong) could possibly cause apparently duplicated slaves when aliases are used – although I can’t think of how it could be going wrong at the moment, it doesn’t hurt to try.
Another thing that might be useful to try is to use larger and/or more widely spaced alias addresses (if supported by your slaves) – I usually prefer to avoid the low numbers to avoid confusion with relative addressing.
Gavin Lambert
Senior Software Developer
[cid:image001.png at 01D5E653.8E63B1F0]
[TOMRA]<https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.compacsort.com%2F&data=02%7C01%7Cgavin.lambert%40tomra.com%7C0503defff1934efb65e008d7b3fa4740%7C4308d118edd143008a37cfeba8ad5898%7C0%7C1%7C637175759824083968&sdata=4tnU0VZcWyzydh67xZCMArxuBzz%2FCAnbontcdMnQyTs%3D&reserved=0>[Facebook]<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.facebook.com%2FCompacsort&data=02%7C01%7Cgavin.lambert%40tomra.com%7C0503defff1934efb65e008d7b3fa4740%7C4308d118edd143008a37cfeba8ad5898%7C0%7C1%7C637175759824083968&sdata=uuCeRGw0q9e2SvV%2F8MMoiK6kRQHybJmsKbHNAEV3ZeQ%3D&reserved=0>[Linkedin]<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linkedin.com%2Fcompany%2Fcompac-sorting-equipment%2F&data=02%7C01%7Cgavin.lambert%40tomra.com%7C0503defff1934efb65e008d7b3fa4740%7C4308d118edd143008a37cfeba8ad5898%7C0%7C1%7C637175759824093964&sdata=OH8rJbO4NK03vTwg05ejC8XwL7XCwm4n0fHbEL%2Fb0LM%3D&reserved=0>[Youtube]<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fvimeo.com%2Fcompacsort&data=02%7C01%7Cgavin.lambert%40tomra.com%7C0503defff1934efb65e008d7b3fa4740%7C4308d118edd143008a37cfeba8ad5898%7C0%7C1%7C637175759824093964&sdata=qzphQ5IG8VeO%2BzZMEY8eV0MNfstYpNOIZATpjrW66eI%3D&reserved=0>[twitter]<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Fcompacsort&data=02%7C01%7Cgavin.lambert%40tomra.com%7C0503defff1934efb65e008d7b3fa4740%7C4308d118edd143008a37cfeba8ad5898%7C0%7C1%7C637175759824103957&sdata=Irh7Jc9k6gPnk7CMleJNtc9ndMSmymUzv%2FcSVRHXwBY%3D&reserved=0>[instagram]<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.instagram.com%2Fcompacsort%2F&data=02%7C01%7Cgavin.lambert%40tomra.com%7C0503defff1934efb65e008d7b3fa4740%7C4308d118edd143008a37cfeba8ad5898%7C0%7C1%7C637175759824103957&sdata=xVcLXEbp8cL7xAQ9QM5%2FMv4MxUMwGR6z37T%2BycCtB7w%3D&reserved=0>
COMPAC SORTING EQUIPMENT LTD | 4 Henderson Pl | Onehunga | Auckland 1061 | New Zealand
Switchboard: +64 96 34 00 88 | tomra.com<https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.tomra.com%2F&data=02%7C01%7Cgavin.lambert%40tomra.com%7C0503defff1934efb65e008d7b3fa4740%7C4308d118edd143008a37cfeba8ad5898%7C0%7C1%7C637175759824113951&sdata=rYo0ocJJDELVOOIDAal50dLEBb4j1kCg%2BDeK3megff0%3D&reserved=0>
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: Graeme Foot <Graeme.Foot at touchcut.com<mailto:Graeme.Foot at touchcut.com>>
Sent: Tuesday, 18 February 2020 08:31
To: Joachim Sällvin <joachim.sallvin at corpowerocean.com<mailto:joachim.sallvin at corpowerocean.com>>; Gavin Lambert <gavin.lambert at tomra.com<mailto:gavin.lambert at tomra.com>>; etherlab-users at etherlab.org<mailto:etherlab-users at etherlab.org>
Subject: RE: Slave lost forever after power cycling
Hi,
Is it this module here (or similar)?
https://www.nord.com/cms/media/documents/datasheets/TI_275281117_SK_TU4-ECT_EN_4217_screen.pdf<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.nord.com%2Fcms%2Fmedia%2Fdocuments%2Fdatasheets%2FTI_275281117_SK_TU4-ECT_EN_4217_screen.pdf&data=02%7C01%7Cgavin.lambert%40tomra.com%7C0503defff1934efb65e008d7b3fa4740%7C4308d118edd143008a37cfeba8ad5898%7C0%7C1%7C637175759824113951&sdata=RG%2F6OP61g%2Br6q4PftLWKpWXWhlOw8EzrUJMl9kNpOP0%3D&reserved=0>
The back of this unit has dip switches:
Second Address (DIP 2..10)
The "Second Address" can be set via this switch and controlled in parameter P181.
If all DIP switches 2..10 are moved to the "OFF" position, the "Second Address" can be set via parameter P160.
This means that if you set an alias on this slave via the "ethercat alias" command it will only remain active until the unit is repowered. If the dip switches are set it will apply an alias based on the dip switches. If the dip switches are all off it will use the P160 parameter.
Use the dip switches or P160 to set your alias for this unit, not the "ethercat alias" command.
Regards,
Graeme Foot.
From: etherlab-users <etherlab-users-bounces at etherlab.org<mailto:etherlab-users-bounces at etherlab.org>> On Behalf Of Joachim Sällvin
Sent: Tuesday, 18 February 2020 6:01 AM
To: Gavin Lambert <gavin.lambert at tomra.com<mailto:gavin.lambert at tomra.com>>; etherlab-users at etherlab.org<mailto:etherlab-users at etherlab.org>
Subject: Re: [etherlab-users] Slave lost forever after power cycling
Thank you very much for your reply.
It seems like the position on the slave network doesn't matter. What matters i the alias addressing of this particular slave. When I don't give the TU4 slave any alias address I can power-cycle it without loosing it. But as soon as I've given it an alias address and power-cycle it is lost (not every time but almost).
What might cause this? It seems like the EEPROM/Sii of the slave overwritten at start-up when it has been given an alias address. Is there a way to prevent this? How does this work "under the hood"?
I use "sudo ethercat -p1 alias 2" for example to give the slave on position 1 the alias address 2. Nothing wrong here I presume since it seems to work for other slaves.
I've been in contact with the vendor of the TU4 module and they claim that this module is working in big volumes (thousands) on the market. All their other customers use TwinCAT and they haven't heard of this problem. I have also tried three different TU4 modules to exclude the possibility of one failing individual.
Examples:
1.All slaves have alias addresses => TU4-ECT lost after power-cycling.
$ sudo ethercat slaves
0 1:0 PREOP + AXL F BK EC, Axioline EtherCAT Fieldbus coupler
1 2:0 PREOP + TU4-ECT
2 3:0 PREOP + ifm IO-Link Master AL1930
3 4:0 PREOP + ifm IO-Link Master AL1332
Power-cycling...
$ sudo ethercat slaves
0 1:0 PREOP + AXL F BK EC, Axioline EtherCAT Fieldbus coupler
1 2:0 PREOP + ifm IO-Link Master AL1930
2 3:0 PREOP + ifm IO-Link Master AL1930
3 4:0 PREOP + ifm IO-Link Master AL1332
2. No slave has an alias address => No problem after power-cycling.
$ sudo ethercat slaves
0 0:0 PREOP + AXL F BK EC, Axioline EtherCAT Fieldbus coupler
1 0:1 PREOP + ifm IO-Link Master AL1930
2 0:2 PREOP + ifm IO-Link Master AL1332
3 0:3 PREOP + TU4-ECT
Power-cycling...
$ sudo ethercat slaves
0 0:0 PREOP + AXL F BK EC, Axioline EtherCAT Fieldbus coupler
1 0:1 PREOP + ifm IO-Link Master AL1930
2 0:2 PREOP + ifm IO-Link Master AL1332
3 0:3 PREOP + TU4-ECT
3. All slaves but the TU4 has alias addresses => No problem
$ sudo ethercat slaves
0 1:0 PREOP + AXL F BK EC, Axioline EtherCAT Fieldbus coupler
1 2:0 PREOP + ifm IO-Link Master AL1930
2 3:0 PREOP + ifm IO-Link Master AL1332
3 3:1 PREOP + TU4-ECT
Power-cycling...
$ sudo ethercat slaves
0 1:0 PREOP + AXL F BK EC, Axioline EtherCAT Fieldbus coupler
1 2:0 PREOP + ifm IO-Link Master AL1930
2 3:0 PREOP + ifm IO-Link Master AL1332
3 3:1 PREOP + TU4-ECT
Best regards,
Joachim Sällvin
________________________________
Från: Gavin Lambert <gavin.lambert at tomra.com<mailto:gavin.lambert at tomra.com>>
Skickat: den 16 februari 2020 23:58
Till: Joachim Sällvin <joachim.sallvin at corpowerocean.com<mailto:joachim.sallvin at corpowerocean.com>>; etherlab-users at etherlab.org<mailto:etherlab-users at etherlab.org> <etherlab-users at etherlab.org<mailto:etherlab-users at etherlab.org>>
Ämne: RE: Slave lost forever after power cycling
Have you tried putting it in different positions on the slave network? Perhaps it only vanishes when downstream of a particular slave; then the problem might be with that slave’s configuration.
Etherlab typically assumes that all slaves are configured with DL auto-open mode (so that slaves that are connected or rebooted are automatically brought into the virtual ring network), but it’s possible that one of your upstream slaves has been configured in the explicit open mode instead.
Gavin Lambert
Senior Software Developer
[cid:image001.png at 01D5E653.8E63B1F0]
[TOMRA]<https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.compacsort.com%2F&data=02%7C01%7Cgavin.lambert%40tomra.com%7C0503defff1934efb65e008d7b3fa4740%7C4308d118edd143008a37cfeba8ad5898%7C0%7C1%7C637175759824123946&sdata=w0d6q81K6%2BQ2TepwEqNmfAjx%2FHWnq4o0CxgtYznyCnk%3D&reserved=0>[Facebook]<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.facebook.com%2FCompacsort&data=02%7C01%7Cgavin.lambert%40tomra.com%7C0503defff1934efb65e008d7b3fa4740%7C4308d118edd143008a37cfeba8ad5898%7C0%7C1%7C637175759824123946&sdata=%2F%2FpNd085%2Fr%2FAwB7WFrMjcsBeqaNppNt9zyxsyKOnf5c%3D&reserved=0>[Linkedin]<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linkedin.com%2Fcompany%2Fcompac-sorting-equipment%2F&data=02%7C01%7Cgavin.lambert%40tomra.com%7C0503defff1934efb65e008d7b3fa4740%7C4308d118edd143008a37cfeba8ad5898%7C0%7C1%7C637175759824133940&sdata=BtRNQl0VlYiXMt%2B9LAydbbpuMye0UMBOP4DxW1VuIuk%3D&reserved=0>[Youtube]<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fvimeo.com%2Fcompacsort&data=02%7C01%7Cgavin.lambert%40tomra.com%7C0503defff1934efb65e008d7b3fa4740%7C4308d118edd143008a37cfeba8ad5898%7C0%7C1%7C637175759824133940&sdata=zBcNoTnS3Xl9KWh4J55CW93rijbKdKRC6ClzWRkxXFc%3D&reserved=0>[twitter]<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Fcompacsort&data=02%7C01%7Cgavin.lambert%40tomra.com%7C0503defff1934efb65e008d7b3fa4740%7C4308d118edd143008a37cfeba8ad5898%7C0%7C1%7C637175759824143937&sdata=I54aYqaAE5Ac%2BmouBoSqsKcB8Z0jji3v0DM%2BOWrzrJg%3D&reserved=0>[instagram]<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.instagram.com%2Fcompacsort%2F&data=02%7C01%7Cgavin.lambert%40tomra.com%7C0503defff1934efb65e008d7b3fa4740%7C4308d118edd143008a37cfeba8ad5898%7C0%7C1%7C637175759824143937&sdata=pIVbEfPu0ZEWiHV2tW2vSqCJore8Ygg90nZChn4pu4A%3D&reserved=0>
COMPAC SORTING EQUIPMENT LTD | 4 Henderson Pl | Onehunga | Auckland 1061 | New Zealand
Switchboard: +64 96 34 00 88 | tomra.com<https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.tomra.com%2F&data=02%7C01%7Cgavin.lambert%40tomra.com%7C0503defff1934efb65e008d7b3fa4740%7C4308d118edd143008a37cfeba8ad5898%7C0%7C1%7C637175759824153928&sdata=WMjBFFYzvUj%2FaNty%2B%2BlOqT8jz3jVmxgEwYesV%2F5Gixc%3D&reserved=0>
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: Joachim Sällvin
Sent: Friday, 14 February 2020 22:34
To: etherlab-users at etherlab.org<mailto:etherlab-users at etherlab.org>
Subject: [etherlab-users] Slave lost forever after power cycling
Hi all,
I loose contact with my TU4-ECT (freq inverter from Nord Drive) slave after power-cycling it when there are other slaves on the bus. This happens intermittently. Only a EEPROM reset (I use TwinCAT for this ) can make it accessible again. When it is the only slave on the bus it seems as I can power-cycle and always access again.
Has anyone experienced the same problem? What might cause this? Workarounds?
Example:
Before power-cycling the TU4-ECT (all slaves have been given alias addresses):
$ sudo ethercat slaves
0 1:0 PREOP + EK1100 EtherCAT-Koppler (2A E-Bus)
1 2:0 PREOP + EL2004 4K. Dig. Ausgang 24V, 0.5A
2 3:0 PREOP + ifm IO-Link Master AL1332
3 4:0 INIT E TU4-ECT
After power-cycling the TU4-ECT:
$ sudo ethercat slaves
0 1:0 PREOP + EK1100 EtherCAT-Koppler (2A E-Bus)
1 2:0 PREOP + EL2004 4K. Dig. Ausgang 24V, 0.5A
2 3:0 PREOP + ifm IO-Link Master AL1332
3 8:0 PREOP + ifm IO-Link Master AL1332
Lost!!!
I'm using Linux kernel 4.13.13-rt5, Ubuntu 18.04 and EtherCAT master 1.5.2.
Joachim Sällvin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20200218/dbf94974/attachment-0004.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 11438 bytes
Desc: image001.png
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20200218/dbf94974/attachment-0070.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 1629 bytes
Desc: image002.png
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20200218/dbf94974/attachment-0071.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 1750 bytes
Desc: image003.png
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20200218/dbf94974/attachment-0072.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 1855 bytes
Desc: image004.png
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20200218/dbf94974/attachment-0073.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.png
Type: image/png
Size: 1970 bytes
Desc: image005.png
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20200218/dbf94974/attachment-0074.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image006.png
Type: image/png
Size: 20278 bytes
Desc: image006.png
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20200218/dbf94974/attachment-0075.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image007.png
Type: image/png
Size: 1506 bytes
Desc: image007.png
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20200218/dbf94974/attachment-0076.png>
-------------- 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/20200218/dbf94974/attachment-0077.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/20200218/dbf94974/attachment-0078.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/20200218/dbf94974/attachment-0079.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/20200218/dbf94974/attachment-0080.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/20200218/dbf94974/attachment-0081.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/20200218/dbf94974/attachment-0082.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/20200218/dbf94974/attachment-0083.png>
More information about the Etherlab-users
mailing list