Hi,
I’m currently testing redundancy on a pair of X20CP3686X PLCs.
At the moment, I’m connected to the redundant pair using the cluster IP and I’m forcing/simulating values from Automation Studio using the Watch window.
During testing, I observed that the application was running on the secondary controller (for example, the staging was at Stage 8). After performing a controller switchover to the primary, many of the values appeared to reset (or drop back to their initial values). The transition happened very quickly, so I’m not sure exactly which variables were reset, but the application definitely did not appear to continue from the same runtime state.
My understanding was that a redundancy switchover would allow the standby controller to continue from the current state. I’m therefore unsure whether:
- This is the expected behaviour when values are being simulated from the Watch window.
- Runtime variables need to be explicitly configured (e.g. Retain or some other redundancy setting) to survive a controller switchover.
- Or whether, in a real system with actual I/O, the values would be synchronized automatically and this behaviour is only seen during simulation.
Has anyone come across this before or can explain how runtime variables are expected to behave during a redundancy switchover?
Thanks in advance.
Aditya
What happens to variables during a switchover depends on many things such as:
In general both of the controllers are running the application at the same time, but only the active controller is writing data to the outputs on the I/O bus. Redundancy switchover
If you are writing values to one controller through AS watch (or OPC UA, or any other way) to simulate something, this is only written on the active controller, but might be replicated to the inactive PLC depending on whether the variable is defined as replicable or not.
Thanks Tommi,
I checked the Replicable column in the declaration editor. In my project almost all variables are already marked Replicable, including the local variables in our main control task which matches the note in Automation Help that new function blocks and variables are redundancy-relevant by default.
However, the original symptom still happens: a local INT step counter in our 100 ms control task returns to its init value after a switchover, and the plant drops from stage 8 back to stage 1.
One detail about how I was testing: I was injecting simulated process values by forcing them in the AS Watch window on the active CPU. There is no real I/O wired on the bench, so the raw input channels read 0 when not forced.
A few questions:
-
Given the local variables are already replicable, what else can cause a local variable to return to its init value after a switchover? For example, does the current switchover level / system state matter, or does the standby need to reach a certain sync state first?
-
Does forcing values through AS Watch on the active CPU affect this? i.e. are forced values excluded from replication, so after switchover the (now active) standby computes from the un-forced inputs, which on the bench are 0?
-
Is there a recommended way to confirm the standby is fully synchronized before triggering a switchover, so I can rule out an incomplete-sync situation during this test?
Thank you.
-
The switchover level matters here so in an optimal situation the system should be ready for a “Bumpless switchover”.
-
I can’t give you a definitive answer right now as I don’t have a redundancy system ready for testing. I could not find a clear answer from the documentation either. Might be possible.
You could try to check this by connecting to both PLCs at the same via their own independent IP addresses / hostnames instead of the Cluster IP / hostname and monitoring the variables.
-
You can check this from the IOMapping of the redundancy interface, which provides quite detailed diagnostics. Other option could be the usage of the AsRed library function blocks.
Are you using Powerlink for the I/Os?
Yes, we are using POWERLINK for the I/Os — each CMS panel has an X20BC0083 bus controller, 8 remote stations in total, with the redundant CPUs (X20CP3686X pair) linked via the IF2181-2 fibre RIF.
I’ll look into the redundancy interface IOMapping diagnostics you mentioned. Could you point me to which channels are most useful there for confirming sync state during a switchover?
One clarification — when you say the switchover level matters. is there a configuration setting that determines whether the switchover is bumpless, or is that inherent to the AR 6.5.1 redundancy implementation with the fibre link? Thats my CPUs state.
The culprit turned out to be Niagara, not the PLC. I’m leaving this note here in case it helps someone in the future who comes across this thread.
