Brute force vs. "programming"

drbitboy

Lifetime Supporting Member
Join Date
Dec 2019
Location
Rochester, NY
Posts
7,873
Summary


Where is the break between doing something brute force vs. using things like loops? I realize that the fixed fractional overhead of loops will sometimes be a deal-breaker, but I suspect that is rarely an issue in modern systems, so I'd like to frame the question to ignore cases where only brute force works as they already have an answer.

Thank you.


Details



Example from thread https://www.plctalk.net/qanda/showthread.php?t=124937, PDF here: https://www.plctalk.net/qanda/attachment.php?attachmentid=54442&d=1589929214



In [LAD 10] there are 31 rungs that set all of the step bits i.e.


Code:
EQU C5:0.ACC 0 OTE B3:0/0
I am looking for opinions: at what point would you put that into a loop?

Musings, TL;DR



I am naturally attracted to the more "elegant" approaches: if the computer was not invented to do repetitive stuff then why are we using it; I prefer pieces of code that use up less vertical real-estate on the screen. Also, doing housekeeping in a loop makes it easure (usually) to add steps when needed, and makes the process less error-prone. However, those are self- and coder-centered points of view, and I recognize that it can obfuscate the code down the road to a maintenance tech and even often myself, and it's harder to debug. So this could be framed as a trade-off between coder time and user time, or between capital investment and operational expenses.
 
Depends on the platform really... something like your example, I would prefer to create a block that had a proper name and documentation along with configuration inputs that would do it outside of the technician's eyes.
 
My decision process for brute force (I prefer in-line code *) against loops depends on the chance of the code being used again but for a different number of items. The machinery I work with has various optional parts that can vary between 6-32 so I use loops for these options.



(* For me brute force involves lots of loops to solve a problem by testing every possible case rather than using a more sophisticated algorithm)
 
Not exactly a loop but indirect addressing of valve/Motor manual control.
The idea is that there are up to 32 valves or motors (only 16 used in this though) to reduce the number of pages to process & manual control combined on the HMI the valves/motors can be run in manual from the process screen. so there are only 4 buttons inc/dec. buttons to set a graphic visible (arrow pointing to the valve/motor visibility) auto/man and On/off or start/stop.
The inc/dec buttons increment a integer, this indirectly points to the bits to control the valve/motor. this is better than having engineering pages with lists of valves. It also means that rather than having 16 or 32 compares to determine the valve/motor to operate it only takes a few rungs and some of those are sort of housekeeping.
No... I do not want well you could do this to reduce the code...….. This is complicated enough for a general maintenance tech.
#
 
to me, it all depends on what the customers maintenance can understand. if you make the program so complicated that maintenance can't understand the code, the machine will never run and you will loose a customer.


I would write the code so maintenance can trouble shoot it and keep the system running. catch 22 I know, but so true.
james
 
well ... there is "programming" ... and there is "art" ...

you are obviously searching for a "higher plane" ... it is a worthy quest ... attached below is an exercise which may help guide you toward the elevated understanding which you seek ...

start with a FRESH/NEW/EMPTY project file ... program ONLY the two simple rungs as shown ... fight ANY inclination to "spruce it up" with anything else (example, you do not need a condition on the TON rung) ... we're trying to keep this simple ...

next program your first "candidate" programming method ... for discussion, let's say that this is a "looping" technique intended to add twenty integers together ... put this "to be tested" code immediately below the two rungs that I've already shown ...

then once the program has been downloaded to the processor, leave the system in the PROGRAM mode – and GO OFFLINE ... to be perfectly clear – the value stored in the F8:0 location should still be ZERO as you exit ... and you should NOT be monitoring the test operation "live and in action" while the test is running ...

now use the keyswitch (etc.) to put the processor into the RUN mode ... specifically, do NOT use the programming software to start the processor ... keep your eye on a stopwatch and wait AT LEAST 30 seconds ... more time won't hurt – but do not "open the oven door and peek" until the TON timer has had ample time to run its course ...

now go back online with the processor – and write down the value which is now stored at F8:0 ... for discussion, let's say that value happens to be 12345 ...

so in simple terms, we now know that the processor was able to execute its entire program (the two original "test bed" rungs – AND - your "looping" method of addition) a total of 12345 times within 30 seconds of scan time ....

now reset the value of F8:0 back to ZERO – and run the test again ... in my experiments, the total deviation from one test to the next was usually "off" by a margin of only five or six counts/scans ... pretty repeatable I'd say ... (don't worry about resetting the TON between tests ... the processor's Prescan operation will take care of that when you tell it to "Go-To-Run") ...

now that you have a realistic idea of how many times the processor can execute the "looping" method of programming, DELETE your "candidate" rungs – and then replace them with a "brute force" method ... again for discussion, let's say that this time you use twenty unconditional rungs – with each individual rung having one ADD instruction to handle the math ... (later you might want to try it with just one rung and a BRANCH for each output) ...

now reset the value stored in F8:0 back to ZERO ... and follow the same drill as before ...

see how many scans/passes/executions that the processor is able to make using the "brute force" method ...

the data that you've collected should now make it possible to compare "apples" to "apples" as to which of two (or even more) programming methods is "more efficient" from a "speed" viewpoint ...

SPOILER ALERT: many programmers (especially those who come from a "computer programming" background) – are quite surprised to find that the "loops" that they were trained to use in the classroom are often burdened by an "overhead" that might not be present in ladder logic projects ...

IMPORTANT:

do NOT try this experiment while you are ONLINE (communicating with the processor) ... or – OK - go ahead and do it just for kicks if you insist ... what you'll probably find is that the communication requirements will take up RANDOM amounts of time – and any data that you collect will take on a "scatter shot" appearance ...

also ...

note that an Emulator will usually not give conclusive results – since it's running on a "computer" which has other background functions to take care of ...

I'll write more about the "artistic" ideas behind programming as time allows ... it's amazing how busy I stay now that I'm retired ...

stay safe ... stay well ...
.

how_fast.PNG
 
from James Mcquade:



+1 ... the best answer - in a nutshell ...




hmm, yeah, I guess it's a bad question to begin with, like "how long is a piece of string?" because the answer is always context dependent.


E.g. if Mr. Mcquade had a manager breathing down his neck to get a machine running NOW and to do it he had to either

  • create and complete error-free editing on 250 rungs,
  • OR
  • write one loop
and he knew he would have time to write it maintenance-friendly next week, do you think he might use a loop then?


That is admittedly a totally fabricated scenario, but it's only to make the point that context rules.


E.g. what if you're the lone maintenance tech and JMPs fit comfortably in your toolbox?


stay safe ... stay well ...


Amen to that!
 
Last edited:
(I prefer in-line code *)


Agreed, that is a more accurate use of those terms.


Although when typing a few dozen rungs when there is an alternative I tend to digimorphize (opposite of anthropomorphize?) myself into the machine and feel quite put upon (snif;)).
 
you are obviously searching for a "higher plane" ... it is a worthy quest ... attached below is an exercise which may help guide you toward the elevated understanding which you seek ...


Nice. I regret more and more that I did not get in the game while you were still a coach.


  • 32062 scans for looping 16 ADDs per scan
  • 36136 scans for 16 "un-rolled" ADDs per scan
So 12-13% more scans until the timer expiry for the un-rolled loop. I assume that difference would go up or down inversely with the complexity of the loop i.e. with the loop overhead as a fraction of the total loop work.



But as I said in the OP, RUN processing speed more or less a non-issue here: either it matters to the process or it doesn't, so it's not summat the coder has control over. I was more interested in the balance between coding time and other concerns.
 
Originally posted by Ron Beaufort:

you are obviously searching for a "higher plane"

Technically I think drbitboy is actually going the other way. I suspect he has all sorts of serious mischief he could unleash on unsuspecting maintenance guys everywhere. What he is trying to figure out is what he can get away with and still be able to walk on the shop floor without getting run over by a maintenance cart.

Originally posted by Ron Beaufort:

SPOILER ALERT: many programmers (especially those who come from a "computer programming" background) – are quite surprised to find that the "loops" that they were trained to use in the classroom are often burdened by an "overhead" that might not be present in ladder logic projects ...

drbitboy conceded that point in the threads starting post:

Originally posted by drbitboy:
I realize that the fixed fractional overhead of loops will sometimes be a deal-breaker, but I suspect that is rarely an issue in modern systems, so I'd like to frame the question to ignore cases where only brute force works as they already have an answer.
But it never hurts to reinforce that point.

Originally posted by James Mcquade:

if you make the program so complicated that maintenance can't understand the code, the machine will never run and you will loose a customer.

If this is truly the case, namely that the machine is down so often due to software issues that it "never runs", then software complexity is the least of your worries. I would think it would make more sense to make sure the thing works than to let it fail and call maintenance every day to "toggle the bit" that is causing the problem. Fragile code is fragile code regardless of the structures and instructions used. Fix the code. I won't lose customers because maintenance can't understand the code. I will lose customers because the machine can't function reliably with the systems supplied. Take this into the mechanical realm. Assume there is a bearing on a machine that fails on a weekly basis and requires an extensive realignment based on a complicated procedure after replacement. Is the issue that it takes time and expertise to realign or is the issue that the bearing fails every week? I suspect if the bearing failed once every 10 years the realignment wouldn't be much of an issue. I guess I would push to fix the actual problem.

Generally speaking, I am more often in a position similar to parky's. I have multiple examples of a type that all need to be serviced but not necessarily in a single scan. It isn't a loop per se but an incremented index that I would normally bump once a scan. Different application but the same feel and structure sans the loop. I do this all the time so it would be a bit disingenuous of me to say I have an issue with looping.

Keith
 
If this is truly the case, namely that the machine is down so often due to software issues that it "never runs",


I don't think James was going there, either. I think it was more "the line went down, probably a rare failed prox, and Joe my maintenance tech went into your code but could make neither heads nor tails of it to aid in diagnosing which prox, and yes we went cheap and didn't pay you to make an HMI screen for that, but we did spend that money for Joe to go to school so he can read ladder and he is scheduled to do it himself and now a maintenance cart is missing so I suggest you not go outside today ..."
 
I'll say one other thing about it: when I do get clever with code, I am bloody well going to comment it. Heavily. Because I could care less about Joe, it's my own embarrassment three months down the road I want to avoid.
 
Originally posted by drbitboy:

I don't think James was going there...

I'm not so sure. The funny thing is, being human, perception clouds reality for all of us. We would each spend 10 hours a week doing something we are capable of doing and can comfortably complete, even if it is completely unnecessary or is otherwise preventable, and not think twice about it. But heaven forbid we burn 10 hours once every two months on something we don't understand. That is obviously the start of armageddon.

None of us likes to feel helpless because, well, it makes us feel helpless. Those situations feel so much worse than things we can control so the effects of those situations are magnified.

Keith
 

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
136
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