Identifying missing DP stations in Step7

Is there any easy way to identify missing DP stations at start-up without specifically trying to address each station and waiting to see if OB86 pops up?

What I'm specifically thinking of is that I assume at start up the CPU does a check to see if the actual configuration matches that planned in HW-Config - otherwise there wouldn't be much point in the option to allow start-up to continue in the event that the configuration does not match. So is the result of this configuration check stored somehwere where I can easily access it?

I don't really want to use OB86 for this, because I want to use it to identify modules which physically exist, being powered down and then being powered back up. Since I'm going to have a stack of modules which will not physically exist for the best part of the next year, if I have to do both jobs in OB86, it's going to make that program unnecessarily complicated.

I originally intended to create a DB with a bit for each module and set the Bit during commissioning, but since somebody else is going to be doing most of the commissioning, I'm having second thoughts about that approach. If I can find a relatively easy way to identify the existing / missing modules at start up, I would prefer to automate this.

All suggestions welcome!

Roy,

are you trying to make a system that automatically configures itself.
That is: The program checks which DP stations are accessible and then activates the corresponding program blocks.

If so, then I find that a bit risky. I mean, how can the program distinguish between a DP slave that has not been installed yet, and a DP slave that has been installed but has a fault ?

I would setup a screen on the HMI to allow the operator to "activate" the installed DP slaves (=really activating the corresponding program blocks).

You could also use the template for Protool that displays a screen with comprehensive status and diagnostics information.
I started THIS thread about this (where there is a link to the template), but never got around to actually trying it out (but I will, sometime, promise..).

Hi Jesper,

I'm sort of sitting in the middle really. It's going to be months before more than a few of the 21 modules are ready, So if I don't lock out the ones that don't exist so that they cannot be selected by accident (or by design if somebody is too lazy to work out how much energy is going to be available by marking more modules than exist and entering the voltage in ProTool), the program is going to spend more time handling OB86 than doing any useful work!

What I intended was a one-time run through at start-up, initiated in OB100 leaving OB86 just to handle those modules which genuinely fault, or for some reason get powered down and then back up again in between times.

I saw you in your old thread, so I've already been there and had a look - the FB125 looks as though it will do just what I require - the ProTool connection sounds like it could be useful too.

Off to do some downloading now, will come back to report later.

Cheers
Roy

IF you address some i/o that cannot be accessed, then OB85 will be triggered.
You can avoid that if the blocks that scan the i/o that is not installed are programmatically disabled.
Alternatively, you can set the property "OB85 - Call up at I/O access error" to "Only for incoming and outgoing errors" (under Cycle/Clock memory).
That will avoid that your program uses too much time to service OB85.

Oops, getting mixed up between OB85 and OB86! Well, actually not really, because it is OB86 that will notice if a module powers down or comes back on-line, but of course, the actual I/O fault will trigger OB85.
But as I said, that's exactly the reason I want to know before I start which modules are not present, so that the OBs only have "genuine" faults to deal with.

Alternatively, you can set the property "OB85 - Call up at I/O access error" to "Only for incoming and outgoing errors" (under Cycle/Clock memory).

Click to expand...

Thanks for that, saved me some time reading the help files!

One thought occurs to me, I've organised my program in such a way that I only access the HW I/O in the program if a module is selected (which is why I want to block the ability to select non-existant modules). I assume that the analog values and digital O/Ps are only read/written if they are accessed in the program - but what about the digital inputs - are they read every scan regardless? If so, is Step7 clever enough to stop scanning once it's seen a DP fault, or do I have to control this myself?

Actually this sounds as if it ought to be the start of a new thread - just how is the Process Image (or whatever it's called in English?) updated anyway and what's the difference between DP H/W and H/W on the Backplane?

I am unsure if OB85 will be triggered if there is an i/o fault and there is also a DP fault at the same time for the module in question. Maybe OB85 will be triggered only when there is an i/o fault without a DP fault.
How to find out: As usual, by experimenting.

.. just how is the Process Image (or whatever it's called in English?) updated anyway..

Click to expand...

In the classical way.
Digital and analog inputs are read before the main program scan.
Digital and analog outputs are written after the main program scan.
PIWs and PQWs are accessed immediately, but they are also not referred to as part of the "proces image".

.. and what's the difference between DP H/W and H/W on the Backplane?

Click to expand...

For the program, I think there is no difference.
OB86 will be triggered if there is a fault in the backplane rack, or on a DP slave. It is all "racks" to the main program.

In the classical way.
Digital and analog inputs are read before the main program scan.
Digital and analog outputs are written after the main program scan.
PIWs and PQWs are accessed immediately, but they are also not referred to as part of the "proces image".

Click to expand...

That wasn't quite what I meant, what I meant was does the CPU try to read all the inputs that have been declared in H/W-Config before every scan - I'm assuming (hoping?) that only O/Ps which have been accessed in the program will be written, but I stand to be corrected there.

Since initially only 5% - 10% of the I/O is going to exist (for a couple of months, anyway) the program is going to waste a heck of a lot time in OB85 if it tries to read the other 90% before every scan!

Edit removed and posted as new post.

I'm assuming (hoping?) that only O/Ps which have been accessed in the program will be written, but I stand to be corrected there

Click to expand...

First, OB85 will be triggered if the program encounters an instruction with an i/o address it cannot access.

Second, all outputs in the proces image is updated at every scan (*).
Try to manipulate an output, that isnt written to in the program, via a VAT, and it will update according to the VAT.
If you delete an output in the program, and the output was ON when the rung was deleted, then it will stay ON !

*: But there will be an electrical propagation delay limiting how fast the output can change.

Or maybe it's not as bad as I'm thinking, assuming the CPU reads in Double Words, as each module only has eight Bytes of Input data, then we're only talking about two transfers per Module plus another two if all the Outputs are also transferred - as long as I don't overload OB85 (at the moment it's empty ), that shouldn't be a major problem - getting paranoid again, looking for problems that don't exist!

As long as you set the property "OB85 - Call up at I/O access error" to "Only for incoming and outgoing errors", then the scan time will not be severely affected.

In the classical way.
Digital and analog inputs are read before the main program scan.
Digital and analog outputs are written after the main program scan.

Click to expand...

Actually, it happens this way:

1. Process image output table is written.
2. Process image input table is read.
3. OB1 is executed.

Siemens made that change several years ago, and I always assumed it had something to do with safety (could it have been possible that outputs could be stuck on for one scan after a restart?). Anyway, it's kind of transparent once the process starts, but thought I'd clarify it.

Roy, coincidently, I'm looking into something similar, but for different reasons. First I'll add a few points:

That wasn't quite what I meant, what I meant was does the CPU try to read all the inputs that have been declared in H/W-Config before every scan - I'm assuming (hoping?) that only O/Ps which have been accessed in the program will be written, but I stand to be corrected there.

Click to expand...

Yes, they will be accessed whether they are in the program or not. To keep the CPU from going into stop mode, you will have to program OB122. OB85 will also be called, but there are subtle differences between them.

As for my application, what I am trying to do is determine the part number of the module that is insertered in a rack. For instance, I would like to know whether its a SM350-1 or 350-2, and then run the appropriate code. I can detect the CPU part number with SFC51, but no luck with the modules yet. I am pretty sure it's possible though.

In your case, take a look at SFC12. I haven't got time to test it right now, but it looks like you could create a "master" hardware configuration, check which modules/stations exists, and then disable the DP slave if necessary and then it wouldn't be looked at again. I'm assuming that you are using profibus in your system, and I don't know if there is an SFC that works with individual modules somehow.

In your case, take a look at SFC12. I haven't got time to test it right now, but it looks like you could create a "master" hardware configuration, check which modules/stations exists, and then disable the DP slave if necessary and then it wouldn't be looked at again. I'm assuming that you are using profibus in your system, and I don't know if there is an SFC that works with individual modules somehow.

Click to expand...

I know you guys are good, but I didn't know you could see into the future! I just went over to the test hall to have a look at how OB85 behaves, as suggested by Jesper:

How to find out: As usual, by experimenting.

Click to expand...

I then discovered that the CPU was configured so that it was not calling OB85. So after writing a two-liner to set a Bit in a DB when OB85 ran, I enabled OB85 for coming and going events only.

I then stood and watched as the Processor went into STOP. A glance at the diagnostic module showed that OB85 had been called too many times and there had been a buffer overflow. Hoping that I wasn't about to have to create stripped down versions of the project to cope with the problem, I came back here looking for somebody's shoulder to cry on, only to discover that S7Guy had already solved my problem in advance!

Thanks a lot!

By the way, the funny thing is that my Bit in the DB was't set, but maybe that was just because things were happening to fast and the CPU never got round to updating the Db.

I'll have another look when I've figured out how to use SFC12.

Roy

I don't know if this will work, but couldn't you use SFC36 MSK_FLT_DIAGNSTC, this is for syncronous faults, if the CPU is calling OB122, you can use SFC36 in OB122 and using the ACCFLT_SET_MASK pin you can set the access error to be masked. Bit 3 of that DWORD is to mask I/O access error read and bit 4 is to mask I/O access error write. (DW#16#4 and DW#16#8??)

Just a thought, maybe someone else can confirm if this will work for you.

Paul

Hi Paul,

At first glance, I think S7Guy's SFC12 is probably the right answer from what I've read in the help file (although it's unusually big, so I haven't yet read it all). It's basically intended for machine builders who have a standard machine of which they only use a part in any particular configuration. What I'm hoping is that I can initially turn everything off and then turn on and test the modules one at a time to avoid the flood of faults I get at the moment.

I don't have S7 on my laptop at home any more (it got too full) so I'll have to have a look at SFC36 tomorrow.

Thanks for the suggestion though

Well the bad news is that the Help file for SFC12 explicitly states that it CANNOT be called during OB100 (or OB101 or OB102), so that screws that idea!

Paul,

Looking at SFC36, if I understand you correctly, I must call this at the start of OB122 - i.e. as the first command of a program inside OB122, this is not entirely clear from the description of SFC36. The example they give calls SFC36 directly in OB1, but I don't think I'm even getting to OB1, I think the CPU's going into STOP while it's still in the start-up phase - any way I can easily check this?

Since my Bit SET in OB85 didn't work, I don't think setting a Merker Bit at the Start of OB1 will tell me much either!

One other possibility occurs to me - since I can get the program up and running when I set HW-config so that OB85 is not called, is there any way I can modify this in the running program?

Then I could get the program up and running, use SFC12 to deactivate the the missing DPs and then when I've got a stable situation, reenable OB85 to handle any genuine faults which come up thereafter.