Does for loop in PLC causes delay in cycle time

I am using Beckhoff PLC(Structured Text language) for a while and trying not to use for loops in all algorithm to make sure everything works in real time and won't get stuck in any loop. Time is so important for algorithms that I am working on. Any line in the code finishes in 1 ms. If I use for loop in somewhere I was thinking that when it comes into for loop, it will take 1ms for every iteration so the rest software will stay untill it finishes the loop.

For this reason I haven't writing any loop but one of my colleagues implemented his softwares with for loop. Loop starts from 1 to 100000 and every 1ms, counter increases 100000 and other counters increasing 1ms which are out of the loop.

The procedure that I know is, If PLC has time after handle everything below 1ms, it cares the rest which might be diagnosis check or IO check or whatever.

So how it can handle 100000 iteration while I identify cycle time is 1ms. What if I use 1 million different loop in program. It can handle for loop also because the program is so small. Would it behave same while software is huge? How I can understand it can finish all loops without causing overflow in cycle time?
I will try and see but for gaining insights I would like to discuss with you.

There is no universal answer to the question of whether processing can remain within your expected/required/preferred scan cycle time.

Computing power is bounded. Each iteration of a loop takes non-zero computing power so, of course, there can be more loops (and/or iterations of loops) to process than what your PLC can handle. There is no magic in your PLC that makes looping "free". On the other hand, looping is, generally speaking, very fast (compared to the processing that is performed inside the loop).

Loops are inherently sub-optimal only if they are wasteful. Replacing a loop that performs N iterations is not computationally worse than coding N times the same code without a loop.

Signs that your loop may be wasteful :

• It is used only to wait for something or poll some data
• It repeatedly does the same thing over the same data
• It uses no matching data structure (such as an array) that you iterate over

In a PLC, you need to make sure that your loops perform processing that reliably fits within your cycle time. The worst case is what you care about : if your loop takes 0.01ms 99.9% of the time, but the last 0.1% requires 1 second, it will not work.

If a loop is what best fits an algorithm (in terms of algorithm efficiency, clarity, maintainability), it is likely to be either the fastest (or very close to the fastest) method to express your solution. You should only be afraid of loops if you code wasteful loops.

In the end, if your PLC is not powerful enough to do everything that needs to be done even with a well-coded solution, the presence or absence of loops is not the problem or the solution. But assume your PLC is fast. Very fast. I run programs with hundreds of thousands of variables, many loops executing every cycle, and am getting cycle times below 0.1ms on a Raspberry Pi. I never avoid loops for anything that is "loopy" by nature, but my loops never block waiting for something, they never allocate memory or perform processing that will introduce meaningful variation in execution time, and they do "simple" things (where "simple" is read with the understanding that computers are truly very fast nowadays).

The real question is not whether loops are good or bad, but whether you are able to identify when to use them, and know how to code them well. It is not about loops being good or bad, but rather you being good or bad with them.

Also, test. See how many iterations of an empty loop you can perform before your cycle time suffers. Try it with non-empty loops that perform things you care about. You will learn about your true bottleneck quickly, and are likely to stop worrying about loops and focus on code inside the loop.