Control Network issues with AC800M controllers
I got two questions regarding CN issues:
1) If the controller configured as a redundant and the second controller wasn't connected (doesn't exist), then can it cause issues with CN2 port of primary one, like not transmitting any data?
2) I started getting "primary connection lost" messages for some AC800M controllers (PM864). Total load of these controllers are above 70%, auto-negotiation is enabled for AC800 CN ports on the network switches and speed is set to 100 Mbit/s FDX. Can this be fixed by disabling auto-negotiation and setting speed to 10 Mbit/s HDX?
Voted best answer
I'm no pro on AC 800M - for adequate assistance, please contact your regional ABB support center.
Only the PM891 can do 100 Mbit/s (full or half duplex) all other AC 800M controllers require 10 Mbit/s half duplex - so at no circumstance should you select anything else but 10 half or auto-negotiate for a PM864. It is recommended to set fixed 10 half duplex instead of running on auto-negotiate.
What error did you get on CN2? If CN1 is available, only RNRP traffic will be sent/received over CN2 (+occasional CNCP clock sync telegrams if used).
Primary connection lost (RNRP) mean that at least 3 consecutive RNRP telegrams have been lost by the receving/reporting node. But already at first lost telegram will RNRP attempt to reroute application traffic over CN2.
Total load shall be kept at less than 90% for PA controller (a HI shall have even less load).
Cyclic load should be kept at less than 70% (controller firmware will automatically cap [retard] program execution to stay at/below 70% cyclic load). So being a bit lower than 70% cyclic load is highly recommended. Look for "Task inc/dec" messages in the controller log. Such are OK once or twice in conjunction with application download, but shall otherwise not appear in the log.
For smooth execution, your application should be split over several tasks (but not too many, staying at a single digit number of tasks is recommended). Task Tuning is required in most occasions, use the Task Analysis and the Task window (when online) to read off Actual Offset and use this to enter a user defined Task Offset + 5-20 ms of additional time (as per available in the CPU budget) in between each task. The controller *need* to have some space left between tasks to be able to communicate. In AC 800M, communication has less priority than IEC61131 code execution. Too long(consecutive execution) of a task will impair an AC 800M's ability to communicate with other controllers and the OPC server.
After task tuning, check RNRP again. There shall be no losses reported. CN2 should be online and it's LED blink once per second (sending the RNRP routing message every second).
Remember that any change of CN1/CN2 setting require a controller reset. E.g. you can not activate CN2 by just downloading. Reset is required.
A primary controller will "ping" its secondary over Ethernet, if secondary does not respond a warning will be shown in controller hardware status.
Controller log may contain further evidence.
Wireshark (network analyzer) can be used to track RNRP traffic (just capture UDP port 2423) - expect a short telegram per second from all nodes. If you see an interruption, continiue with additional captures at other points in the network until you have found where the telegram go missing. Not always due to a controller problem (sending is most often successful).