I’m encountering a network start error with some rather unusual behaviour, and I’d appreciate your help in understanding what might be causing it:
We have a few drives from Chieftek Precision Co. (CPC) where we are able to discover and start the network normally if only 1 of the CPC drives is connected on the network.
However, once 2 or more of the same CPC drive is connected on the network, network discovery fails with network start error "RSINetworkStartErrorDISCOVERED_ZERO_NODES "
Initially, we suspected it to be a mismatch of the EtherCAT IDs on the devices:
But the drive does not have any physical DIP switch to change the EtherCAT ID nor does it have the configuration to change the EtherCAT ID in its own software
Interestingly, when testing this behaviour on another PC (laptop), 2 or more of the same CPC drives are able to be discovered normally without errors
Therefore, our next suspicion was on the NICs as both PCs are using different NICs (all are in the supported NIC list by Tenasys).
The PC that fails to discover during 2 or more CPC drives are using the following NICs:
We’ve also tried including and updating the drivers in Program Files (x86) → INtime → network7 but to no avail.
Both NICs were tested and returned the same behaviour where 2 or more CPC drives result in “ZERO_NODE_DISCOVERED” error but able to discover and start when only 1 CPC drive is connected on the network
The PC (laptop) that is able to discover when 2 or more CPC drives are connected is using the following:
10ec/8168/..../.... Realtek PCIe GbE Family Controller
May I know what might be the root cause of this unusual behaviour?
Your help and clarification are much appreciated!
Thanks for the detailed write-up on your troubleshooting steps, that helps us narrow the problem down greatly.
The laptop discovering the drives successfully definitely suggests that the NICs are a probable suspect, specifically in relation to the way RMP opens EtherCAT NICs on Windows/INtime.
Likely Cause
EtherCAT devices expect the master to auto-negotiate the Ethernet link. As of RMP 11.0.5 and earlier, RMP’s EtherCAT Master opened Windows/INtime NICs with a forced 100 Mbps/full-duplex link. Most EtherCAT devices tolerate this, but some specific combinations of drives and NICs (specifically Intel ie1g NICs) fail to tolerate it and yield DISCOVERED_ZERO_NODES. We suspect this is occurring on your system.
On RMP 11.1.0, we changed the default Windows/INtime behavior to auto-negotiation. This makes discovery more robust in general, but we have encountered at least one Realtek NIC that fails with auto-negotiation. We’ve included an option to revert to the legacy forced-link behavior on 11.1.0 for machines this affects (details below).
What We Suggest
On your Intel PC
Install RMP 11.1.0 and try discovery with your 2 drives.
If it succeeds, please let us know that the upgrade resolved your problem.
If it still fails on 11.1.0, please send us:
The RMPNetwork log from the failed start.
The exact CPC drive model and firmware version, plus the ESI file if you have it.
Which NIC you used and how the drives are cabled.
On your Realtek laptop
Install RMP 11.1.0 and try discovery with your 2 drives.
If discovery now fails on this machine, add the following attribute to the <Settings> block of your CustomeNodeInfo.xml file to restore the 11.0.5 link behavior:
<UseIntimeHpeLegacyForcedLink />
We are currently working on a way for RMP to handle this case automatically, so this step may not be necessary in the future.