what is typical scan time of a plc?
and what effects the scan time?

 

Dear Sakshi,

Do you have a fast application where speed really matters? If so, it is important to have a fairly accurate estimate of what the scan time will be within the plc. But how do you get this number when every manufacturer seems to 'hide' the specification in sugar-coated marketing jargon?

The answer is simple. Dig through the jargon and get to the root of the problem. Make sure when comparing plcs that they are being compared equally. Many manufacturers have the 'fastest' plc. But how can that be true?? (Reminds me of the phrase 'new and improved'. Seems to be way overused and doesn't tell us much -- but it 'sounds good')

Don't fall for the marketing stuff, do your own research and make sure to compare each plc on equal terms. It's alot easier said than done but we can do it!

OK, but now you're probably thinking 'how can I do this?'. Good question. The answer... research. Here are the details to get you headed in the right direction.

Remember that the TOTAL scan time is generally the time it takes to look at the inputs (to see which are on and which are off), execute the program (the ladder logic program you wrote), and update the outputs(turn on or off the appropriate ones based on your program). That's the general 3-step plan. For most of us, that's all we need to concern ourselves with. (For you experts out there, we should note that most of us will not need to worry about other issues like communication, housekeeping, etc)

The step where we look at which inputs are on/off is fixed. The step where we turn on/off the outputs is also fixed. So, the plc manufacturer should be able to provide us with this information. Most manufacturers don't publish these numbers in their brochures or even the plc user manual itself. But if you ask them directly, I'm sure they can all provide the number to you.

The more inputs/outputs that exist on the plc, the longer the i/o update time will be. It can generally be assumed to be under a milli-second for most micro-plcs and gradually increasing as you progress to the midsize and larger plcs. There is no rule but ask your 'manufacturer of choice' if you need the number for your proper estimations.

Example:
input update time = 300us
output update time = 100us
-->> So, total i/o update time is 300 + 100 = 400us

What else do we need to complete the 'time equation'? That's correct, we need to know the program execution time. This is typically much easier to find than the i/o update time. Unfortunately, it also calls for manual labor. (Get out the pencil and paper... I'll wait for you)

To calculate the program execution time we simply make a list of all the instructions we used and note how long it takes the plc to execute each one. (The time to execute each particular instruction is most likely published in the plc users manual) Then add up all the individual execution times to get a total program execution time.

Example:
LD -- 1us
TMR -- 3us
LD -- 1us
OUT -- 2us

1 + 3 + 1 + 2 = 4 + 3 = 7us
-->> So, total program execution time is 7us.

Obviously, this simple program is just an example to illustrate a point. Simply add up the time it takes to execute each instruction in your ladder diagram and you will arrive at the program execution time.

7us here is quite fast because the program is quite unrealistic. This simple program just starts a timer when a given input turns on. In reality, our program should be doing much more than what we are showing here. If it is not, then we are just wasting valuable plc power. This sample is more a job for a simple timer than a plc! So, as you can hopefully see, a longer program is going to come with the price tag of a slower program because each instruction takes time to execute.

In the end to arrive at the final estimation we want to add up the total of our values. That is, we want to add our i/o update time to our program execution time.
So,
400us + 7us = 407us

Therefore, we can estimate that the plc scan time in this example will be about 407us.

Remember that 1us(1 microsecond) is 1 millionth of a second. So, 407us is 407 millionths of a second or almost one half of a millisecond. (quite fast indeed)

Now that you know the estimated scan time you can determine if the plc is going to be fast enough for your particular application. If the plc is not fast enough, then consider using interrupts within your program as they will not be too deeply effected by the scan. They will however, be effected by the i/o update time. Some plcs allow you to adjust that time, but many don't.

In general, when I'm planning my application and speed is something I may need to worry about, I'll take the number we calculated above and double it for a safety factor. Some of you may think that doubling the calculated value is a little extreme, but keep in mind that in most instances, the physical input doesn't come on at the exact point that the plc is looking at its inputs(for example). Therefore, in the worst case it must wait another complete scan before the input is seen by the plc. Hence, it has taken almost two scans to see the input. So, that's why I like to estimate by using double the value that we calculated above.

Hope that helps in your understanding what "speed" really means!!

In case of any query, please feel free to contact.

Regards
Sushant Chanana
[email protected]
sprayengineering.com

 

The typical scan time for a PLC is anywhere from a few milliseconds to several tens of milliseconds. Many PLCs have some means of letting you measure the actual scan rate. The actual scan rate may vary considerably from scan to scan.

The actual scan time is affected by the processing speed of the PLC, the amount of system overhead (I/O scanning, communications, etc.) in that type of PLC, the size of the program, the type of instructions used in the program (Some types of instructions take longer to execute than others), and the types of instructions executed in that particular scan. The way you write the program can effect the actual scan rate.

 

Typical is 1 mSec.- 50 mSec.

The processor effects the scan time. But many things affect the scan time, mostly the number and complexity of the instructions and in many cases the number and type of IO points. On some PLCs the scan time can be adjusted up from that value. If you have a mind for tedium, it is somewhat predictable and can be calculated by adding the times for all the instructions plus the IO time.

Regards
cww

 

Hello Sakshi,

The Scan time is the time required for PLC to read all inputs, excute plc program and update output.

what effects the scan time?
- the speed of plc processor.
- the number of input signals.
- the number of output signals
- the length of plc program
best regards
Eng.Hassan

 

>it is somewhat predictable and can be calculated by adding the times for all the instructions plus the IO time. <

Adding up the time for the instructions isn't that easy. The problem is that not all instructions are executed every cycle. For a lot of output instructions, the time to execute an instruction takes a lot longer than to not execute it. So, the time taken to execute a rung will depend on what the result of the rung logic was. Also, entire subroutines can get skipped if they are called conditionally.

In addition to the above problem, a lot of PLC manufacturers like to talk about how fast their boolean logic is. However, there is an observation from the computer industry called "Amdahl's law". This basically states that the faster you make any one thing, the less important it is to the overall speed of the system.

For a lot of PLCs, the boolean logic is much, much, faster than word, timer/counter, and program control operations. The result is that the overall cycle time is dominated by the execution time of those slower instructions, rather than the very fast boolean logic.

To put some numbers to this, here is an example from the Siemens S7-22x manual:

A, O (AND, OR)
- 0.37 usec for I addresses.
- 1.1 usec for M, C, T, etc. addresses.

/R (Real divide)
- 300 to 360 usec.

So, we can see that a single divide operation can take as much time as 300 to 1000 boolean operations. You might use more ANDs and ORs than other instructions, but in real world programs the slower instructions will dominate the scan time.

I have done some research into this area to help in development of a soft logic system. I took some real world PLC programs and did an analysis of execution time for each type of instruction. What I found was that if you added up the execution times for each type of instruction, by far the largest contributor to scan time was instructions for copying words to memory locations. Total boolean logic execution time was actually quite small.

However, that is just a static analysis. It didn't take into account whether each instruction was actually executed or not. To do *that* properly would require setting up an emulator that would log each instruction as it is executed, and also to simulate the operation of the machine itself so that we could trace the program as it actually runs.

I could throw a few more complications into the mix. One is that if the PLC applies certain optimisation techniques, then the time required to execute a complete rung of logic could be less than the sum of the times for the individual boolean instructions. I don't know if any PLCs actually do this, but it is something that I have been considering adding to the soft logic system that I wrote.

Here's another complication if you are comparing two different PLCs. Some designs of PLCs take many more instructions to do the same job as other PLCs. Consider for example adding two words together and saving the result. Some PLCs would require you to load the first word to the accumulator, load the second word, add the numbers, and store the result. Some other PLCs will do all that with a single memory to memory instruction.

So, the scan rate for a real world PLC program will depend on a lot of factors. The best you can do is come up with a very rough estimate.

 

That's why I said it's somewhat predictable :^)

And it's tedious for sure. Actually it's something they would like you to think they have a handle on but it generally requires an impractical amount of analysis compared to testing.

Regards
cww

 

I don't think anyone mentioned the speed of the I/O modules. You can't neglect to consider that some input modules require several milliseconds to respond, therefore that additional time must be considered in the "worst case scenario". Sometimes you can eliminate that element of possible delay by just installing a high speed input module (when available). Same applies to output modules too.

 

thanx a lot guyz fr ur guidance!!

 

> thanx a lot guyz fr ur guidance!! <

Urgh. Is it too much to ask that people use proper writing skills when posting? Or am I just an old fogey that needs to get with the times?

-James Ingraham

 

James, be thankful for the thank you!

Phil

 

James and Phil, You are both so right. Sure hope he doesn't pen too many technical documents.

Cheers
Gerald

 

1) Define a 'MW' as a INT in your Symbollist or an INT in a datablock and call it "Scantime".

2) Open OB1.

3) Pull down the "top curtain" in OB1.

4) Open "TEMP" behind this "Curtain".

5) Mark "OB1_PREV_CYCLE" and select "Copy"

6) Insert a new Network in OB1.

7) Get the "MOVE"-Function and place it in this network.

8) Paste "OB1_PREV_CYCLE" on left side of "MOVE".

9) Put your pre-definded "Scantime" on right side of "MOVE", so Scantime become a global data.

10) Now the Scantime is shown in milliseconds , (Dec. and not HEX).

Scantime is in a 'normal' program from 15-100 msec with peak-values up to 200msec. or more, depending of lot of events:
The CPU, No. of AI/AO's, Heavy calculations, Interrupts and many other events, but OB1 shows them all!

Regards
Jan Steen Nielsen
Denmark

 

I would like to get the average value of 5s of a pressure parameter in simatic step7. Is there any SFB available in it?

Right now i am calculating the average by using WSR FC90, but in this also i can only define the length but cant get the 5s avearge.

The only way that i will trigger it for 10s than i can have an average of 5 samples. If any one have explore it earlier than comment?

 

is there any difference between Plc scan time & plc scan rate?or both are same terms?

Regards
Satish

 

Scan time is the time required to execute a scan. Scan rate is the number of scans executed per unit of time. They measure the same thing, but express the results in different ways.

 

They are inverse: A 10mSec scan time gives a 100 Hz scan rate.

Regards
cww