How to optimize for synchronization using changing network topology

[Ghost_coder]

I am using 1 cRIO-9047 connected to 5 cDAQ-9189s.  4 of the cDAQs are further away and connected to the local IE4000 in a ring topology.  They only need to acquire data, no deterministic feedback and control, but I am using 802.1AS as the Sync Clock type.  There are 1 or 2 daqmx tasks running per chassis.

When 1 leg of the ring is disconnected, the tasks running on 2 of the cDAQs stop, and the other cDAQs remain running.  The stopped tasks is somewhat expected because the packet route has to change and go through additional hops around the ring.

When the leg of the ring is reconnected, the tasks stop as well (which I would like to avoid)  Is there a way to program the IE4000 to not optimize the route, and just keep the existing route to prevent the issue when reconnecting?

Any other robustness and optimization tips?

[Ghost_coder]

Bump - Why does the data acquisition task stop when the redundant leg of the ring topology gets reconnected?

Does the network switch in the cDAQ-9189 have any configuration parameters?  How to troubleshoot?

[vacharya]

Looking at this whitepaper for Designing Distributed TSN Ethernet-Based Measurement Systems, there is a note that states

---

Keep in mind that if a link between two of the devices that support IEEE 802.1AS is broken, the synchronization data communication is disrupted.

---

So, if you are disconnecting the link between 2 cDAQ devices, they would temporarily lose sync which would result in the DAQ tasks being stopped.

If you want to break the link between a cDAQ device and the IE4000 switch, there might be a way to tweak the Rapid Spanning Tree Protocol (RSTP) settings on the IE4000 to not use that link segment.

I don't have much expertise in that area, but maybe the links in this post (Time Precision Protocol Switches) could help you.

Additionally, if you provide a bit more context on what the high-level goal that you want to achieve by disconnecting the leg is, we could provide more input.

Thanks,

Vineeth