Empty error OBs in S7 - should they be allowed?

Just thought I'd try a bit of pot-stirring here to see what floats to the surface.

Should the inclusion of empty error OBs in STEP7 programs be encouraged or advised?

Personally I'm against empty OBs. And yet I've seen examples when people begin developing S7 programs where the first thing they do is add a selection of error blocks to an as yet empty program. Usually if I challenge them about this the conversation goes something like -
"Why do you put all these blocks in there with no code in them?"
"It's so the PLC keeps running if there's a fault."
"Why do you want to keep it running if there's a fault?"
"So that I can keep working on the other bits of the program without having to fix things like hardware errors or I/O errors"
"How do you know if there are any hardware errors or I/O errors? By including these blocks with no code in them you're just hiding any faults."
"Oh, I'll check later by taking the blocks out."

Has anyone else observed this (or is a practitioner of this !?)

I just think it seems at odds with how I like to work - test early; test often; check for errors; remove them as you find them. I've no objection to the inclusion of the OBs - after all this is the CPU's way of telling us an error has arisen. I just don't see the point in deliberately making sure the message we're given is blank. A few lines of code in each block will keep the CPU running if necessary, and have the added advantage of identifying what and where the errors are.

Regards

Ken

I'll stir the pot the same way Ken, I agree with all you have said. Rgds, Simon.

I am with you on this Ken,

I tend to only include the error OB's that I require and only if they contain code to tell me what the problem is. Blank OB's for me is a No-No. Personal preference comes into this. I work for an end user, not an OEM, so as far as my boss is concerned any way I can keep the PLC running is fine with him.... but not with me.

Does some of this come from people using the 'new project wizard' where it gives you a selection of OB's to include in the program and they just tick the 'select all' button?

I will hold my hand up here and state that when I first started using S7 that was what I done, until I realised that I didn't really want to be doing that for the reasons you stated above.

Paul

Hi

Iam the one who simply copy-paste these OB's from project to project.Reason is I have no idea of how to program them.
I have not seen any any project with something written in them.
I wonder what to write in say OB86.
Needs to have clear understanding of these OB's,any sample project can make things clearer.

But have you ever had this response....?

Ken M said:

"Why do you put all these blocks in there with no code in them?"
"It's so the PLC keeps running if there's a fault."
"Why do you want to keep it running if there's a fault?"

Click to expand...

"So I can process the I/O, DP error etc. using SFC51 and display the alarm on my HMI"


I personally call SFC51 in this situation via a flag set in the OB but there's more than one way to skin a cat....


Kevin H

...via a flag set in the OB ...

Click to expand...

That sounds suspiciously like a piece of code in there

Ken M said:

That sounds suspiciously like a piece of code in there

Click to expand...

Ken,

I think you missed my main point which was that it is possible for empty OB's to exist for a valid reason, i.e to allow subsequent error processing and display.

Just because I use a different method - setting a flag in the OB etc - doesn't mean it's the only/best way to achieve the end result...

Kevin H

Hello guys;

Just my $0.02:

The diagnostics buffer is one of the most useful tools from Siemens at commissioning stage, and if you have no error OBs loaded in the CPU (even unprogrammed) then the diagnostic buffer is half-blind; often you will find the mention "missing OB: OBxx" with no further details.
But if the requested OB is loaded then the diagnostic buffer will point to the defective module or connection (even though the diagnostic message can be cryptic, it generally gives good indications for troubleshooting).
So until the program is debugged, I tend to use unprogrammed OBs; when I have a working program, then I add code to the diagnostic OBs, such as SFC51 or function calls to my error routines.
Hope this helps,
Daniel Chartier

Kevin

I'm puzzled - if the OB is empty, what do you use to trigger the SFC51 call elsewhere? I thought the only info in the OBs was in the TEMP area, so if you wait until execution has exited what's left?

Even if you only use an instruction in the OB to set a bit, any bit, that's still code isn't it? Or have I missed something?

Ken

So, kinda off track here, but I have a quick question.

How does inputting these blank OBs in the prgoram stop things from stopping?

When the processor faults, does it just call these OBs, and if the OB isn't there, it stops? So if you put the OB in, regardless of whether or not there is code, it goes to it, is able to find it, and doesn't stop?

Ken,

Yes...I personally put some code in the OB...

....BUT I was playing devils advocate and saying that the OB could validly (is that a word?) exist without any code, for example to allow the program to continue processing SFC51 to identify the error and display it on a HMI. SFC51 could be called cyclicly elsewhere.

Kevin

Daniel,

I had to read your post a couple of times just to make sure that I fully understood it.

At the beginning of the post it seems that you are disagreeing with Ken (and myself) regarding empty error OB's because, as you quite rightly state, the diagnostics buffer has nothing to go on. So from that you are advocating the use of empty OB's, correct? You go on to say that you do this during commisioning then....

when I have a working program, then I add code to the diagnostic OBs, such as SFC51 or function calls to my error routines.

Click to expand...

So, from this, you are then agreeing that OB's should not be left empty on a working program.

Without trying to cause an argument, what side of the fence do you sit on?

Paul

Tharon said:

When the processor faults, does it just call these OBs, and if the OB isn't there, it stops? So if you put the OB in, regardless of whether or not there is code, it goes to it, is able to find it, and doesn't stop?

Click to expand...

Correct

Paul

Hello Paul;

Without trying to cause an argument, what side of the fence do you sit on?

Click to expand...

No argument in sight, unless one takes this to be a matter of faith.
Personnally, I look at it more as a matter of convenience.
For example, programming SFC51 can be complex, you have to know which SSL-ID code to use in order to get the right information at the right time. Hard to know beforehand.
So basically, I use empty OBs at startup, until I know my program is working. As I go along, I can decide which OBs need to remain on the finished program, and what kind of data/actions I require from them. These I generally program for my use, of to send data to the HMI.
In some plants, at the request of maintenance guys, I left a few empty OBs, because the technicians could call me up (generally at 2 AM of course) with somthing else than the usual "the d..n thing stopped working again"; the diagnostic buffer could at least guide me (and sometimes them) a bit.
Hope this makes things clearer.
Daniel Chartier

PLucas said:

Without trying to cause an argument, what side of the fence do you sit on?Paul

Click to expand...

Hey, I thought this was pot-stirring...

Joking aside, OB121 is the most important OB not to have blank as it is this block that is called if you fall of the end of a db, call a block that does not exist etc.