0

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.

Freq
  • 83
  • 2
  • 7

1 Answers1

2

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.

Fred
  • 6,590
  • 9
  • 20
  • Many thanks for detailing. In various environment, if you write a code that includes for loop, it will go to the next line after finishing the loop. This is the process normally. But there is no time dependency if not stated. On the PLC side, testing would be a better idea. – Freq Feb 05 '23 at 20:33
  • IEC61131 for loops are no different from loops in other languages. After a loop, the code continues to the next line. A loop does not replace the normal scan cycle, and the PLC does not exit the scan cycle after each loop iteration. All iterations of a loop are performed inside the same scan cycle. A loop is not a way to spread processing over many scan cycles, if this is what you are hinting at. – Fred Feb 06 '23 at 21:22
  • If you are able to emulate a FOR loop at the PLC scan level (e.g. create a FORLOOP structure that you Initialize the COUNT member and set CURRENT equal to 0 (0-based or 1-based FOR loop, maybe pass that in???), then call a BOOL Do() method that takes a FORLOOP instance that does the work for THAT iteration, then increments the internal CURRENT member, then have Do() return FALSE once the FORLOOP instance CURRENT member reaches the COUNT value??? It's the opposite of the traditional FOR/NEXT where HERE you are relying on the PLC I/O scan to "iterate" the loop??? – franji1 Feb 09 '23 at 20:37