what is the maximum timing error when using a timer in a plc

ok need some help with this...what is the maximum timing error when using a timer in a PLC?

1. 1x the Plc scan time
2. 300ms
3. 2x the plc scan time
4. 4x the plc scan time

which one of these choices would it be ???? thanks for your help one this

5. Incalculable in the generic sense.

thanks for the input does anyone else have any suggestions?

1. 1x the Plc scan time
2. 300ms
3. 2x the plc scan time
4. 4x the plc scan time

Psykologist question "In the list above, which selection seems to stand out ?".

I have feeling that the maximum timer error will be 300 ms. But cant explain why.

Question in phrased so that no answer can be given. Unless, you disclose what course you are on?

I must AssUMe that this is a question from an older, un-updated book or lab material. Normally, for most old traditional PLCs, the answer would be Number 1. The timer would only be updated one time per scan, so the scan time effects the error. Larger or longer programs will have a longer scan time, so a larger error.

In more modern PLCS, the timer update can be controlled so that it is more often, so the maximum error could not be determined without more information.

PLC errors and stops - timer error = infinity or at least indefinite. Lots of unstated conditions in that question.

In the older AB PLCs like the PLC3, the timers had to be sampled every so often just to get them to run. It's actually in the manual. They've gotten better, but as a rule of thumb, in Allen Bradley for example, even in Controllogix - DON'T use the timers for actual timing. They've improved, but still aren't the proverbial atomic clock.

There's no answer for your question. In the PLC-3, a 45 second timer, and the size of the program we had, made the timer complete in about 40-50 MINUTES. We duplicated the timers in the program to make them work. 60X the timer value was not in your answer, but I have personally seen it!

OK, I'll try and give an answer, but this answer is based on the way A-B timers work, viz...

Each time the rung containing the timer is scanned (and let's assume the rung is true), the processor compares the timer's internal time reference against the processor's "clock", and calculates how many accumulator time periods have passed (different processors have different timebases, 1mS (Logix5000), 10mS or 1S (PLC5), 1mS or 10mS or 1S (SLC).

So the processor does the maths, and then decides how much to add to the timer accumulator.

The timer's internal reference is then updated from the processor's clock ready for the next scan.

It then checks to see if the timer has "timed-out", i.e. the accumulator is greater than or eaqual to the preset, and if it is, the .DN bit is set, and the .TT bit is reset.

So, to answer the OP's question, worst-case scenario is that the timer is scanned, and it has just failed to meet the preset value, let's say it has 1mS left to run. So the processor goes off to scan the rest of the logic, and returns to the timer 1 scan later. The maths is done, the accumulator is updated by the time difference between the processor clock and the internal reference, and then it checks to see if the accumulator is greater than or equal to the preset, which it sees is so, and the .DN bit is set.

So the "timing error" is marginally short of 1x Scan Time.

Of course, this timing error is NOT consistent.

All of the above assumes that the timer instruction is scanned more frequently than the internal reference will allow.

The number of bits used for the timer's "internal reference", or timestamp, determines how frequently the timer needs to be scanned in order to maintain timing, without loss of synchronisation.

These bits are hidden away inside the unused bits of the memory word occupied by the control bits, .EN .TT & .DN. (This is still true in the case of Logix5000 processors, because the TIMER data-type must use 3 x 32-bit words of memory, even though it contains only 2 DINTs and 3 BOOLs).

If my memory serves me correctly, PLC3, PLC5 and SLC timers need to be scanned more frequently that 512mS, or time is "lost" because of the resolution of the internal reference. tomalbright's PLC3 timer problem is the result of "lost" time due to this.

Thanks daba. In Contrologix, I corrected some logic using a one second timer. The time accumulated was off by about 75% during a month. I used the PLC internal clock second instead to trigger the runtime counts, but it's STILL off, makes about 95% over time. There is no better way to count time than using an internal clock. The program time is in the 100ms range. I'm probably missing actual seconds in the program scan; the error is very low, but it's still there. The 1ms error is probably there per daba, but programming, scan time, internal reference all play a part even when sampling an internal clock.

dancingbear312 said:

thanks for the input does anyone else have any suggestions?

Click to expand...

9a: Read all the manuals for all of the bits and pieces both physical and abstract, until you fully understand all of the questions, fill in the specs and formulas, and then calculate the maximum error. Since there is no "all encompassing" formula for a "PLC" you must give a hardware specification, then find all pertinent hardware and software reference manuals.

Give us a (list of the) platform(s), then we can poke you in the right direction to derive the formula for each. Full part numbers and communication specifications (if applicable) are insurance of direct and precise answers.

Is this for a test? Think of the real world. Pick a real situation, find all the specification and do the math. This is my 9a)-eth and final answer based on the engineering specifications supplied...by the OP

9B) I wish to write a retraction to my blabbering above. In the generic sense with rounding I suppose Last_Scan_Time during the done cycle would be the answer, plus or minus a CPU clock resolution (or two)?

The scope of the question is clearly the scan logic processing,
not the internal clock precision or input time filters, not to mention the PLC stop by error. I guess, timer in subroutine or in skipped part of program is also out of the scope.

For a cyclic program, the maximum timing error scenario is the following:
- The timer contact appears before its coil.
- The timer coil is driven by a physical input..
- These are the last rungs in the program.
Now, if the physical input is activated just after the I/O refresh between scans, one full scan will pass until the next I/O refresh reads the input active.
Then the entire program must be executed until the last rung with the coil is executed and the timer starts timing.
That is, the timing start may be 2 scans late after the physical input activation.
Now, if the real timing elapses just after the timer coil execution, one full scan will pass until the coil is executed again and the timer is done.
When the timer is done, another scan to read its contact as active.
That is, the done contact reading may be 2 scans late after real timing end.
The correct answer is 4xScantime, if the scantime is significantly shorter than the timer resolution, otherwise the latter significantly contributes to the timing error.

How about interrupt timers?

The one and only right answer is: infinity. If you make a program error you might end up with a timer that never finishes, so the timing error will be infinity.

In other words: this is a perfect example of a poorly worded question. Not one of the provided answers is correct and there's too much room for interpretation. If at least it was stated what PLC was thought of when making up that question, it would have been half-way to becoming a good question.

If the question would have been like "What is the maximum timing error when using a correctly programmed S5-timer in an S7-300 PLC?" then the right answer might look like "about plus zero minus one time the timebase used".
Any other answer can be disputed in this case.

This again proofs that making up good, indisputable exam questions is about the hardest part of a teaching job.

Kind regards,