Greetings, I am currently utilizing the SEL-3555 RTAC platform and exploring the possibility of implementing fail-over for the EtherCAT master on this platform. While SEL Tech support engineers have advised against this, they have not provided a clear explanation as to why this is not recommended. They have pointed out that none of their customers have attempted to use the EtherCAT network POU in the same way I am trying to. Here is a breakdown of my setup: 1. I have two RTACs, referred to as RTAC A and RTAC B. 2. RTAC A is configured with an IPAlias block communicating with a corresponding IPAlias block on RTAC B. 3. The IPAlias block determines which RTAC will take control of the IPAlias interface (x.x.x.x). 4. I have an Axion RemoteIO chassis that utilizes EtherCAT as the protocol. 5. Each RTAC has an EtherCAT network with a software POU block that can be enabled or disabled. My goal is to use the output of the IPAlias block to control the activation/deactivation of the EtherCAT POU on the RTAC, ensuring that only the RTAC in charge has control over the Axion Remote IO running on the EtherCAT protocol. Despite attempting the setup, it has not been successful. I am now seeking documentation on the sequence of operations for EtherCAT. I have tried searching for this information online, but only come across articles discussing the benefits of EtherCAT without finding specific technical details. From my understanding, the EtherCAT network is initialized once during the download to the RTAC and does not have a mechanism to re-initialize if the Master disconnects. I am unable to find documentation outlining the actions in case of a Master disconnect or when the network service is stopped by the EtherCAT POU. I am reaching out to those with extensive experience in working with EtherCAT. Is it technically feasible to implement fail-over for a Master on the EtherCAT network? Does the EtherCAT network instance retain certain parameters of the Master, such as IP or MAC addresses, in a way that could cause issues if another Master were to take over the network? Any insights or guidance on this matter would be greatly appreciated. Thank you.
After some research, it appears that the EtherCAT protocol does offer the option for a passive/standby master, although this feature must be specifically implemented by the software developer. If SEL does not explicitly mention this capability, it is likely not supported. Therefore, attempting to achieve the same functionality through the POU may not be successful, as the network instance could end up without a master.
If you are looking to integrate CODESYS with SEL, there is a high probability that SEL already supports it. You can kindly request them to include the feature you are interested in, such as running two controllers on a single ethercat network. The demonstration typically lasts either 30 minutes or 2 hours, which could be useful for a proof of concept using CODESYS runtimes. You can find all the necessary ethercat specifications and documentation on websites such as CODESYS Group and ethercat.org, accessible for free after becoming a member. One of the advantages of using the ethercat protocol is the easy access to detailed specifications.
An Australian individual mentioned that SEL most likely utilizes CODESYS and suggested politely requesting them to implement a specific feature for dual controllers and one EtherCAT network. The EtherCAT specifications and related documentation can be accessed for free on websites like CODESYS Group and ethercat.org by becoming a member. The open access to EtherCAT specifications is a standout feature of this protocol. To inquire about implementing CODESYS as the logic engine, consider asking SEL for specific technical details using references from the provided link. This aligns perfectly with what you aim to achieve.
Hey there, It's an interesting case you got there! Your understanding is somewhat right - the EtherCAT network does indeed initialize once at the start, however, manual re-initializing can be a bit tricky particularly in failover situations. I believe the SEL engineers advise against it mainly because in an EtherCAT network, the slaves are typically "hard-assigned" to the master at the start of the process through their IP/MAC addresses and it's not designed around "hot-swapping" masters in the conventional manner. Creating a seamless failover would involve somehow transferring these assignments to a new master, which EtherCAT protocol isn't fundamentally designed to accommodate. That's not to say it's impossible, though. You would likely need to design an extensive handover process if you want this to work, though it could well prove to be somewhat complex. I'd recommend reaching out to EtherCAT Technology Group for more specific guidance. Best of luck!
It sounds like you're tackling a complex setup with your RTACs and EtherCAT configuration! From what I understand, implementing a fail-over for an EtherCAT master is indeed not straightforward since EtherCAT was designed for high-speed, real-time applications where a single master typically manages the network to maintain timing integrity. If another master were to take control, it might cause conflicts with the existing parameters like IP or MAC addresses, which could lead to network instability. Have you considered exploring the use of redundancy protocols specifically designed for EtherCAT, like the EtherCAT Safety Over EtherCAT (FSoE) or even discussing alternative architectures with SEL support? They might provide more clarity on their hesitations as well. Good luck, and I hope you get it figured out!
It sounds like you're navigating a pretty complex setup with the SEL-3555 RTAC and EtherCAT! While SES support may seem hesitant, it might be worth considering that EtherCAT's design does prioritize deterministic and real-time communication, which could complicate having dual masters or fail-over systems due to potential conflicts in control signals. Regarding your quest for documentation, the EtherCAT Technology Group’s website might have some technical papers or specifications that could shed light on handling master disconnects. In practice, many users go for a monitored redundancy system instead of a true fail-over to avoid these complications. If you haven’t already, it could also be beneficial to reach out to the EtherCAT community forums, where you might find others who’ve encountered similar challenges. Good luck!
✅ Work Order Management
✅ Asset Tracking
✅ Preventive Maintenance
✅ Inspection Report
We have received your information. We will share Schedule Demo details on your Mail Id.
Answer: - Answer: SEL Tech support engineers have advised against implementing fail-over for the EtherCAT master on the SEL-3555 RTAC platform, citing concerns and lack of customer attempts in this area.
Answer: - Answer: The setup involves two RTACs (RTAC A and RTAC B) with IPAlias blocks, an Axion RemoteIO chassis using EtherCAT, and EtherCAT network with software POU blocks that can be enabled or disabled based on IPAlias control.
Answer: - Answer: The attempt to control the activation/deactivation of the EtherCAT POU based on IPAlias control has not been successful, leading to a search for documentation on EtherCAT's sequence of operations.
Answer: - Answer: The user has been unable to find documentation detailing the actions in scenarios of Master disconnect or network service stoppage by the EtherCAT POU, which has prompted the search for technical details.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.