S7~OB35 Interupt Problems

STL??? · Jun 14, 2006

Hi,
Our plant has inherited a washing/degreasing plant controlled by a 316 DP with a VB HMI.

Basically one of the cranes intermittantly rocks side to side over a certain station which visually looks like a positioning problem,

I have a documented program (in german!) which i'm slowly getting translated.

Whilst trying to debug the problem i opened up the module information page and was presented with entries consistent with the fault.

From what i understand OB35 is called every 100mS and the code contained must complete before a fresh call, If this doesnt happen, you can use OB80 to prevent a CPU stop?

Could somebody confirm this?

Attached Hopefully is the Diag Buffer file and pictures?

STL??? · Jun 14, 2006

STL??? · Jun 14, 2006

Jobbe · Jun 14, 2006

It seems that your cycle time is too high. The maximum time is 150ms and you need at least 177 ms. This would result in a CPU stop if you didn't load OB80.

Try changing the maximum scan time in the hardware config.

Double click the CPU
select tab "cycle/clock memory"
increase the "scan cycle monioring time" to 200ms.
Compile and download the new settings

STL??? · Jun 14, 2006

Hi,
Yes i could alter the Max Scan time etc, The plant runs well within the standard scantime range until (what looks like to me) the code within OB35 screws up for some reason on this one station intermittantly.

At its previous home, Encoders,DP slaves,Cables etc have been changed to try and correct this issue, Even the machine builder has no answers as the original programmer left the company!

Now its my problem

regards

STL

i cant believe how high the scantime is anyway

STL??? · Jun 14, 2006

Just to add,

The CPU doesnt stop and OB35 reads in/Out Data from a DP slave(ET200s) with a SSI Module fitted

S7Guy · Jun 14, 2006

Has this machine always had this problem? Is it possible that the scan time used to be 70ms or 80ms or so, but some kind of other interrupts are extending it? If I look at your pic, I can see that the scan varied from 69ms to 177ms. Maybe there is something going on that causes some of the scans to be too long.

I find it hard to believe that the original programmer would put in a 100ms timed interrupt when the base scan time was well over 100ms.

STL??? · Jun 14, 2006

Hi S7Guy,

Has this machine always had this problem? Is it possible that the scan time used to be 70ms or 80ms or so, but some kind of other interrupts are extending it? If I look at your pic, I can see that the scan varied from 69ms to 177ms. Maybe there is something going on that causes some of the scans to be too long.

The Program i have is from the M/C Builder and matches the Online program.

CPU Properties: Cyclic Interrupt

OB35 has priority set to 12, Execution set to 10 if this is any help? also there is a comment warning of execution time greater than 20ms.

Yes this has always been a problem apparently and our sister company has no S7 software but had a modem link to the M/C builder for support.

There is tons of Indirect addressing in this program, So its highly possible that a Loop or something similar is causing the scan time issue.

Does anybody have any good methods of tracking down a scan time eater?

STL??? · Jun 14, 2006

OB's Used

35 cyclic Interrupt
80 Cycle Fault
81 Battery Fault
82 I/O Fault
85 OB not loaded
86 Rack Failure
87 Comms Fault
100 New start
121 Programming Error
122 I/O access Error

I think ill remove OB121 tomorrow and see if it stops

S7Guy · Jun 14, 2006

There are a lot of ways to isolate what is causing long scan times, but the first thing I would do is log a sample of 500 consecutive scans and see if there is a pattern. Just grab the last scan time and throw it in a FIFO, stop the FIFO after a while, and take a look at it. If it looks like most of the scans are less than 100ms, then you can start figuring out why certain scans are much longer. That would be a start.

STL??? · Jun 14, 2006

There are a lot of ways to isolate what is causing long scan times, but the first thing I would do is log a sample of 500 consecutive scans and see if there is a pattern. Just grab the last scan time and throw it in a FIFO, stop the FIFO after a while, and take a look at it. If it looks like most of the scans are less than 100ms, then you can start figuring out why certain scans are much longer. That would be a start.

Thanks S7guy,

Ill try it tommorrow

SimonGoldsworthy · Jun 15, 2006

From the setting you describe, it sounds like OB35 is set for a 10ms interrupt. What made you think it was 100ms ?
You can read the actual time in millisecs inside OB35. I do this to check it is 10ms in my applications and flag up a fault if it is not

e.g.

Code:

	 L	 #OB35_EXC_FREQ
	 L	 10
	 <>I 
	 =	 M	 3.2 //flag fault if not running at 10ms

Note that the timed interrupt processing could be extending your OB1 scan time. To monitor the execution time of OB35 you need to read the system time at the start and end of OB35 and then you can find the difference to give the execution time. Similarly you could log the times to a buffer to see how they vary or do a simple comparison to see if the time ever exceeds a threshold.

PeterW · Jun 15, 2006

Are you sure its OB35 or just guessing? sounds like you have a loop out of control somewhere.

Are able to allow it to crash to see the stacks??

shortest scan of 69mS for shortest scantime seems extremely long to me.

PeterW · Jun 15, 2006

I've seen scans increase where I/O was missing.

STL??? · Jun 15, 2006

From the setting you describe, it sounds like OB35 is set for a 10ms interrupt. What made you think it was 100ms ?

Hi Simon, Thanks for the tip with OB35, I assumed it was 100mS based on the help file information:

OB Number    Default Interval    Default Priority Class

 OB30                   5 s                      7

 OB31                   2 s                      8

 OB32                   1 s                      9

 OB33                   500 ms                   10

 OB34                   200 ms                   11

 OB35                   100 ms                   12

 OB36                   50 ms                    13

 OB37                   20 ms                    14

 OB38                   10 ms                    15

By default i think it is 100mS, But as S7guy quite rightly said this doesnt make sense. I looked in the CPU properties and saw it was set to 10.

Are you sure its OB35 or just guessing? sounds like you have a loop out of control somewhere.

Yes OB35 is exceeding its default time, I'm now waiting for the relevant blocks to be translated, To try and put this thing to bed!

Are able to allow it to crash to see the stacks??
shortest scan of 69mS for shortest scantime seems extremely long to me.

Unfortunately it needs to run until the weekend! Yes 69mS i feel is very high and up til this point, It is the most complex program i have come across!

Most of the intermediate processing is done via local memory(probably to reduce scantime) and tons of mapping using ANY pointers.

I think they should have used a more powerful CPU

Fun part is it is 100% STL

Regards

S7~OB35 Interupt Problems

STL???

Member

STL???

Member

STL???

Member

Jobbe

Member

STL???

Member

STL???

Member

S7Guy

Member

STL???

Member

STL???

Member

S7Guy

Member

STL???

Member

SimonGoldsworthy

Member

PeterW

Member

PeterW

Member

STL???

Member

Similar Topics