S7 Any solution for a better timer

Normally everybody use pulse memory bit generate all necessay pulse,tact(100ms,200ms,1s...).
Then in the FB we use (for example 100ms) to count delay for the output.

My problem - I have a system with more than 100 drive, big profinet network - arround 200+ deivce, and safety program also running in this PLC. Scan time of PLC is 45-55ms. I already choose the most faster PLC I could - CPU319F 0.004ms/1000 instructions.

Some place I need stop delay, but under this scan time every time part stop on different place. After optimize scan time lower than 50ms, then part mostly stop on rigt postion.

So I guess it's should more or less relate with scan time and pulse which I use. It seems not like following equation when scan time is above 50ms.

Part Stop distance 30mm = 0.6mm/s*(100ms*5(Setting from IDB)+Communication delay(could be ignor))

Real stop different can be 30-80mm, which means it may cause by miss counting 100ms by each 100ms.

Some idea from my colleague is changing time unit resolution 100->200ms when CUP SCAN time is more than 50ms. But is really a big modification that I have to change all the IDBs. And Privcy Blocked FB.

Anyone have better solution for such kind of stop delay?

hill831017 said:

Normally everybody use pulse memory bit generate all necessay pulse,tact(100ms,200ms,1s...).
Then in the FB we use (for example 100ms) to count delay for the output.

Click to expand...

No not everybody does like that, and it is not normal.
It is a crude method, which shows exactly the kind of inaccuracies that you have observed.
The most typical is to use IEC timers.

hill831017 said:

Some idea from my colleague is changing time unit resolution 100->200ms when CUP SCAN time is more than 50ms. But is really a big modification that I have to change all the IDBs. And Privcy Blocked FB.

Click to expand...

It is a bad situation, if the program is poorly written by someone else, and you dont have the source code to change it.
Can you contact the original supplier and ask them to change the program ?
If the machine is still within guarantee, it should be fixed at no cost by the original supplier.

A CPU scan time of 50 ms is also a bit long nowadays, especially for a 319F CPU. I suspect that there is something that extends the scan time unnecessarily.

Helo MP, unfortunately I'm the supplier. This system is too big, and we had superviser system need to comminicate with, by the huge data transmition we have to give up CP card and directly connect them to the CPU, which again cost a lot of CPU resource.
Do you have any example program for using IEC timers for generateing all necessary pulse and tact.

Thanks advance.

The problem with using a pulse for updating timer values, is that you get quantization errors, just like you have described. There is no easy fix, because this is a fundamental issue.

Seriously, you should change the program to using IEC timers instead of the "pulse counter timers". If you have made the program with FBs it will not be impossible to change the program and just update the IDBs (*).
That should get you a precision of the overall scan time (45-55 ms).
To improve further, you should try to look into if there are things in the program that burden the scan time unnecessarily. For example, if there are heavy calculations that do not need to update constantly.

Investigate if the supervisory system isnt polling too many tags too fast. Most tags shouldnt be updated more frequently than 500 ms. A few tags may be updated every 100-200 ms. That could save some of the performance lost on the communication task.

*: It is easy to update the IDBs. Just run a block consistency check, and it is done automatically.

In post #1 you wrote that the FBs were Privacy Blocked.
Are you the programmer of the FBs or not ?
If you are not the programmer, then contact him and demand that he fixes the issue.

JesperMP said:

In post #1 you wrote that the FBs were Privacy Blocked.
Are you the programmer of the FBs or not ?
If you are not the programmer, then contact him and demand that he fixes the issue.

Click to expand...

We have standard developer in Austria, I'm the site comissioner, I already send this thread to them, they will think about it. Thanks for your help and best regards.

I agree with Jesper. Multi Instance IEC time would solve all that. If you have to be crude I would put your timers in a faster interrupt OB and run them say at 10msec. Or go the other way and move the non-essential stuff to slower OB....maybe even brake that up into slices. Then your main OB runs faster and will help with overall issues.

Nick