# Writing long PLC code routine without scan-time over-run

I wonder if is a problem with response time of PLC in some cases? If so, what is the case? How to designer it solves ? For example calculation are to complex, the next step must be calculated in 200 ms but it take 600 ms.

[Clarification:] PLCs typically execute their logic in a repeating scan sequence as follows:

• Execute the logic.
• Write the outputs.

The result is usually a predictable scan rate.

Sometimes some complex logic has to be executed and this can extend the scan time and interfere with the performance of the process as the response time is extended.

How does the designer execute time-consuming logic without extending scan-time excessively?

[/Clarification]

Sorry for My English.

• I have no idea what you are asking. Commented Jun 16, 2016 at 14:09
• I'm guessing the OP is concerned about some unspecified control loop not being quick enough for some unspecified function... I'm no expert but I would not think a fully utilized PLC would execute it's control program more than once per millisecond and if there was such a requirement I would use a dedicated controller to get the fastest response needed. Commented Jun 16, 2016 at 18:16
• Looks like the OP is asking how the Scan Rate or Scan Time could cause problems .... my comments stand. Commented Jun 16, 2016 at 18:26
• I agree with what @Spoon has stated in his comments. I have indeed had to use a separate PLC for this type of situation. Additionally, some PLCs will allow you to set the scan time, so that it always executes a scan every X ms. This can make timing more consistent. You have to be sure that X ms is greater then your longest scan (ie when your complex algorithm runs). The time in between completing the logic scan and then start of the next is just dead time. Commented Jun 17, 2016 at 14:10

For those not familiar with PLCs, they are used in industrial automation and usually run with a program scan time of < 1 to 20 ms. (OP's 200 ms scan time would be considered very slow.) The short and preferably fixed scan time gives a predictable and repeatable response time to a change in inputs and timing of outputs.

Figure 1. PLC scan cycle. Source: The Basics of PLC Operation.

The OP's question is how to handle a procedure that will extend the program scan time - without extending the program scan time!

There are several ways of tackling the problem:

1. Farm the task out to a speciality module - e.g., a PID temperature control module and let it perform asynchronously with regard to the PLC scan time. The speciality module can update some shared memory registers when complete.
2. The PLC can do the same trick in certain circumstances where a portion of each scan cycle is set aside for special function programs which execute until their time is up, hold the intermediate calculations, return control to the main program and pick up where they left off on the next cycle. This only works if the system can tolerate a slow update rate for these sub-programs.
3. Complete the task over several scan cycles. For example, I recently had to create an RS485 message checksum routine in an old PLC. I created a word counter, reset it to zero and every scan added a word to the checksum and incremented the counter until the complete message was summed. It took maybe twelve scans to complete the checksum but that was fine as the message transmit was once per second.
• I don't understand what you have asked. Explain the problem you are trying to solve and ask a specific question. Commented Aug 10, 2016 at 11:06
• If the scanning time was extended to unacceptable values. Can we accomplish this task using the FPGA and to communicate with the FPGA to shorten the scan time? Whether such an approach is applicable? Commented Aug 10, 2016 at 11:19
• That question is far to broad. It depends on the task, the brand, CPU model, communication protocols, etc. FPGA may or may not be an appropriate solution. Commented Aug 10, 2016 at 12:42