PLC Scan Time Theory

[kachow12345]

Hi,

I'm new to PLCs and learning about PLC Scan times for Schneider PLCs

I've derived the PLC scan time using the free running blocks. The PLC Scan time of the simulation is 25ms

I've generated a 1 second pulse with a pulse counter using two TON blocks (500ms each TON) and a pulse trigger that is reset after each second.

I've run the program for 60 seconds and recorded the number of pulse counts.

I was expecting to see 60 counts (i.e 1 second pulse = 1 count, so for 60 seconds you get 60 pulses), however, I've recorded 57 counts.

Can someone please explain to me the theory behind what is happening and why my TON 1 second pulse counter is delayed by 3 seconds (3 pulses).

 

[parky]

There are a number of reasons, firstly, the simulator is not meant to represent an actual processor & the PC will be running many other processes so although it states a certain scan time it probably will not be indicative of a real PLC processor.
also timers are known not to be that accurate as the complete bit will only occur to be true within the scan so can be at least one scan out each time.
The only way is to use timed interrupts & do your calculations there, but again in simulation it will probably not be the same as a real processor.
as you should be aware, most simulators will not simulate certain functions like high speed I/O, special modules & possibly analogues.
Scan time can usually be calculated by the number of instructions used & their relative processing time but that is a long laborious process.
I do know the Mitsubishi simulator in FX mode has a constant scan time of 100ms but on a real processor an average sized program can be in the order of 10ms, so I assume that applies to many simulators.

 

[cardosocea]

Time doesn't stop for your logic to be processed completely at each 25ms... Additionally, if you write logic in a certain way, the time it takes to scan it will vary between cycles as well. Then there's communications and cleaning up in the background which makes execution time slide further.

Because of the above, your timer will trigger a bit at 26ms, 27ms, 25.00001 ms, etc... That's likely what is causing what you're seeing.

Remember that the PLC timers are looking for the elapsed time to be above what you set them at, not precisely at that point in time.

 

[parky]

Yes Cardosocea is correct, the logic processing time may vary for example a function like Multiply two floats say for example takes 50microseconds, if the logic before it is false then the function will not run so the scan will be 50microsecs less than when it is enabled.
There are other things you can do to reduce the scan time for example if a loop of say 2000 variables takes 2ms, then on each successive scans do it in smaller chunks (assuming the required result is not critical on each scan).

 

[drbitboy]

As stated by others, those two timers each expire after at least 500ms or 20 scan cycles, at which point the second timer output is 1, which resets the first timer and triggers whatever else it is feeding (I assume you have cascaded the timers something like this:

  run  tm3  tm2
--] [--]/[--]/[---[TON tm1 500ms]--

  tm1
--[ ]---[TON tm2 500ms]--

  run  
--] [---[TON tm3 60000ms]--

)

and it takes another scan cycle, i.e. 25ms to restart the clocks i.e. for the cascaded timers to collapse and for the tm2 output to return to 0 so [TON tm1] can start again.

So it takes at least 1025ms per cascade cycle; consider that there is some uncontrollable overhead between program scan cycles (communication, bookkeeping, etc.) that can take a variable amount of time, so any individual scan cycle could take less, or significantly more, than 25ms. And a scan cycle is a discrete event; if one scan cycle goes long, it goes long, the next does not "try to make up the loss."

60s per 57 timer cascade resets is 1.05344s or ~1053ms per cascade reset; also it could have started, but not completed, another cascade cycle when the 60s timer expired, so that 1053ms is an upper limit.

58 cycles would be 1034ms per cascade reset; since we already postulated that it takes at least 1025ms per cascade reset, it is not surprising that the PLC did not complete a 58th cascade reset (although note again that the PLC might have started, and been most of the way through, a 58th cascade cycle).

Here are some experiments I performed on a MicroLogix 1100 to determine the variability of various timing approaches: https://github.com/drbitboy/PLC_2s_lamp_flash; that PLC has a 10kHz free-running clock and scan cycles were typically 1ms ± a fraction of a ms, so the time measurements had decent resolution. The PNGs and PDFs should tell the story; let me know if anything is unclear.

 

[creativepaper]

One way I believe to make this work would be to change your TON to 499 (or anywhere from 476-499) since you have a 25ms scan time. This will mean that you TON is DONE when you are at the 500ms mark.
Scan 475ms = TON running
Scan 500ms = TON completed and will process what you are after

 

[Lare]

As this is schneider you can use system bits %S6 for 1 seconds pulsing which comes from plc clock and is more accurate than using two 500ms timers.


Still you can see error because of scan time isn't exactly 25ms and 60 seconds isn't exactly 60 seconds.
You should anyway get rid of ton timers error.

 

[lfe]

I have used the PLC clock seconds, when they have changed from the previous value then a second has passed and I generate a pulse that is used in various places in the program.

Completely accurate over time.