PLC Programming.... or what... cars & motorcycles?

Terry Woods

Member
Join Date
Apr 2002
Posts
3,170
Much of what has been said lately reflects a lack of interest in the "art" of PLC Programming.

Certainly, one must understand the mechanics of programming PLCs and configuring the associated hardware. But, the true power of the PLC is not known until one looks at PLC programming as the ART that it truely is.

To pursue the "ART" of PLC Programming means to understand what is really necessary to program PLCs to think as humans do.

To many programmers, a PLC is nothing more than a faster version of an operator, or worse, a simple switch-handler designed to reduce real relays and wire count.

A PLC program can not be like an operator unless the programmer had the foresight to create his code in a manner that resembles an operator. He would do well to consider mimicking a very good operator.

One major defect in operators is that they do not know what is happening when failure occurs. Of course, they see the result of the failure. But, usually, they do not know why the failure occurred. All they know is that a FUBAR happened.

Of course, the failure occurred because of some condition. It could be because of a logic fault or an output device fault. In many cases one can not determine that the fault occurred because of an output device, at least, not directly. In that case, one must be able to look at the logical conditions at the time of the fault and then look at the physical results of the fault to determine the cause.

It all depends on the ability to analyze evidence. In some cases the evidence is clear to the PLC and can be easily indicated on an HMI. In some cases, the evidence is less than clear.

In any case, the program should always be able to indicate what it was doing at the time of the fault. Knowing the process, one should always be able to know what the process was expecting to happen next.

Only in this way can the PLC Program hope to have a chance to indicate the true nature of the fault.

A working program is not a problem. A faulted program is a problem... the question is... why did the program fault?

Is it a logic issue? Or is it an output issue? Or is it an Input issue?

You can not KNOW the cause of a problem unless you develop the process in such a way that it can KNOW!

Devopling a process is as much about fault-handling as it is about process-handling. Having a system that can identify its own faults is remarkable!

That is a system that will cure itself! ... eventually... if the programmer is paying attention.

That is attainable though the ART of PLC Programming!

Comments?
 
Well said.

Now I have a daffynition for you.

PLC - abbreviation Programmable Logic Control. 1. A cabinet full of relays, wires, timers, counters, switches and indicator lights packaged in a shoe box.

I do more trouble shooting with PLC's than actual programming. Trouble shooting in its' self is becoming a lost "ART".

Having an HMI installed with every PLC that is programmed to actually show the control circuits in their ON or OFF state is quite nice. An engineer at my company added an HMI on a 12 plc project as a trouble shooting aid. Some of it was not calibrated or functioning fully. The customer almost demanded I get it calibrated correctly. I told him the HMI was not part of the contract and I would not, at the present time, make it fully functional. The items to be displayed were completely available by looking to the right 3 to 15 feet. That was 4 years ago and today all of them are fully functional. In all new systems, to all customers the HMI is a normal part of the package and has the new techs spoiled. Once fully tested and functional it makes breaking out the test equipment almost unnecessary. I likes it.
 
Leadfoot said:
I do more trouble shooting with PLC's than actual programming. Trouble shooting in its' self is becoming a lost "ART".
That is exactly why I insist on programming in a "troubleshooting mode"
How many times have any of you uploaded a program (if it's from another vendor, you have no documentation) and had to spend hours just trying to figure out what the original programmer was doing with bit shifts, moves, and things of that sort. After you finally figure out what he(she) was doing, you realize it was simply to make what you are doing now extremely difficult, if not impossible. (Or does this only happen in the mining industry?)
Now, don't jump in here trying to defend bit shift, moves and things of that sort, I KNOW they have a purpose, but be honest, you have seen them used where the only concievable purpose was to confound the next guy.
Is this good programming? Is it a way of saying "look how clever I am", or is it simply a way to confound the person who follows you onto a job?
Whichever it may be, is it ethical? I think not.
 
I did a C200h to CS1 that had a bunch of math on the analog inputs. The man with the program was killed in a motorcycle accident and the mfgr was out of business. The customer did not realize what the file was and deleted it from the laptop. They got lucky while at a trade show, found the company that bought out the original company. They were able to get prints. This allowed me to ID all the in and outs.

Turns out after talking to a hydraulic sales rep that had spoken with the man that had been killed, he was trying to have the speed of one shuttle cart be speed matched to the main shuttle cart. It looks like a cheesy PID sort of.

Problem was the carts did not move at the same time. They are pullers. When the first one gets to its limit, the second one starts and the first one returns to home. I removed a bunch of logic math instructions.

This past couple of days, I have been muddling thru bit shifts, registers, moves, compares, add, subtract, multiply and divides on a cut to length line. Fortuately for me the engineer that wrote the code is real sharp, the engneer that started the system makes the design engineer look dumb and I have both of their cell phone numbers. There has not been PLC problems, just one peripheral PCB keeps failing. While monitoring it and adjusting the "BAND AID" to keep it running until the new PCB gets here, I watch the inputs from the operator's HMI flow thru the PLC to the PCB. I used to scratch my head and say HUH a lot. Now I say wow,I understand that.
 
We use an automated packaging line that consists of four OEM machines that were modified to work with each other as a system. The engineering firm that put it all together for us had built a very elaborate shutdown / startup sequence that worked extremely well, but took FOREVER. It was well over a minute before everything shutdown all the way and then started back up.

Our production teams hated it. They got in the habit of pulling packages of the line and piling them up to be processed later to artificially reduce the shutdown time. This really did nothing but make a big mess, but I couldn't get that through to them. The line was constantly surrounded with piles of partially packaged items.

Finally, I got involved and re-wrote the entire sequence so it was about 8 seconds down, 8 seconds up.

Almost a year later, operators were still yanking packages off the line every time it shut down. I kept yelling at them. I'd force them to watch the machine shut down and start up and chastise them for not learning the process.

Then one day as I was walking past the machine a downstream peice of equipment faulted and then was immediately corrected by the operator before the shutdown was complete and a huge slug of packages suddenly took off and jammed up one of the machines.

45 minutes later as I was pulling my hair out staring at my logic, I realized I had overlooked this very obvious situation and what was happening was that the startup sequence was beginning while the shutdown sequence was also happening resulting in a giant mess. o_O

This was why the operators were still pulling packages off during shutdowns.

Since then I always spend a lot of time thinking through every possible scenario whenever implementing new logic. I also follow up with the operators at given intervals after my initial testing is complete to make sure I didn't overlook and stupid situations.
 
Devopling a process is as much about fault-handling as it is about process-handling.

I will quote this a bit farther and say that "Fault handling is part of the process."

Unfortunately this is a problem with a lot of programs we see today. Not only in PLC's but in our PC applications as well. I agree with Terry 100%. The 'ART' as he mentioned is not easily taught but I think aquired with experience.
 
I also agree with Terry.
95% of "PLC" faults are I/O devices, a good PLC program will handle faults in a orderly fashion so that diagnostics are easy. Most of the projects I have done there is no need to "go online" with programming software to fault find. The HMI devices give all the information required. All PLC programs should have built-in exception handling, then logic faults won't occur and I/O faults are quickly identified.
On a large project I will put a full set of alarms and diagnostic tools on the HMI and on small projects with 2 or 4 line HMI's then I use fault codes with a fault-finding chart in the manual.
It may take longer to program but I don't get much grief from the operators or maintenance staff and downtime is greatly reduced.
I can count on the fingers of one hand when I have encountered a genuine internal PLC fault.
 
Well said, Terry. What it comes down to for me is a simple question.

Does the individual consider automation systems a job, or a profession?

To me, it is a profession, and I am a professional. I try to act accordingly.
 
No prima-donnas thank you.

Terry Woods said:
But, the true power of the PLC is not known until one looks at PLC programming as the ART that it truely is...
Comments?

One word springs to mind; Balderdash.

Terry, I have read some very insightful answers that you have written to posts on this site. I'm guessing that you started this particular thread with your tongue firmly in your cheek.

Oh well, I'll share my opinion on the so-called ART of PLC programming, with regard to PLCs thinking like human operators do. It just isn't going to happen is it, how is a PLC supposed to stop mid-scan to stare at the posterior of the new lab assistant. How is a PLC supposed to know that a machine in the next production line (controlled by another PLC) has occasional faults caused by noise and that it might also have the same problem? Artificial intelligence is currently at the ****roach level and it won't get much better until they stop using silicon based technology. PLCs can aid operators for mundane tasks but they can't replace operators.

Writing PLC programs isn't ART, its automation (with a small a). It's no different from other methods of automation: relay logic; pneumatic; hydraulic; ushidayotic, etc.

(A message to students reading this thread; don't mention the ART of PLC programming during a job interview.)

A PLC program that identifies it's own faults? Yeah, multiply the project cost by at least 50. The customer has ordered a machine that isn't supposed to have faults. If the fault is in the logic it is still necessary to correct it. If the person who fixes it is the same person who wrote the original, then that person learns not to make the same mistake again (one hopes). It would be cheaper for the customer if you sold them a support contract, and better for your business too.



Terry Woods said:
Devopling a process is as much about fault-handling as it is about process-handling. Having a system that can identify its own faults is remarkable!

That is a system that will cure itself! ... eventually... if the programmer is paying attention.

That is attainable though the ART of PLC Programming!

:ROFLMAO: Hey, can I buy it in a bottle? and do I get a free alarm clock too?

For ART in automation, check out W. Heath Robinson.
 
Thank the Lord for some sense , far too many cut it and bash merchants lurking about .

"Does the individual consider automation systems a job, or a profession?"
Neither , they are a passion and an artform when done well , not just a means of buying beer and knickers - though that is obviously important.
 
Fragmented art

Terry, when it is illuminated writes clearly and direct.You it detached the part of control of faults and diagnosis, is a part of the cake, but valley one topic.

Programmer a PLC it is an art, is only true when exist transformation of code in wealth, aggregate value. Important besides producing with "art" it is necessary to know to apply, have sensatex not to burn time in a code that to end will be inefficacious.
Everything needs balance, when more to insert lesser code the control on the total. An high mental cost.
Before must know as, because, when add one code. It must identify, know and produce diverse pairs of the combinations problem-solution.
More rare to occur, to convert is one code with the qualities: robutez, flexibility, effcience and effective..

Currently the art is to manage shambles An art only can be produced when it can total be shaped by the artist. Mainly, because the manufacturers consider that the set software/hardware, in condition with the necessity real of the programming.

We have that to modify (different of adapt) the thought, strategies for object! Modifying until the type of problematic. (Many times are the biggest parcel of time) Art, in the direction of the word, is when it has free capacity to manage the workmanship...

To say "Programmer PLC is art" in a auditorium of the Hannover, currently which the impact? Sanction, acts of contract UP or DOWN

How much that valley is art? The phrase of the present time "Programmer is art without wealth" can be evidence in the world.

Ps: Only found stranger the title,is not necessary to call attention
 
Last edited:
Sorry, Terry, I don't concur with your use of the word "art" when associated with programming (whether it be PLCs, PCs or whatever).

To me 'art' has certain key implications which I don't want around my automation system :

- it is not deterministic. If someone composes a piece of music, paints a picture, writes a book or a poem, it will probably turn out differently each time they tackle it. The act of producing art changes the artist. Their world view is no longer the same, with the result that what they produce the next time, although still 'them', is now a different 'them'. How many times have you heard people say about a recording artist "oh, I liked his early stuff, but I stopped buying his albums after .... "? That's not to say the later albums are better or worse than the early ones: the main thing is they're different. And when you're building your 25th shrink-wrapping machine for me as a customer, I don't want to see how Terry Woods developed as an artist through the previous 24! I want them all to work. Identically.

- Art, real art, spontaneous, from-deep-down-inside art, is well-nigh impossible to teach. You've either got it or you haven't. And there aren't that many people who have it. There's a big difference between draughtsmanship and painting. Oh they might both need to understand perspective etc, but one understands and is bound by rules while the other can choose whether to accept them or not. I want my machinery and processes to know the rules and obey them, not to become all creative when they get the urge. So give me someone who regards PLC programming as an engineering discipline, please. I don't want to inherit more ladder logic as conceived by Jackson Pollock.

- Finally, you usually can't tell an artist what to produce. In detail. You may commission a portrait but who knows what it will look like until it's finished. Again, I want someone who does a job of translation, not creation. Here's my intentions, here's what I want, specifically, now go and make it so.

There's absolutely nothing wrong with holding our collective heads up as programmers and being proud of the roles we perform, but why stoop to being an artist when you can be an engineer?

Ken
 
Well said Ken, I agree with most of what you say. However, I would support Terry on one point. In my opinion good programmers (and I'm not one) are extremely creative people. To be able to start with a blank sheet of paper and then plan a well organised and coherent program is something which never ceases to amaze me. It's this process of synthesis, this way of thinking, that is a hallmark of a good programmer.

Which is probably why I'll never be a good programmer. Even if I say it myself, I reckon I'm a pretty good troubleshooter and I put it down to the fact that I'm pretty good at analytic thinking (during the "milk round" when I left uni in '66, I managed to complete the IBM test without any mistakes). But that's the art of taking things apart - exactly the opposite of what a good programmer does. As a result my programs tend to develope as I work on them. All sorts of ideas will pop into my head while I'm programming which I can never just conjure up out of thin air. This also means that most of the structure has to be imposed afterwards - if I have enough time! On the other hand, I do make sure I document everything very thoroughly.
 
Extracted from http://www.m-w.com/cgi-bin/dictionary

Function: noun
1 : skill acquired by experience, study, or observation <the art of making friends>
2 a : a branch of learning: (1) : one of the humanities
3 : an occupation requiring knowledge or skill <the art of organ building>
4 a : the conscious use of skill and creative imagination especially in the production of aesthetic objects;


Note that it isn't until the fourth definition that we get into the realm of aesthetics and the fine or performing arts.

I agree with Terry on this one, at least in terms of broad concepts and certainly in applying the term ART to good programming and automation system design.

When I was a young rookie engineer I thought one of the neat things about engineering was that it had right answers and wrong answers and was a discipline with structured approaches to problems.

Now that I am a crochety old engineer I realize that engineering, and programming, and any creative field for that matter, has a lot of art to it. At least if you are any good at it, that is. A well executed system design and program have aesthetic apeal. A well executed engineering drawing is also aestheticly appealing. There is a huge amount of creativity and innovative thinking in good programming, good operator interface design, and good engineering design.

And I disagree with those who think creativity in the "fine" arts is somehow harder or in some way superior to engineering creativity. After all, Hieronymus Bosch and M. C. Escher could draw anything they felt like. We have to make our creative efforts work within the laws of physics, the restrictions of economic systems, as well as the inherrent contrariness of human nature!
 

Similar Topics

Hello colleagues, Some time ago I started my adventure with programming. With your help and the courses, things are starting to come together...
Replies
13
Views
591
Dear All, I need a sample PLC program to count the output pulse of a mass flow meter so that a specific amount of mass (for example 100gm)can be...
Replies
2
Views
82
Hi Please I have zeilo smart relay #SR2A201BD but I don't have it's programming cable. Can I use any general usb/rs232 converter? Or need...
Replies
2
Views
79
Hi, Does anyone have thoughts or know of, can point in the right direction any published materials with a plumbing centric point of you explaining...
Replies
1
Views
125
@ All: what is your best guess on a potential range in increase in efficiency in % (i.e. saved programming hours, greater output, etc.) when...
Replies
5
Views
291
Back
Top Bottom