Scan Times

[Doug-P]

I was talking with a programmer who was shocked at our 23ms scan time and pointed out that he writes code to try to keep scan times below 10ms.

Don't tell him about my 180ms sorter, he'll have a conniption fit!

 

[dandrade]

two mystery

I have an application with 2 servos with encoder AND Tachometers. The tachs go directly to these old servos and the 2 encoders go in the PLC.

Unfortunatly, the positionning of the servos is directly proportionnal to the scantime because the speed AND direction are through anaolog modules.

It works fine and my client is pretty happy about it BUT we had an issue where the width of the product would varie after some of my visits.?????

Bizarre!

I found that whenever I would make ANY online-changes the PLC scantime would jump from 18ms to 85 ms.

Yaks, that one was hard to find. I just did not look at scantime first.

I had exact structure and problem.Inclusive, adds code of memorization in blocks the value of scantime, when the error occurred the operator,push the button retain the block in the memory.

He had not excessive variation > 9ms.

Returning, to the general problem.

If the scantime does not influence the performance, because of this? Reporting of layer, of a Brazilian magazine automation. It showed that the exchange from the CPU, increased the performance system, by the diminution of the cycle of the machines.

 

[JesperMP]

Originally posted by Pierre
You mention something like a coil. What is the make and brake time of a coil? A LOT MORE THAN YOUR 10 ms

Originally posted by Kamenges
..it has been my experience that machine speeds are not limited by processing times but by mechanical limits.

If you calculate the possible minimum cycle time as determined by the mechanical and electical limits, then you get a theoretical minimum cycle time.
To this value you have to add the lost time used to proces the steps in each cycle.
To put it short:
1. The ROI for reduced cycle time increases when the theoretical minimum cycle time decreases (a 5 sec cycle time is more worthwile to optimize than a 30 sec cycle time).
2. The ROI for reduced cycle time increases when the number of steps in a cycle increases (20 steps is more worthwile to optimize than 5 steps).
and to this you can add the obvious:
3. A program that can be reused many times multiplies the ROI (a standard machine that is sold in the 100's is more worthwile to optimize than a one-off).

 

[PhilipW]

Scan time is the the PLC programmer's equivalent of the boy racer's 1/4 mile time...it means something, but it is only ONE of the engineering criterion that measures the performance of a system, and not always an important one.

In our dairy industry, where we run 5-10,000 I/O plus 20-50 PID loops in a single CLX L63 processor with the memory maxed, we routinely run all the device logic at a periodic task rate of 100 msec, and the sequencing logic at 200 msec. Works just fine for these applications.

On the other hand I have an SLC5/05 based Emergency Generator and Load control system that trundles along at a 30-50 msec scantime when nothing is happening, but when an MCB switching event occurs I can get throughput time of about 8 msec, with just a few tricks in the program organisation.

When I started programming I often placed too much emphasis on minimising total scantime, but to no real benefit. With time I have learnt to write processor efficient code, mostly by use of state engine sequencers and event based tasks...primarily with the goal of keeping the code well organised. As a result I finish up with deterministic code where I know everything will be processed in the time window it NEEDS to be actioned in; not longer, nor shorter.

In fact I would argue that many PLC programmers tend to OVERPROCESS their logic. I would hazard a guess that 95% of I/O out there in the real world doesn't need scanning more often than ten times a second (100msec). The processor resource that this frees up can sometimes be utilised in other ways, ie better comms, more features or more deterministic performance.