Brute force vs. "programming"

from drbitboy:

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
[my emphasis added] ...

BINGO! ... that in a nutshell is the viewpoint of the hapless Maintenance Manager who can't keep the plant's machinery running ... it's usually NOT that the PLC code is fragile ... it's the fact that back in the "good old days" there was a physical WIRE connecting something that wouldn't RUN (example: a pump) back to the something that told it WHEN to run (example: a proximity switch) ... even a trained monkey could eventually track down the problem by following the physical wire from one end to the other ...

but ...

nowadays – there is no PHYSICAL wiring between the "innies" and the "outies" ... the connection is made through the logic/code of the PLC ...

let's just assume (gosh I hate that word) that the necessary software is loaded on the maintenance technician's laptop computer ... (how many forum threads and posts have been sacrificed to THAT simple assumption?) ...

and let's just assume that it's possible to have the laptop go online and communicate with the processor ... (yet another plethora of threads and posts sacrificed toward accomplishing what should be a fairly simple connection) ...

but let's just say that now the technician is online – and ready to track down WHICH prox switch is keeping the Bo$$ from making money tonight ... if he's lucky (I prefer to say "blessed") then maybe the "green on the screen" (or rather the lack thereof) will help him nail down the problem – just like the tech was taught in the PLC training classes that he attended ...

oops! ...

turns out that this code wasn't written in Ladder Logic ... so how about Structured Text, Function Block Diagrams, Sequential Function Charts, Equipment Phases, Add-On Instructions, and so on and on – ad infinitum ...

throw in a "loop – a whirl – and a vertical climb" or two – and now we're back to James Mcquade's statement ...

I would write the code so maintenance can trouble shoot it and keep the system running.

sounds like a good objective to me ... (the old saying: "money talks" comes to mind) ...

I know from personal experience that most Maintenance Managers are NOT interested in their technicians troubleshooting the PLC's code ... they just want their crews to be able to "track down" the NON-PHYSICAL connection between the money-making outputs – and something like a malfunctioning input - which might be keeping the system from working ...
 
Last edited:
The original question:
Where is the break between doing something brute force vs. using things like loops?
I think you're promoting a false dichotomy. If I needed to decide whether or not to program a loop in a ladder program, I think I would first ask whether the task should be programmed in ladder or whether structured text would be a better fit.
 
The original question:

I think you're promoting a false dichotomy. If I needed to decide whether or not to program a loop in a ladder program, I think I would first ask whether the task should be programmed in ladder or whether structured text would be a better fit.




personally (to me) the language is irrelevant. I was thrown by someone's program on a Siemens recently; was it called STL - STatement List? - not structured text anyway. I knew summat like that existed because my brother mentioned it. I looked at it, googled it, got an idea, and decided "okay, basically somewhere between assembler and forth."


But yes, we need to look at the problem and choose the right tool from the toolbox. Or sometimes we need to write code that the tech can read. And just because there's an application for a loop that doesn't mean the entire project has no use for ladder. Look at the test RonB gave: it only lost 12-13% on speed; I would think the loss in clarity would be a bigger issue, but then again I get agitated when I see dozens of rungs doing the same thing to different variables. Just because the loop is implemented more cleanly in another language does not mean it should not be used; and who's to say what's clean anyway? The final hardware that executes don't know how many legs a horse got.



There's a language out in the 4th/5th generation procedural language world that is used for a lot of things. They call it the "Swiss Army Knife" of programming languages because it can "do everything." Do you know what the practical definition is for Swiss Army Knife? It's the Wrong Tool for Every Problem.


Really rambling now, wheeeee!
 
from drbitboy:


[my emphasis added] ...

BINGO! ... that in a nutshell is the viewpoint of the hapless Maintenance Manager who can't keep the plant's machinery running ... it's usually NOT that the PLC code is fragile ... it's the fact that back in the "good old days" there was a physical WIRE connecting something that wouldn't RUN (example: a pump) back to the something that told it WHEN to run (example: a proximity switch) ... even a trained monkey could eventually track down the problem by following the physical wire from one end to the other ...

but ...

nowadays – there is no PHYSICAL wiring between the "innies" and the "outies" ... the connection is made through the logic/code of the PLC ...

let's just assume (gosh I hate that word) that the necessary software is loaded on the maintenance technician's laptop computer ... (how many forum threads and posts have been sacrificed to THAT simple assumption?) ...

and let's just assume that it's possible to have the laptop go online and communicate with the processor ... (yet another plethora of threads and posts sacrificed toward accomplishing what should be a fairly simple connection) ...

but let's just say that now the technician is online – and ready to track down WHICH prox switch is keeping the Bo$$ from making money tonight ... if he's lucky (I prefer to say "blessed") then maybe the "green on the screen" (or rather the lack thereof) will help him nail down the problem – just like the tech was taught in the PLC training classes that he attended ...

oops! ...

turns out that this code wasn't written in Ladder Logic ... so how about Structured Text, Function Block Diagrams, Sequential Function Charts, Equipment Phases, Add-On Instructions, and so on and on – ad infinitum ...

throw in a "loop – a whirl – and a vertical climb" or two – and now we're back to James Mcquade's statement ...



sounds like a good objective to me ... (the old saying: "money talks" comes to mind) ...

I know from personal experience that most Maintenance Managers are NOT interested in their technicians troubleshooting the PLC's code ... they just want their crews to be able to "track down" the NON-PHYSICAL connection between the money-making outputs – and something like a malfunctioning input - which might be keeping the system from working ...

The clever Maintenance Manager would be asking why the screen doesn't say what the process is waiting for, getting rid of the need for Bubba to cart around his laptop in the first place.
 
i'm answering several posit.

I did have a boss looking over my shoulder. yelling at me, calling me an idiot, even threatened to fire me in front of our customers because of something I knew I had to fix after the customer left. I finally quit.

I have written plc code.
plc 2, 5, slc 100/150, slc 500, Omron, mitsibushi.
the biggest program was 2400 rungs on a multi station walking beam. I have programmed for next loops for a message display, and even indexed addressing.

when i stated that a machine would not run, what I was referring to is a machine that was programmed by my co worker. he NEVER, EVER, EVER used the statement A>=B or A<=B, or A = B. everytime the machine faulted, there was 8 places the program could have stopped. an oem programmed a machine with 14 latch bits and 24 unlatch locations of the same bit. how do you debug programs like this? I rewrote that program and downtime went from 24 hours per 80 hour week to less than 10.

as machine builders/programmers, we need to always be aware of maintenance and program debug capabilities. I have always tried to be mindful of them.

I am not slamming anyone and do not mean to insult anyone, I do apologize if I have insulted anyone.
just trying to explain my posts.
james
 
I'm not a software engineer, so I consider everything I write (No matter how complex) to be "Brute Force". The criteria is pretty simple.

It has to work. It has to be robust. It has to be easy to understand.
 
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 ...
 
As people are aware, over the years more and more computer programmers have got into PLC programming (as an example drbitboy, who l hasten to add is wishing and willing too learn plc programming the "correct way" or his brother will kill him) and must wonder what this rubbish LD programming is even doing in a PLC and hence they start writing code in higher level programming methods.
I haven't come across any coding done by a programmer so aren't really in a position to criticize, bar what l have read on various forums, but what l would see being the bigger issue is the programmers are very unlikely to have any mechanical/electrical aptitude hence wont fully understand what they are coding and maybe aren't aware of the safety downfalls they may have written into the code.
I'm all for LD myself when it is to be easily followed, but the ease of writing ST for more complex areas is hard to beat, as well as function blocks, take the PIDE in AB it is the only way it can be implemented, on top of that it is easy to follow, even for Bubba surely.
 
I'm sure that the Gang of Four would be available and happy to help troubleshoot any problems with that machine that happened at 3am on a sunday.
 
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.

As with everything there are exceptions... the offshore drilling industry prefers certain equipment that comes completely programmed in Siemens STL. Granted, their competitors and even internal competing products are absolute ****, but it's not always black and white.
 
Like Drbitboy said, he is learning PLC's and has not had the experience. His equipment exposure is limited as he is doing this off his own back. But his determination, excellent skills (and no doubt his technical skills in programming languages) are definitely up there. however, I have been in this game for over 30 years, I too came from a background using C, C++, pascal & forth, but that was over 30 years ago. One of the problems is as already mentioned the exposure to hardware of a process. I have worked alongside many companies that seem to employ programmers (highly educated) but no on-site exposure, and then they use commissioning engineers to spend their lives on site. This often turns into a bit of a disaster. The programmers do not always understand the problems so the software is written without thought of the process (in other words they take a spec and code accordingly). The companies I have worked directly for all engineers follow the projects from initial meetings to final commissioning on-site, this has proved to be a winning combination. One system I was called to contained a number of PLC's & HMI's & a Scada system. The company called me in after falling out with the original supplier, fortunately as the system was bespoke to them they did have copies of the software, I spent a week with them in production listening to the people that had to run or maintain the system, It became apparent that the design of the screens & the way it was controlled (although no objections to the actual code) it just was not user friendly, even trying to do certain functions required paging through screens to find the right area, again the software had been written by bums on seats that could not or would not visit site. I did feel sorry for the two site engineers who spent a lot of time on-site as piggy in the middle. One left the supplier & contacted the customer, with my blessing they employed him for a short term contract, working with him it became apparent that some simple changes would make the system easier to run & maintain.
 

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