S7 - 300 Series CPU crashes on failed DP despite presence of OB85/86 etc.

I'm not around much at the moment as I'm spending quite a lot of time on site commissioning - with no Internet access (doesn't half take a long time to catch up if you miss 4 days!).

This week somebody switched off one of the DP-Slaves to make some mods - and the CPU promptly went into STOP! Actually, it's not the first time I've noticed this and I've even mentioned it before I believe, but so far I've not found a solution. The actual problem that causes the CPU to stop is a buffer overun, according to the diagnostic buffer - presumably because OB85 is being called too often (some of the entries in the Buffer state that OB85 is not available).

It probably won't actually be a serious problem in practice, but it strikes me as the sort of fault that just shouldn't happen.

Does anybody have any suggestions for a strategy to react to the first fault so as to keep the CPU alive? I tried calling my routine to disable the DP-Slave concerned using SFC12, but it doesn't appear to react quickly enough.

This sounds strange. What shows your diagnostic buffer exactly.

However, you could disable the interrupt temporary trough SFC39-42 until you disable the slave.

However, you could disable the interrupt temporary trough SFC39-42 until you disable the slave.

Click to expand...

Oops, hadn't thought of that! Will give it a try when I'm back in Rossendorf next week.

You can also suppress OB85 for I/O access errors in the h/w config for the CPU.

If the CPU is setup to report i/o failures, then it may fault on cycle time. Even if OB85 is programmed it is no guarantee that it will save the CPU from faulting. This because each i/o call will mean a jump to OB85, and thus the cycle time watchdog may easily be exceeded.
Selecting OB85 callup for "only ingoing and outgoing" errors doesnt help much, as all the errors typically come at the same time.

No, the problem is definitely not cycle time, the report in the diagnostic buffer is buffer overflow. Damir's suggestion of disabling the interrupts sounds like a possible solution though. I'll be back in Rossendorf on Wednesday and give it a try.

Right, but it could be something similar - that the frequent calls to OB85 conflict with timed interrupt calls.
So maybe a simple solution could be to completely disable OB85 calls. And then make your own alarm message for when a DP slave is missing.

Thinking about OB85, something puzzles me.
I mean, if your proces is so sensitive that it cannot accept i/o problems, then it is a good idea to stop completely (CPU goes to FAULT).
If on the other hand this is not the case, then the idea is to add OB85 to keep the CPU running. If OB85 cannot guarantee that, then what is the purpose ?
Rather than programming OB85, one should decide to set "No OB85 callup" or not.
Because we have FC125 and FB125 we can ourselves detect when a DP slave is missing and then take appropriate action in the program.

Wonders never cease! I've now managed to get Internet access on-site.

What I'm actually doing is using OB85 to set a flag to cause FC125 and SFC12 to run, but they are running at the start of OB1 and before it gets there the CPU crashes during the process image update. I've added code to turn off the interrupts in OB85 now and will try again later when I get a chance.

Just had an involuntary test and everything's still running - stopping the interrupts inside OB85 seems to be the solution.

Hi' RMA

I had a similar problem on a small project with only 2 DP nodes, suddenly when the machine was running i got an fault on my DP-net causing the plc to go into to stop mode.

This is how i solved that problem (With some help from a good friend)See atached file.

Hope this will help.

Regards
Brian.

I forgot i my last reply to tell you that the time set on the "Flasher" is how long you would allow the DP node to be turned off or faulty before you get the alarm.

The alarm will not cause the plc to go into stop mode but just set an alarm flag.

Regards
Brian.

Thanks BNA, that was interesting, unfortunately, it doesn't look as though it will help with my problem. Although all the alarm OBs are present, the multiple calls on OB85 during the process image update eventually cause an internal Buffer overflow in the CPU and this is the reported fault which causes the CPU to go into STOP.

I thought I'd solved the problem by shutting off the interrupts immediately when OB85 is called instead of just setting the Flag to cause everything to be checked in OB1, however, although it's improved the situation, about one time in ten the CPU still goes into STOP. I also found that the five Load and Transfer commands I initially had in OB85 to copy the Temp Variables to a DB for later analysis increased the failure rate to about one time in three.

This is what I've got in OB85 at present, apart from the fact that the five Load/Transfer pairs have been removed. If anybody's got any thoughts about why it's not working I'd be pleased to here them.



I'll be back on site tomorrow, so I'll try and remember to do a screen dump of the diagnostic buffer next time it happens.

Edit:

I think I may have just discovered the source of my problem staring at me in the Block title line - I think the above S/W belongs in OB82 or/and OB86 not here!

Just back from site. Having added the interrupt blocker to OB82 and OB86 things have improved significantly. In the course of about 50 Power Off/On cycles the CPU only went into STOP once. The question now of course is why did it do it even once - anybody got any ideas?

Sorry, things were at mild panic level and I didn't get a chance to screen-dump the diagnostic buffer. However, this time it wasn't the usual buffer overflow, but something to do with the internal priority class - can't remember the exact message, I'm afraid!

How about setting "OB85 - Callup at I/O access error" to "no OB85 callup" ?
You are probably allready doing your own check for accessible nodes with FC125. With that you can programmatically decide what to do if nodes are not present.
Actually it is better this way than using OB85 ! With FC125 you know when a node is missing, and a node is typically a chunk of i/o that pertains to a certain function. In that way it is relatively easy to decide programmatically what to do.
Whith OB85 you only know that some i/o somewhere is inaccessible. You then have to do something extra to get more useful information to decide what to do.
In other words, using ones own error handling function with FC125 is probably easier than enabling OB85. And then you can completely do away with other unwanted sideeffects - like the ones you are experiencing with conflicts with interrupts.

Basically what I'm trying to do is catch any faults which cause loss of access to one of the DP-Slaves - either a bus fault or a power fault, for example. I'm already using FC125 to identify the problem DP-Slave, it's triggered by the setting of a Merker Bit in the appropriate OB. Here's the code (from an early version):



My initial problem was that about half the time, presumably depending on the point in the cycle the interrupt occurred, the CPU would stop with a buffer overflow before OB1 got round to starting the next cycle. Switching off the interrupts with SFC39 in the OB itself seems to have solved that problem - with 3 or 4 electricians/engineers working on the system at present, modules are getting switched on and off on a regular basis! I'm just a bit curious as to what caused the single CPU STOP that did occur - it was definitely associated with one of the modules being switched off.

Reading through the Help files again left me more confused than I was before! However, I came to the conclusion that OB85 was probably actually the best OB to catch these sort of faults, so I don't really think I want to switch it off.

By the way, if you're interested, you can see what things looked like in the capacitor hall about three weeks ago here. If you click on the small picture of the hall at the bottom right, you'll get a bigger (but older) picture.

Back on site again and the system has helpfully decided to crash nice and early, so I was able to dump the diagnostic Buffer. Unfortunately it's in German, but I think it's probably easy enough to follow.

The entries from 19 - 100 for PAW 356 are caused by the Test screen being being active at this point and trying continuoisly to write 0 to the Set-point O/P and are not relevant to the main problem.

I provoked the problem by switching module 11 off, which because of daisy chaining of the Profibus Optical Fibre link also took down modules 12 and 13.

Anybody got any thoughts?