Step 7 FB's and scan time

Hi all,

I'm just writing some code that uses quite a lot of nested FB's. The reason being that I want to make the code with a very simple interface so that the electrical staff can just drop it in the software, provide some information and then it just does it's stuff.

I've found that it is quite dramatically affecting scan time (adding about 70ms to the scan). I'm using an old 313C to test with and the software will be going in a 315 but I would still like to streamline as much as possible.

The software is using nested FB's so a 'kernal' FB calls lots of other FB's which in turn call other FB's in order to get the job done. It was quite a complicated project so I split it like that to make it easier for me to develop. I made all the 'called' FB's instances of their caller FB so that the electricians only have to call one FB with one Instance DB to make the whole system work.

My question is: Does nesting FB's like this add anything significant to the scan time (i.e. rather than just either having all the code in one or two really long FB's OR calling lots of FB's individually and providing each one with its own instance DB) ??

Thanks for any help you can give me

Cheers

;-)

Old 313C versus latest generation 315 makes a huge difference.

Writing reusable code can indeed cost a lot of cpu time.
Every time the CPU has to jump from an FB to another FB, it must save the previous local stack and load a new local stack.

Another thing that may skew the picture because of the old 313C is that the older CPUs were significantly less efficient when addressing DBs (compared against addressing I,Q and M addresses).

The penalty of writing "reusable code" by nested FBs can be as much as a factor 10 to my experience. This used to be an issue, but with the latest generation CPUs it is irrelevant in comparison with gain in maintainable code.

What nesting depth are we talking here - the maximum depth I can achieve is 7

JesperMP said:

Old 313C versus latest generation 315 makes a huge difference...

Click to expand...

Jesper, thank you for your excellent information. I loaded the software into our 315 (it's an old 315 - 2AF03) and the scan went from an average of 19ms to about 50ms. Although the specs say that it runs 1000 instructions in 0.3ms. I've asked my boss to authorise buying a new 315 which will do 1000 instructions in 0.05ms so that should be fine.

L D[AR2 said:

What nesting depth are we talking here - 10, 50, 100 ?

Click to expand...

Only nesting to a depth of about 4 or 5 but there lots of calls to the FB's and I've done them as multiple instances rather than each having their own Instance DB. This software needs to be able to be rolled out across other production lines so I wanted to make it as 'black box' as possible. I was just looking into whether it would be possible to streamline it a bit by juggling the code around.

Thanks for all your help.

;-)

The spec that says 0.3ms per 1000 instructions is more misleading than informing.

The latest CPU generation 6ES7315-2AH14-0AB0 will be ~5 times faster than 6ES7315-2AF03-0AB0. So you will land between 5-10 ms.

Yep Jesper. The new one is spec'd at 0.05ms per 1000 instructions so, as you say, its 6 times faster.

There are encoder pulses running through our original one which started getting interrupted (or missed I should say) when I loaded in the new software.

Hopefully a new 315 will sort out all the problems. I've just got to get the bean counters to spend the money now...

;-)

You have encoder pulse evaluation in software ?
For slowly changing encoder pulses it would be OK.
You also have to consider input latency (typically ~5ms).
I have done encoder evaluation via a counter module, and then timed interrupt (OB35) for checking the encoder frequently. In that way I dont have to worry about scan time or input latency.

It's not a 'true' encoder. Just a sprocket on a proxy. It's been running fine for years but it was only when I put in my software it started struggling a bit.

I think that over doubling the scan time was a bit much for it! ;-))

It'll be fine when we get the new PLC. I'm trying to persuade them to go down the route of profinet for the new rig and then we can start updating other parts of the profi network too.

;-)

"Encoder" processing should be in a timed interrupt using the PIB value to make it independant of scan time.

LD will look into incorporating something like this when the new PLC arrives. It will make it more robust for the future. ;-)