¿ A PU410 RTA problem can to collapse a MB300?
Hello, we have in our plant a MB300 control net, with 7 redundant controllers AC450, and four operation station connected to MB300 with PU510, also we have two Gcom and a PU410 RTA connected into MB300.
Yesterday our MB300 collapsed, the operation station signal control disappeared (every signal control was dark).
Our MB300 is made with Fiber optic and switch ethernet, not with coaxil cable.
I saw a log file where said "MAC addr LOST NODE 60", our node 60 was PU410, so i proceed to disconnect and the MB300 went back to work.
Do you know if these problem with a PU410 had happen in other place?
Likely not due to the PU410, rather something that subscribes via this PU410.
Try to extract system messages from this RTA and controllers before restarting. The messages often give a distinct reason to the problem - eg. overflow due to excessive subscription, etc.
The data subscription framework in MB300 was built in the eigthies, and for the HMI used back then (MasterView 800). Typically were 100-200 objects subscribed per HMI station, not more than 4-8 of them per MB300 control network.
Today with the MB300 OPC DA server in the system, it is (way too) easy to place bad subscriptions or excessive subscriptions which risk to flood the controller and saturate the MB300 protocol to a point where flow mechanisms block further transmissions until the already initiated ones have completed.
1) Read the performance section in the 800xA for Advant Master Configuration User's Guide
2) Download and read the 800xA for Advant Master Performance Guideline (Technical Description)
Now you will know that the max recommended RTA CPU load is 40-50% and that you should not subscribe on other rates than 1, 3 or 9 seconds and that a controller can pump the MB300 AI VALUE, STATUS and NO_OF_DEC properties efficiently while the remaining MB300 AI properties come at a much higher price. Write orders should only be issued to MB300 DAT objects and with low frequency/volume. Some OPC clients use "client driven pace mechanisms" such as asynch reads or synch device reads which will take a big bite on a controller's performance...
Google "abb aks opcdaconnector statistics" and try to use AfwApplogViewer to measure number of subscribers and items. The "advdsmasteradapter statistics" operation give even more detail.
Upload system messages and applog results and I will comment on them.
In addition to my first answer, if complete system message was "MAC Carrier Lost", the PU410 lost connection to the MB300 bus.
Check hardware and port statistics for PU410 connection to the MB300 control network.
Up to 5% (less is better) of all traffic can go lost in transmission on half duplex which MB300 is using without being a real concern for the system. Divide collisions with sent packets and CRC errors with received packets to get percentages.
Try to copy and store all messages emitted during an undesired event. System Messages from the RTA Board Config tool are especially valuable, but will go lost if not retrieved *during* the event.
A lot can be told from a System Event List covering the event. If possible revisit the [Workplace Structure]Web System Workplace:System Event List, it holds several thousands of messages, maybe the complete event - remember that you retrieve 500 more each time you press the <Up> arrow button.