Output Channels goes from "1" to "0" repeatedly, 800xA 6.0
The failure observed in a controller during the upgrade from version 5.0 sp1 to version 6.0.1 in system 800xA.
In this upgrade a particular model PM861A controller presented an anomaly, this anomaly is that almost all the DO820 modules (approximately 95% of these modules) with active channels (only affected channels that were active), they changed state intermittently (Every 1 sec, the output went "off" for approx. 0.2 seconds and then returned to "on"), being that by logic these outputs had to remain active, because of that, the connected valves began to open and close in Intermittently.
This fault occurred approximately 5 hours after the upgrade of this controller and only affected this controller in specific, being observed in the modules DO820 installed in the ModuleBus. The failure disappeared when performing a hardware modification in the Control Builder (a card that was not being used was removed from the Builder control structure).
As antecedent of the controller is that the load, in version 5.0, was to 75% with the logical operation and the plant in operation. When updating, the load of the controller was increased to 85%, and after the logic worked, and making repeated modifications in the logic, due to the change in the input and output variables of the ValveUni modules, increased the load of the controller to 100%.
At first it was thought that the load of the controller and the times assigned to the different tasks could influence, so that the task times were adjusted so that they did not overlap and the processor was reloaded, but after approximately 5- 6 hours, the fault was repeated again.
The hardware associated with this driver consists of:
• One CI860 module.
• A CI854A (Single) module, to which a CI840 with 11 modules and other Profibus devices like UMC22 is connected.
• ModuleBus Electrical with 12 modules.
• 4 clusters connected to the Module optical module.
The flaw itself is difficult to replicate, but after 4 to 6 hours of operation of the controller in version 6.0, this happens again. The fault only affects this controller, since in the rest of the plant the updated equipment works without problems.
Another relevant fact is that this controller shares applications and tasks with a larger capacity PM864 controller, but the PM861 is the one with the highest logical load that hosts two applications and has the largest number of modules connected.
Finally, it was decided to return the processor to version 5.0 and analyze the problem before reloading the firmware version 6.0.
The Scan cycle time of the ModuleBus is set to 0, which means that the scan is managed by the controller. Our theory is that given the load of the controller this does not reach to execute the tasks in its program cycle and finally does not finish writing the outputs, which causes the outputs to go to their default state that is "off".
IIRC, as a rule of thumb: the ModuleBus Scan Factor should be set to 50% of the fastest task in need of data to/from modulebus IO.
For example: if the fastest modulebus dependent IO task is running at 500ms, select a ModuleBus Scan Factor of 250ms.
A zero setting will cause the controller to handle the modulebus as fast as possible with adverse effects on the total load. The default value is 100ms.
I cannot explain the flickering IO - I believe you should ask Supportline for help.