Bus2f error

Hello mohamed;

First, about your last ppoint: you remove the erro LEDs on you CPUs by correcting the faults that cause the LEDs to light up. You cannot remove or mask them any other way.

- the BusXf LED appears when the operating system of the CPU detects an error on the network that links the CPU and the remote I/O stations (on Profibus or Profinet for example).A faulty node interface or module, connector of cable could be the source of the fault.

- the REDF LED lights up when the operating system detects a redundancy fault between the primary and stand-by CPUs in a redundant system. This could be a problem with the sychronization modules or F.O. cables between the CPUs.

To have better information on the source of your problems you should open the diagnostic buffer of the CPUs. This is a memory location where all diagnostic messages of the CPUs are maintaned and made available to the user. So open the diagnostic buffer on the primary CPU and start examining the messages there, study the messages that appear to relate to your LEDs in particular. 

If you need help understanding the diagnostic messages, there is a button on the diagnostic buffer screen that allows you to Save As a text file the complete list of messages currently in the buffer. You can attach this text file to your next post so we can study it and help you further.

The screenshots below are taken from the S7-400H fault-tolerant system manual, which you should consult whenever you have problems with your redundant CPUs:

https://support.industry.siemens.com/cs/ww/en/view/82478488

Hope this helps,

Daniel Chartier

 Hello mohamed;

mohamed s gaber

Event 1 of 10: Event ID 16# 2942
I/O access error, reading
P area, byte access, Access address: 390
Requested OB: I/O access error OB (OB122)
Priority class: 1
External error, Incoming event 

Here above is a sample from the diagnosis and its repeated but with different address

Also, do you have any explanation for disconnecting input powe to the im module with bus fault and reconnect it again the bus2f disappears ?

 I have no technical explanation for the return of comms on a IM module when power is reset. We refer to this phenomenon "Ifrits", or sometimes "Ghosts in the machine"; believe me, that happens more often than you can imagine. If you IM module is aged, it could be that the electronics are telling you they might be at the end of their useful life, and you might have to change it eventually.

I/O access error OB, OB 122, is called by the operating system when an invalid address is accessed by the user program of the CPU; it is OB 122 that writes the error message to the diagnostic buffer. And it will often happen at the same time you lose a Profibus node. For example, say you have an analog input module on node 11, using address  PIW 390, and you  use the scale function to convert the analog input to engineering values, when node 11 goes offline (for whatever reason) the program cannot read the value in PIW 390, and OB 122 is called.

I suggest you write down all the addresses linked to OB 122 in the diagnostic buffer, and locate these address numbers in your hardware config; then you will confirm which node number becomes faulty in your network. You should find corresponding messages calling OB 86 for that same node in the diagnostic buffer.

Hope this helps,

Daniel Chartier

Edit: Your diagnostic buffer settings allow only the collection of the last 10 messages, which is a very small sample to diagnose a complex system like a S7-400H. The standard size of a diagnostic buffer in a S7-400H should be at least 120 messages long (see the manual proposed earlier) and can be extended even more, if needed, for historical collection for example.

D.C.

Hello mohamed;

Very often (some estimates go up to 85% of all Profibus failures) the problem in a Profibus network lays in the infrastructure, cable, connector, termination... This very useful article from Profinet.com is very informative on this subject:

https://us.profinet.com/top-5-reasons-your-profibus-network-failed/

It also provides a link to the Profibus installation guidelines, from Profibus International. Follow the tips in the article to correct the problems in your installation and then study the guidelines for more familiarity.

I presume from your question that your SCADA is also part of the Profibus network. If it is a Siemens software, then it acts as a Master (class 2) on the network and should not affect the other slave nodes present. You must simply make sure that it is cabled and terminated properly in the network.

If it not a Siemens software, you must find out if it acts as master or slave on the network, and that the length/speed requirements over a segment is respected, and that each segment does not carry more than 31 nodes (plus a repeater, if necessary).

Hope this helps,

Daniel Chartier

Hello Mohamed;

In that case, I don't think an equipment on a totally different protocol and interface would affect a Profibus node. What are your thoughts on this possibility?

Instead of starting a new tangent in this thread, I would prefer you examine the help and documentation already given. Once all suggested tests are examined and proven insufficient you can start examining new theories.

Hope this helps,

Daniel Chartier