Brute force vs. "programming"

This is what I do, All I/O are mapped to internals including spare I/O. The Symbols reflect the I/O some examples (depending on symbol length)
Real I/O TKO1_LS02_I Mapped bit TKO1_LS02_M
All I/O mapping is done in any way I think is convenient but in the event of having to change an I/O point I take a spare (Usually symbolled as Spare_X25 Mapped Spare_X25) then change the symbol to the original and do a search & replace, so it does not matter if it is mapped individually by bit or by word or by a loop.
The way I write code depends on a number of factors, standards of the customer, my preference for that bit of code & being mindful of the expertise of maintenance (not always possible).
I do not write code to "look how good I am", I write code that can be understood, and what suits the application.
Time is often a constraint, so many do not have the luxury of sitting back, mulling it over and trying ways to integrate it into a few rungs/instructions as possible. Nowadays memory is not so much of an issue, scan time probably not as latest processors are pretty fast & reducing code by using special functions and loops can actually increase scan time.
 
Thanks to everyone, no exceptions, so far. This has been illuminating. Keep it coming if you have more, or sit back and enjoy.


Stay safe ... stay well ...

I will refer you to this youtube video.
Unrolling the Loops - Computerphile
https://www.youtube.com/watch?v=guXgBe2wvEA
It is a computerphile video of professor david brailsford reminiscing about john warnock unrolling the loops for a demonstration of the apple laserwriter.
 
I will refer you to this youtube video.
Unrolling the Loops - Computerphile
https://www.youtube.com/watch?v=guXgBe2wvEA
It is a computerphile video of professor david brailsford reminiscing about john warnock unrolling the loops for a demonstration of the apple laserwriter.




I can't find it, but I saw an unrolled loop somewhere, and the macro for the looped operation was "pew" - so the code looked summat like this (unrolled by a factor or 8):


Code:
#define pew ...



ct = n >>3;

for (i=0; i<ct; ++i) {
  pew; pew; pew; pew; pew; pew; pew; pew; 
}
ct = n - (ct<<3);
for (i=0; i<ct;++i) { pew; }
;)
 
Last edited:
I prefer loops for a many reasons,
. Even when the loops are very large,
. the “overhead” burden mentioned can be easily mitigated for many style loops
.
. I use loops for nearly anything that will require me to duplicate lines of code more than 3 times
.
. Reasons:
.
. Say I have a PLC with 1000 Outputs and do 1000 "Hand-Off-Auto" routines in 1 loop...
. I will either make 0 mistakes , or I will make 1000 or 2000 or 3000 mistakes at a time,
. They will be very quickly noticed, fixed, never to be visited again
.
. If I write 1000 separate rungs of H-OA code, I could make hundreds of mistakes that may
. not be found until 5 years later when an sequence that has never occurred before happens
. causing an undesired reaction, or worse yet causes a catastrophic failure
.
. My “Hand-Off-Auto" code loop for 1000 output devices, will only be one rung long, in one folder & I will never need look at it again
. The ”Hand-Off-Auto” code will not be spread over 100 folders where you need to scroll past endless H-O-A code
. every time you trouble shoot a device
.
. If I later need to add a "Disable" or “Test” bit to the "Hand-Off-Auto" loop
. it will only take 10 seconds to add it to all 1000 devices
.
. The “overhead” burden mentioned, even for large loops, is seldom an issue & can be easily mitigated for many types of loops
. For example:
. If I write an index with a natural loop time of 1 second
. For 95% of my devices & alarms, 1 second is well within spec
. If a device or alarm function in that 1 second loop needs to react in milli or micro seconds…
. You simply “Pop” the index forward to the device(s) that needs a quick reaction.
.
. The action for that device will happen in the next scan of the PLC
. (milli or microseconds depending on PLC)
. An easily designed software driven interrupt, if you will.
.
. Much quicker to write
. saves thousands of lines of cluttered code, drastically reduces troubleshooting
. & reduces coding mistakes on an exponential level
 
I sort of agree with Davie, There are many ways to create loops that do not increase the scan time by much, for example on non critical time loops use the scan by incrementing the loop every scan, if the time is too great then use the PLC scan as a nested loop, i.e. for a loop of 100 on each scan loop 10 times. It all depends on the number of iterations you need, a small system that has only 30-40 common routines probably do not need to do a loop, but above that it makes sense. I think everybody agrees, loops are great, all will either work or not, where individual code can have mistakes, Again if well documented then should be easy for a reasonably competent engineer to understand.
 
Last edited:
In motion control, loops are avoided. If the program gets stuck in an infinite loop there could be damage or death. I spoke with a customer that used mostly Delta Tau motion controllers at the time. We were comparing motion controllers. I told him we don't permits for or while loops. The customer said that even though the Delta Tau allows loops he doesn't permit them because of the risk of infinite loops.


Looping can be done but there must be a yield() function in the loop. The yield function will yield control of the processor and let other tasks run so that only the one task in an infinite loop is stuck. Actually, well make use of this feature a lot.


PLCs usually scan the whole program except when executing state machines like SFC. When executing SFCs the PLC just scans the active steps and not the whole program. Inside the SFC step one can use while or for loops but now the whole program can lock up. It is often better to put a looping condition in a transition. The transition functions like a yield function I mentioned above and will let other tasks or charts run.


SFCs don't get mentioned on this site very often but I think they are great for machine control because they make state machine programming easy.
 
In motion control, loops are avoided. If the program gets stuck in an infinite loop there could be damage or death. I spoke with a customer that used mostly Delta Tau motion controllers at the time. We were comparing motion controllers. I told him we don't permits for or while loops. The customer said that even though the Delta Tau allows loops he doesn't permit them because of the risk of infinite loops.


Looping can be done but there must be a yield() function in the loop. The yield function will yield control of the processor and let other tasks run so that only the one task in an infinite loop is stuck. Actually, well make use of this feature a lot.


PLCs usually scan the whole program except when executing state machines like SFC. When executing SFCs the PLC just scans the active steps and not the whole program. Inside the SFC step one can use while or for loops but now the whole program can lock up. It is often better to put a looping condition in a transition. The transition functions like a yield function I mentioned above and will let other tasks or charts run.


SFCs don't get mentioned on this site very often but I think they are great for machine control because they make state machine programming easy.

Curious,
What would cause an infinite loop?
 
Most PLC's will not go into infinite loop as they have watchdog timers for safety (or at least should have). so if a loop takes up more scan time than the processor watchdog time it will go into error & stop.
If the loops require a form of comparison or condition to exit the loop then there should be some sort of safety in the loop. Another thing is checking for address out of range when doing indirect addressing in a loop (or anytime to be correct).
 
Curious,
What would cause an infinite loop?


A mistake in the program, usually caused by a bad assumption in the program's model of the real world.


But specifically, a loop exit condition that never becomes true.


As an example, see Ron Beaufort's timing experiment earlier in this thread. I tried it out, adding 1 to N7:0 in a loop. The results** I got showed less than 10μs per ADD, but the MircoLogix 1100 manual says an ADD should take over 13μs. So I wondered if there was an optimization going on inside the ADD, that if it detected that 1 was being added to a value and put back into that value, then it would utilize an an increment instruction, which might run faster than an integer add internally. So I chose to add the [Last Scan Time] instead, which was stupid to order 0 because my loop ended when N7:0 hit 512, indicating the loop had run that many cycles when it was adding 1, but by adding the last scan time, which is typically a value greater than 1, I would get a smaller, and variable, number of loop cycles. It was also stupid to order 1 because, on the atypical first pass, the last scan time is 0; needless to say, N7:0 d-i-i-i-i-i-dn't quite make it to 512 on that first pass and the program faulted. d'Oh!



** in my case the loop added 13% to the per-scan run time for 20 cycles, and up to 30-35% for large numbers (512) of cycles, as larger numbers reduce the effect of the timing rungs. The loop penalty comes out to 4-5μs per loop cycle the way I did it, so if more actual work is being done in the loop the proportional loss will be less.
 
Last edited:
Most PLC's will not go into infinite loop as they have watchdog timers for safety (or at least should have).


Semantic nit: oh they will definited go into an infinite loop, with a glad cry 'n all, but of course they will not stay there if there is a watchdog timer.
 
Curious,
What would cause an infinite loop?


Mostly caused by assuming the signal will always come in when that is never quite true.

Although, if a loop has to wait for something, it should just run the program and eventually the "loop" would be ready to run.



The way out of it is to have a reasonable idea of how long a loop will take, how long the watchdog will take and set the time out between both. If the loop is likely to take longer than the watchdog, run the loop inside the natural PLC loop.
 

Similar Topics

I know, why bother...If I had my druthers I wouldn't. I have a proven batching application developed and written in CLX, but the newest customer...
Replies
7
Views
2,725
Hi everyone i have a customer, who wants to show an alarm on the machine, if the I/O forces are enabled and set, on at ControlLogix L81E with...
Replies
3
Views
138
Hi there, I'm doing some extensive testing and commissioning with a slew of new Emerson PACSystems RX3i PLCs. It would be convenient to...
Replies
5
Views
80
Hello all, I have a question in regards to RSlogix 5000. I am having issues with the program force closing when I try to make online edits. We...
Replies
0
Views
95
Hello all, I have some parameter files that I'm using. Most of the tags are direct reference to the PLC, but a couple are HMI tags. If I change...
Replies
1
Views
472
Back
Top Bottom