S7-300 Rack failure OB (OB86)

Hello

Our system bug from time to time random and we cannot define the cause of faults. When we check the HW online the program is running normal.

The diagnostic buffer contains the following attached 02 saved text .

Could you please help me how to find reason correct and localization of error.

Hello nadi;

The first 2 messages from your diagnostic buffer (setup for up to 500 messages tota). indicate the need for diagnostic OBs 86 and 122.  Please do a search for OB 86 and in the diagnostic buffer logs, see if other remote  rack errors are present.  do the same for OB 122,  I/O access error , and list these entries, this will be useful later.

First thing is to determine if some ofthese messages messages are linked, that is, if the calls to OB 86 and OB 122 come from the same event. Let's look at events 1 and 2 first, as an example.

OB 86 is called when a Profibus station (or Profinet device) loses communication physically with the master. In your case , the faulty slave in message #1 is at Profibus address 4. Please look at the hardware configuration and open slave no. 4 to identifuy what it is and where it is located in your plant; you can open the local diagnostic buffer on this node, to see if there are events specific to that node that have been logged. 

You should look at the I/O addresses associated with that slave no 4 and check if you find address 1006 in the I column. OB 122 will be called if your program tries to reach PIW 1006 while the slave is at fault and connot exchange data with the Profibus master:

If address PIW 1006 and slave node 4 are linked, it means you have lost connection to that slave temporarily (you will get incomig OB 86 and outgoing OB 86 entries in your buffer..

If we look further in the diagnostic buffer log, you will find recurrent calls of OB 122, for addresses 1000 to 1008. Are these linked to the same slave no. 4? The buffer contains also OB 86 calls for slaves no. 6 and no. 20, these must be checked also.

Most issues with temporary loss of DP slaves come from physical connection problems, on the cable, the connectors or the termination switches; on older machines or equipment that is subject to vibrations these elements should be checked more frequently. Have a look at this quick overview to guide you:

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

Hope this helps,

Daniel Chartier

dchartier

Hello nadi;

The first 2 messages from your diagnostic buffer (setup for up to 500 messages tota). indicate the need for diagnostic OBs 86 and 122.  Please do a search for OB 86 and in the diagnostic buffer logs, see if other remote  rack errors are present.  do the same for OB 122,  I/O access error , and list these entries, this will be useful later.

First thing is to determine if some ofthese messages messages are linked, that is, if the calls to OB 86 and OB 122 come from the same event. Let's look at events 1 and 2 first, as an example.

OB 86 is called when a Profibus station (or Profinet device) loses communication physically with the master. In your case , the faulty slave in message #1 is at Profibus address 4. Please look at the hardware configuration and open slave no. 4 to identifuy what it is and where it is located in your plant; you can open the local diagnostic buffer on this node, to see if there are events specific to that node that have been logged. 

You should look at the I/O addresses associated with that slave no 4 and check if you find address 1006 in the I column. OB 122 will be called if your program tries to reach PIW 1006 while the slave is at fault and connot exchange data with the Profibus master:

"I/O access error, reading

P area, word access, Access address:   1006"

If address PIW 1006 and slave node 4 are linked, it means you have lost connection to that slave temporarily (you will get incomig OB 86 and outgoing OB 86 entries in your buffer..

If we look further in the diagnostic buffer log, you will find recurrent calls of OB 122, for addresses 1000 to 1008. Are these linked to the same slave no. 4? The buffer contains also OB 86 calls for slaves no. 6 and no. 20, these must be checked also.

Most issues with temporary loss of DP slaves come from physical connection problems, on the cable, the connectors or the termination switches; on older machines or equipment that is subject to vibrations these elements should be checked more frequently. Have a look at this quick overview to guide you:

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

Hope this helps,

Daniel Chartier

 also all slave are in same link. see attached image HW.

dchartier

Hello nadi;

The first 2 messages from your diagnostic buffer (setup for up to 500 messages tota). indicate the need for diagnostic OBs 86 and 122.  Please do a search for OB 86 and in the diagnostic buffer logs, see if other remote  rack errors are present.  do the same for OB 122,  I/O access error , and list these entries, this will be useful later.

First thing is to determine if some ofthese messages messages are linked, that is, if the calls to OB 86 and OB 122 come from the same event. Let's look at events 1 and 2 first, as an example.

OB 86 is called when a Profibus station (or Profinet device) loses communication physically with the master. In your case , the faulty slave in message #1 is at Profibus address 4. Please look at the hardware configuration and open slave no. 4 to identifuy what it is and where it is located in your plant; you can open the local diagnostic buffer on this node, to see if there are events specific to that node that have been logged. 

You should look at the I/O addresses associated with that slave no 4 and check if you find address 1006 in the I column. OB 122 will be called if your program tries to reach PIW 1006 while the slave is at fault and connot exchange data with the Profibus master:

"I/O access error, reading

P area, word access, Access address:   1006"

If address PIW 1006 and slave node 4 are linked, it means you have lost connection to that slave temporarily (you will get incomig OB 86 and outgoing OB 86 entries in your buffer..

If we look further in the diagnostic buffer log, you will find recurrent calls of OB 122, for addresses 1000 to 1008. Are these linked to the same slave no. 4? The buffer contains also OB 86 calls for slaves no. 6 and no. 20, these must be checked also.

Most issues with temporary loss of DP slaves come from physical connection problems, on the cable, the connectors or the termination switches; on older machines or equipment that is subject to vibrations these elements should be checked more frequently. Have a look at this quick overview to guide you:

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

Hope this helps,

Daniel Chartier

Hello nadir;

Just trying to organise the diagnostic buffer data from your first post (Diagnose_last_ecents_2).

All events are from 09/26/21. This is how the messages can be grouped.

1- Station 4 failed at 1:36:20.711 (event 1), returned at 1:36:20.797 (event 74).

     Between these 2 events, recurring I/O failures at addresses 1000-1006 (OB 122)

2- Station 11 failed at 1:30:44.792 (event 75). returned at 1:30:44.851 (event 148).

     Between these 2 events, recurring I/O failures at addresses1024-1030 OB 122)

3-  Station 17 failed at 1:30:29.046 (event 149), returned at 1:30:29.951 (Event 230)

     Between these 2 events, recurring I/O failures at addresses 1040-1046 OB 122).

4- Station 20 failed at 1:25:00.252 (event 231) , returned at 1:25: 00.452 (event 232)

     No I/O failures between these events.

5- Station 26 failed at 1:07:30.514 (event 233), returned at 1:07:30.755 (event 428)

     Between these 2 events, recurring I/O failures at addresses 272-280 (OB 122)

6- Station 26 failed at 12:29:25.435 (event 430), we reach event 500 before its reurn is marked.

   Until the end of the buffer, recurring I/O failures at addresses 10008-1014 (OB 122)

The first 4 groups of errors Stations 4, 11,17 and 20) happened  within a period of 10 seconds, then there was a dely of 18 seconds before you lost station 26, then station 6 is lost after almost 25 minutes...

The close timestamp of alarms on various slaves warrants the examination of the terminator settings in the network. On what nodes (the first and the last node on the bus, physically, check your network drawings) are termination resistors expected to be ON (all other terminators on the intermediate nodes must be OFF). You should check not only the status of the resistors especially on the end nodes, but also check whether the resistor switch is loose (could change status subject to vibration) and if the end nodes are always powered, since termination resistors are powered by the node.

Hope this helps,

Daniel Chartier

Hello Mr chartier, 

i dont think the problem is related resistance dip switch but i will check egain and will give you result.

please find attached our profibus  network. 

thanks for your support. 

It's continues casting machine *(Steel Meltshop factory) , we have 6 strands same architecture (in software & HW) but separate, work since 8 years. Last month we had problem only in strand N:4

the problem still continue and today we have module ok and Error LED (SF) in permanent status.

see attached last diagnostic.

 thakns for support.

Kheireddine