Why no code in OB82, OB83,OB85,OB86 in our program

We have S7 414-H PLC. In the software I found Organization block OB82. But in the network nothing code there.. Comment is there I/O fault 1. And in 'Temp' some variable only declared. As I am new in S7 so I want to know why no code is there in network. Same also I found in OB83(I/O fault2 in comment but in network nothing code) and other two block OB85( OB not loaded fault)., OB86(Loss of rack fault).



Could any one explain why no code in the network.

arocon

Code absent because programmer can add his code but it isn't necessary. That OBs already perform CPU reaction to corresponding fault preventing CPU from going to STOP mode.

Hello arocon;

Gambrinus is right, OBs allow a programmer to program code but do not require it.
An OB is not called by the user, like a FB or FC block. It is called by the CPU, to react to an event detected by the CPU; each OB reacts to a different event. If you use a Time_of_day interrupt OB (for example OB10), your code will be executed at the time that you have set for OB10 to be active (in the CPU properties, in HWConfig). The CPU will ensure that the OB is called, not you; when it is called whatever code you have programmed will be executed.
Now, OBs in the range of 8x or 12x are error OBs; they are called by the CPU when it detects certain error conditions; if there is any user code programmed in them, it is executed as soon as the OB is called; if there is no code, there is nothing the user needs to be done; but that does not mean that the OBs are not useful. They capture the date and time of the event, and provide information for the PLC internal diagnostics (available to the user in the Diagnostics buffer). One important thing: normally the CPU will stop when it detects an important error in its process (wrong memory access, or missing I/Os, communication error, programming error...); when the correct OB is loaded in memory, even with no code programmed, it allows the CPU to continue operating even with a fault still present (the SF LED will shine red, but the PLC will continue working). So you can diagnose and repair the error (if possible) while the CPU is running.

You will find a lot of information on OBs in the System and standard Functions manual; it is installed in the Simatic/Documentation folder on your PC, along with Step 7.
Hope this helps,
Daniel Chartier

I have been studying now S7. My concept was OB1 was called by operating system and all other blocks are called by OB1. From reply i got that not only OB1, but other OBs also called by operating system. But when they are called by operating system? and at that time OB1 is working or not? If anyone clear it, it will be great help.

arocon

These blocks are only called when the event happens. They only scan when you have a rack fault, etc.

You have to have the blocks or the CPU will go into stop mode. By downloading the empty block the CPU will remain in Run mode and you can do some logic in the OB's to show rack faults etc.

There are many OB's, some timed and some triggered by events.

Hello arocon;

at that time OB1 is working or not?

Click to expand...

The OBs other than OB1 are interrut OBs, which means they have the right to stop execution of OB1 when they are called by the operating system. As soon as the code inside the OB is executed it returns the CPu to the point where it was before the call. In old 80x86 parlance, they act as interrupt vectors (look it up). Actually, this is how the CPU continues working when it reaches a fault covered by OBx: instead of going to stop, it give control over to OBx code, then recaptures control of its program after the fault; diagnostics are available, LEDs are lit, but the CPU doen't stop.
Hope this helps,
Daniel Chartier

I've seen many S7 systems where the interrupt and fault OBs are present but all empty. Even worse, if you check, you can often find they are being triggered almost constantly, producing a high OB1 scan time.

It seems quite clear in these cases that the designer/programmer added the blocks to prevent the CPU going to stop, but made no further attempt to identify the problem causing them to be triggered, or to add any code to successfully handle the faults as they arose. I am always very suspicious of empty fault OBs. If they have no code, they're performing no purpose other than to accept the interrupt trigger and then pass control back to OB1. Surely some attempt should have been made to cure the fault rather than just hide it? And if this type of thinking has been adopted, what other examples of bad practice are there elsewhere in the program?

Ken

Quite often the OB's would be blank during developement and/or commissioning, but these should either be removed or have logic to analyse and if required stop the PLC.

I agree they should not be empty on completion.