Hello team,
We have a customer who is considering building a machine with a tool changer. This tool changer would require us to disconnect and connect Ethercat nodes while the rest of the network is running.
These “hot connect” nodes is placed last in our line topology.
These “hot connect” nodes can be uniquely identifiable (hardware DIP switch adress).
At this stage we are just investigating, and would appreciate any input. Is it doable today, is it on the roadmap, or is it something we can’t expect to achieve?
Dynamic networks isn’t currently possible on the fly. You would need to restart your network each time the topology changed. That might not be required though. Could you just associate different IO with the function of each equipped tool head? Why would they need to be different nodes?
Hi Jesper,
I sent you an email earlier. I’ve moved this post to Suggestions. We have added your request to our roadmap and will investigate the HotConnect functionality. In the meantime, please email with answers to my questions.
Hi @stleee, yes, Hot Connect (and flexible topology more broadly) is still on our roadmap, and it’s something we’re actively working toward.
Rather than tackle full Hot Connect in one step, we’re approaching it in stages. The first milestone is sync group support: the ability to organize the network into groups so that a non-main group going offline can be tolerated without bringing down the whole network. From there, the next milestone is allowing those groups to come back online and rejoin the network through our APIs.
We don’t have specific dates or implementation details to share yet, but we wanted you to know it’s a real priority for us and not just a wishlist item.
One thing that would genuinely help us. Could you tell us a bit more about why you’re asking, and the specific use case you have in mind? Understanding how you’d actually use this, what’s in the optional groups, how the machine is laid out, and what behavior you’d expect when a group drops or returns, lets us make sure our internal goals line up with what you and others actually need. Real-world scenarios are the best input we can get while we’re shaping this.
Thanks for raising it, and please keep the feedback coming.
@stleee@Jesper — following up on the roadmap answer from May: both milestones
we described have shipped in RMP 11.1.0.
Sync groups. Nodes assigned to a non-zero sync group get their own cyclic
datagram and their own expected Working Counter, so the RMP evaluates that
group’s process-data health independently. A grouped node dropping out of OP —
cable pulled, powered off, commanded away — marks the group DEGRADED or ABSENT and flags its data invalid, without invalidating any other group’s data
or faulting the network. Group 0 is the default and keeps the old all-or-nothing
behavior. In EtherCAT terms each group becomes a Master Sync Unit in the
generated ENI.
Recovery.MotionController::NetworkSyncGroupRecover() drives a group’s
member nodes back to Operational in place — typically tens to a few hundred
milliseconds, with no network restart and no other axes going down. Compare that
to the full restart this used to require.
Assign a node with the SyncGroup member of its Config via NetworkNode::ConfigSet(); read actual membership from Status.SyncGroupId
and group state from MotionController::NetworkSyncGroupStatusGet().
This is the containment layer under Hot Connect rather than full Hot Connect
itself: it contains node-dropout faults, so it fits the tool-changer case where
the removable nodes sit in their own group at the end of the line.
Docs: Sync Groups. If you try it on a tool changer, we’d still like to hear how
the group boundary lines up with your actual tool head.