# Demarcation (was: STL x Ladder)

J

#### Jiri Baum

Bob Peterson:
> I personally avoid text based languages. I end up turning things over
> to electricians to maintain and they can handle RLL quite well.

Actually, this is an interesting question, on quite a different level:

Why should electricians fix programming problems, any more than fitters should change wiring or programmers tighten the bolts?

Certainly one person can do all three jobs, especially in small, simple installations. But where the size and/or complexity of the project warrant it, they should be separate jobs, with quite different qualifications.

Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools

J

#### Joseph Doty

I agree....

Electricians and Mechanics do not normally go to school to be programmers. Hence they do not think like one and end up creating problems.

Joe

B

#### Bob Peterson

Typically, electricians are not expected to fix programming problems, but they are expected to be able to debug problems, and to make temporary program changes, or to add minor bits of code as time goes by.

The reason this is done is that usually the electricians are the guys on the front lines and get their first when a problem happens. They are often well trained and well suited to this role and actually like it. A lot more interesting than pulling pipe and wire.

You want to get a programmer out of bed at 3 am and bring him into the plant to enter a temporary program change to get around some problem that developed??? Why not just train the guys that are already there to take care of it.

Bob Peterson

B

#### Bruce Durdle

Joseph and Jiri,

On the other hand ...

electricians are usually very familiar with the operation of the machinery being controlled - a programmer isn't. I would guess that a very large proportion of any machine control application involves simple ladder-type relationships - "If pressure is high AND timer has expired, stop the pump"
- which do not require the peculiar (in all senses of the word!) skills of a computer programmer.

Remember the whole original rationale for the PLC - as a replacement for the large relay panel. While the PLC has moved well beyond that point, the original problem remains. I could say that programmers go to school to learn how to write programs, and are usually aimed at the business end of the market at that (I am presently trying to get a modicum of plant computing introduced into the Bachelor of Applied Information Systems degree at the trechnical institute where I work). The subtleties of real-time programming and the need to take a close look at the properties of sensors and actuators when develoipoing applications are skills they have to pick up on the job - just as an electrician has to pick up some programming skills.

And is it going to be the programmer or the electrician who gets roused up at 3 am because the machine just tripped for the 4th time that night? An electrician is more likely to produce a program that is understood buy another electrician than is a programmer. Because the electrician has not had the exposure to all the subtle tricks that the programmer has, he/she is more likely to produce brute strength inelegant but obvious systems.

Bruce

J

#### Jiri Baum

Bruce Durdle:
> electricians are usually very familiar with the operation of the
> machinery being controlled - a programmer isn't.

I guess we need to make a distinction here between programmer-engineer and programmer-technician (we need better names for those).

> And is it going to be the programmer or the electrician who gets roused
> up at 3 am because the machine just tripped for the 4th time that night?
> An electrician is more likely to produce a program that is understood buy
> another electrician than is a programmer.

That's petitio principii - you're arguing that we need electricians to do it because we need electricians to be able to do it.

Would you call a mechanic or an electrician because the machine just tripped for the 4th time that night? How about if it started vibrating excessively?

Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools

J

#### Jiri Baum

> > Bob Peterson:
> > > I personally avoid text based languages. I end up turning things
> > > over to electricians to maintain and they can handle RLL quite well.

Jiri Baum:
> > Why should electricians fix programming problems, any more than fitters
> > should change wiring or programmers tigten the bolts?

Bob Peterson:
> You want to get a programmer out of bed at 3 am and bring him into the
> plant to enter a temporary program change to get around some problem that
> developed??? Why not just train the guys that are already there to take
> care of it.

Well, sure, you can train one of the guys already there - but admit they need training and give it to them.

Don't say we can't use programming feature X because we're going to have the wrong kind of technician maintaining it'', at least not as a general statement. (In particular situations it may well be warranted.)

Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools

D

#### Danrfull

No one makes a better programmer then the men in the trenches. I have seen way to many programs written by control engineers that are over
kill and very difficult to troubleshoot. In todays world you should be able to tune instruments,change motors, wire in new installations and program from scratch, entire control systems. If you cannot get your hands dirty, please take up banking.

R

#### rsewell

Bruce >Remember the whole original rationale for the PLC - as a replacement for the large relay panel. While the PLC has moved well beyond that point, the original problem remains. I could say that programmers go to school to learn how to write programs

The PLC has moved WAY beyond relay replacement, to the point that the original problem is heavily masked in most large PLCs by communications, sequential, and regulatory logic.

Bruce >The subtleties of real-time programming and the need to take a close look at the properties of sensors and actuators when develoipoing applications are skills they have to pick up on the job - just as an electrician has to pick up some programming skills.

Absolutely true, but there are many more electricians doing production equipment programming than compu-sci types, most who graduated with something quite different in mind. Electricians, I believe, likely do have the most suitable background to do PLC programming - if and only if - they do not go into it like they have nothing to learn beyond the instruction set. Those who honestly believe that a week at a vendor course qualifies them to take on a major project are the problem. Those who invest their own time on their own home computer, know where the computer section of the local bookstore, read the A-list, are self taught in basic or C, can be terrific as programmers. For whatever reasons - lack of interest - the plant runs them off their feet - whatever, many electricians do not attain required programming skills.

Bruce >Because the electrician has not had the exposure to all the subtle tricks that the programmer has, he/she is more likely to produce brute strength inelegant but obvious systems.

Programming skill lends to consistent, elegant AND obvious systems, the program should be as banal as at all possible. The challenge is that the programmer is called upon to implement controls which are themselves subtle and involved. Straightforward interlocks are not what separate the good programmers from the inept. We are not talking about a micro PLC controlling a sump here. Sequential control which can branch dynamically, pause, bypass, retrace, and have different operator permissions at different control stations, coordinated with other plant units as feed and discharge conditions change, and involve modulated variables and large IO count, can reach high levels of inherent complexity. Large programs of over a thousand rungs generally have some more involved sections. An experienced programmer will abstract and structure the problem and work from the desired functionality down. An electrician who has failed to come to grips with programming constructs will tend to write from the field device up. In a demanding application, the code will just grow more and more chaotic and less obvious to anybody, electrician or otherwise. Ultimately, the guy will probably get the equipment working and feel vindicated as a programmer, and who am I to judge. Never mind that the program has become a black box, not consistent with any sort of standard style, inaccessible to extension or alteration or operator interface enhancements.

Regards
Ron Sewell
Sigmatic Controls
Kelowna BC

M

#### Michael Griffin

Bob Peterson wrote:
>> I personally avoid text based languages. I end up turning things over to
>> electricians to maintain and they can handle RLL quite well.
>
At 16:56 19/12/01 +1100, Jiri Baum wrote:
<clip>
>Actually, this is an interesting question, on quite a different level:
>
>Why should electricians fix programming problems, any more than fitters
>should change wiring or programmers tigten the bolts?
>
>Certainly one person can do all three jobs, especially in small, simple
>installations. But where the size and/or complexity of the project warrant
>it, they should be separate jobs, with quite different qualifications.
<clip>

I believe that what Mr. Peterson is trying to say (he can correct me if I am wrong) is that for any really difficult trouble shooting problem, finding what is actually wrong (software, electronics, mechanical?) is most
of the work - fixing it is often relatively minor. It is rather rare that the true problem will be so kind as to leap out in front of you and introduce itself.

I believe that what Mr. Peterson is trying to say (he can correct me if I am wrong) is that for any really difficult trouble shooting problem, finding what is actually wrong (software, electronics, mechanical?) is most
of the work - fixing it is often relatively minor. It is rather rare that the true problem will be so kind as to leap out in front of you and introduce itself.

If the electrician cannot read the program, how can he determine that there even *is* (or isn't) a programming problem? After all, when he arrives at the machine all he generally has to work with is a non-functioning machine, and (if he's lucky) a confused account of what someone thought they saw.

It is for this reason that it is important that a program be readable - and to be readable by someone other than a full time programmer. If I write a new program, I only have to be able to read it once. The maintenance personnel who look after the machine may have to read it many times over the years.

Consider the following (rather common) situation. Suppose you have a machine where pallets travel down a conveyor to an elevator. A stop gate holds the pallets back until the elevator is ready to receive them. Every once in a while (say, a couple of times a week) an extra pallet seems to get into the elevator and jams it. Nobody actually sees it happen, they just see
the end result when they come over to see why the (fully automated) machine has stopped. Now from this information can you tell me if:

1) Is there are bad proximity sensor which is giving an intermittent signal? (electrical)
2) Do we have some other sort of wiring problem? (electrical)
3) Is the stop gate sticking in the down position, instead of returning after the pallet goes by? (mechanical)
4) Is the stop gate worn, or is the conveyor speed too high for the pallet weight, causing the occasional pallet to ride over the stop? (mechanical/mechanical engineering)
5) Is there some other sort of pneumatic problem? Say for example a dirty muffler causes feed back in the manifold pilot exhaust line which causes the pallet stop valve to occasionally actuate when another, unrelated
valve shifts? (mechanical)
6) And of course, is there some sort of bug in the program? (programming)

I have seen all of the above as causes for this or similar problems. Now can you tell me who we need to fix this problem? Do we need an
electrician, a millwright, or a programmer?

I don't know what sort of industries you have worked in, but all the companies I have had anything to do with expect their electricians to be able to do more than just pull the wires they are told to pull. They are expected to be able to get to the root of a problem and fix it, to implement small projects they are given, and to come up with quality and cost improvements - just like every other employee of the company, regardless of who they are.

**********************
Michael Griffin
**********************

B

#### Bruce Durdle

Hi Jiri,
I don't know what the situation is in Oz, but here at least most programmers go through the hands of the business/computing faculties - in fact, for most of this year I and a colleague, teaching what we call Industrial Electrotrechnology (basically the material covered by the Automation Group) have been tacked on to the end of the Business and Information Systems faculty. Their training is primarily in programming for business/accounting applications. While we could expect that this would translate across to the messy end of things, a lot of them have problems coming to grips with the hardware.

Electricians also have their hassles, and a lot of electricians have difficulty translating from the world of pulling 3-core 2.5 mm2 PVC and installing 3-pin plugs to the industrial world of 3-phase motors, and relay-based starters, let alone the more complex stuff we are talking about. However, I think that a good electrician is very pleased to get recognition as an industrial technician, whereas a good programmer will be either too expensive or too hard to find, and may well see moving in to the industrial end of the discipline as a retrograde step.

An electrician is also likely to approach the problem from the plant end, and look for problems in sensors and the plant, whereas a programmer is more likely to start playing with the software. (I've seen a software-inclined technician spend 3 days checking configurations and testing computer hardware looking for the source of a 20% excess of steam flow out vs water flow in to a boiler - the cause was eventually traced to a leak in the DP cell impulse piping).

Certainly in the organisations I have worked for or dealt with, shift or call-out electricians were expected to do everything at 3 am, and usually happy to get paid for it. Programmers are usually regarded as "staff" and overtime/call-out work is not well regarded. It is lilkely that an on-call electrician will be called out anyway, simply because of payment considerations.

Demarcation issues often cause major industrial problems at any change in technology, and perhaps this is the next area where these problems are likely to have to be faced up to.

Bruce.

J

#### Jiri Baum

Bruce Durdle:
> However, I think that a good electrician is very pleased to get
> recognition as an industrial technician, whereas a good programmer will
> be either too expensive or too hard to find, and may well see moving in
> to the industrial end of the discipline as a retrograde step.

Indeed it would be a retrograde step, as it would be for an electrical engineer to become an electrician.

> Demarcation issues often cause major industrial problems at any change in
> technology, and perhaps this is the next area where these problems are
> likely to have to be faced up to.

I guess that was my main point.

As long as electricians are expected to handle maintenance, design of software is hobbled to what electricians can pick up. To address this, maintenance of software might be handled separately, by a new kind of technician, or at least a new kind of technician's qualification.

Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools

T

#### Terry Sheehan

The key is to allow people to work with an application language that most closely matches there mind set, and not force people to be retrained to do someone else's job. If you think in terms of electrical flow, use Ladder.
If you think in terms of process flow, use Function Block Diagram. If you think in terms of decision flow, use Flow Chart. If textual programming makes sense, use Structured Text. Let the application and your experience dictate the language, not the language dictate you experience. Use a combination of languages together for applications that combine disciplines.

Jim Desrosiers
AlterSys

R

#### Richard Higginbotham

Funny, most (by far) the problems I've ever had to fix stemmed from electricians, techs, EEs etc. pretending to be programmers and botching it royally, (not that a "programmer" cant write pore code or anything). All in all, I know very few people who are "programmers" who work in the application side of automation. EEs, ChEs, etc. heck even SEs dont necessarily make the best programmers much less electricians.

Some people just shouldn't write code. Dont know why it works that way, but it seems to be one of those real world truths that can't be escaped. I wouldn't let myself do anything remotely complex that was mechanical or electrical. Its just not something that will ever be in my skill set.

As to the original question, why do some feel that electricans should do the programming... well, why should electricians be instrument techs? Why should we choose anyone do something they aren't qualified to do?

Well, probably, because they're cheaper.

Richard Higginbotham

Speaking for myself, and poorly

P

#### Paul Gruhn

Please note that there is a new ISA Safety Division with a Software Safety Subcommittee that will now be covering these very issues (related to instrumentation, controls & automation). Visit "www.isa.org/~safety":http://www.isa.org/~safety !

Paul Gruhn, P.E., C.F.S.E.
ISA Safety Division Director
[email protected]

T

#### Tim Davis

Why have an electrician fix a program?
becouse the machine is down!

lost production means lost revinue. I am a journeyman electrician but you wouldn't want me to bend any pipe for you. I consider myself a
troubleshooter first. I know my limits and would never edit someone's program without first understandding the programers original intent. I
can recall one slc500 program thet was a total mess- masked moves to a compare to set the " all selector switches in auto " bit. this type
program came from a " programmer " he is a professor in canada and had no idea how to wright an electrician friendly program. he also had a big attatude when he found out someone was in " his " program. when i left, the operator could pre-start the cycle after the parts were
loaded and the cycle time went from 24 sec. to 15 sec. ask this coustomer if they like electrician's programs.

The shift maintenence person is always the first guy on the scene. after a couple of hours, the phone starts to ring.

becouse i hold an electricians licence does that mean i tell my coustomers that they need the hydrolic tech when i find a sticky valve? not if i want to keep them as a coustomer! i get a valve and fix the problem.

just a few thoughts
great subject
Tim Davis

C

#### C. Nelson

From my experience the term "electrician" is a very broad term when it comes to the industrial production floor. Where I work different people in the department each have their own strengths, some running conduit and pulling wire, some troubleshooting the machinery, and programming. I agree that the "production electrician" has the best vantage point to be the best person to
programmer. He knows the machine better that anyone else.(the good ones do!)However...just because you have taken a course and know how to program in ladder logic doesn't mean you can program a project. Like I preach regularly...the hard part of programming a machine is knowing what you want the machine to do and knowing what components and sensors are on the machine that
you can use to make it happen. As far a the structure of the program is concerned...if a person has had to troubleshoot machines very many years, he realizes what it takes to make the program and documentation user friendly. I
have seen programs written by machine manufacturers that were very hard to read...
I have had no formal training on PLC's, and yet from years of troubleshooting have taught myself, first to read the program and then to write my own. IMHO I think the bottom line is some people will never be able to program well, because they don't have the apptitude to understand logical things, in the same manner some electricians are never good at troubleshooting machines, but can do
a fine job of installing them and hooking up the power. It's ironic to me why I have to work under a licensed electrician and he could no more do what I do than the "man on the moon" could.

V

Hello List,

Also there is another criteria.
We ought to keep in mind that different computer languages have different limits of complexity. The LD (aka Relay Logic) obviously can serve for simple algorithms only. So, there is the only justification for the Relay Logic - if there are a lot of _physical_ relays and there are no complex tasks in the plant. In the case the LD can both fulfil the task and reduce the complexity of the maintain.

C

#### Curt Wuollet

Hi All

I'm finding this fascinating. I have never met an automation type who was an electrician. Perhaps it's local custom, but most seem to come from the electronics arena or machine tools. I think it's a good thing to differentiate design and implementation from operation and maintenance. Very few electricians I've met would make much headway with some of my systems and it would not be fair to call them at 0330. I'd much prefer to get the call. It's a lot easier to troubleshoot before someone has started changing things or applying jumpers to "test" stuff. Probably a different situation than big industry. We don't have any electricians on staff. We call in outside folks for plant power wiring.

Regards

cww

--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned Industrial Automation Software For Linux. mat.sourceforge.net. Day Job: Heartland Engineering, Automation & ATE for Automotive Rebuilders.
Consultancy: Wide Open Technologies: Moving Business & Automation to Linux.

L

#### Luca Gallina

Hello all,

I think this will be a never ending thread if we don't focus on some points:

1. The final users
==================
There are industries (large or small) where electricians must be sort of wizards, other industries (mainly large ones) have electricians and programmers as distinct roles.

Some industries prefer internal personnel to solve all the problems, other industries rely on internal electricians and external programmers.

Some customers take a close look at the equipment they're buying, others simply don't, just look for cheap stuff without providing precise specs (and frequently end up with a plethora of different controller brands)

2. The applications
====================
There are applications where PLCs' scan lots of simple logic, other applications where common logic is 1% of the whole program.

There are applications where high performance is a must, others where performance requirements are pretty poor. In the first case, high performance and simplicity do not always join in marriage.

3. The money
============
A programmer is often asked to develop a program as fast as he can (..."the shipping is already overdue") or as cheap as he can (.."we're out of budget")

High-cost programmers do not ensure high software quality, but it's pretty likely that very-low-cost programmers lead to low quality programs. Nonetheless, customers often chose these last ones.

4. The programmers
===================
A true programmer will naturally pay attention to programming techniques and languages which allow the developing of solid programs in good, fast and cheap way.

True programming, despite of some easy-looking programming languages, is and remain a specialized sport. Programming is not just "instructions", programming is also software planning and optimization.

A true programmer (believe it or not) is the first person who wants a rational, neat, easy to maintain program. He *does* know that if a machine/plant does not work, he's the first to be to blame. Freelance programmers usually have no escape: bad programming = no payment.

===================

So there are different views and different factors...
If you are a final user probably you'll pay attention to maintenance issues and program simplicity. If you're a developer you'll probably pay attention to innovative or advanced programming techniques.

We typed lots of words about programming, but my experience tells me that a good machine (good engineering, good mechanics, good wirings) ease the programming and needs little software maintenance. Poor initial engineering causes always many troubles (and many headaches). Perhaps instead of arguing on "Ladder vs. STL" we should look elsewhere...

best regards
Luca Gallina

B

#### Bruce Durdle

What we are trying to do here (I'm involved with writing qualifications for instrumentation workers) is meet the requirements by providing the relevant training for tradesmen on the one hand and expose the programmers and IT experts to instrumentation concerns on the other. We will hopefully have a post-trades level qualification in PLCs which gets a bit more deeply into proper programming techniques based on RLL and the other IEC formats and specifically deals with programming for industrial applications, and also giving some exposure to IEC61508. I'm finding a lot of interest in these topics from electricians who have been thrown off the deep end by their employers and want to get a better understanding.

Not so much from programmers who are having trouble getting to grips with the concerns of the industrial users though!

I think the site instrument/electrical techs here (who mostly have to start life as electrical apprentices because of our electrical wiring registration system) do a very good job. A couple of weeks ago I was teaching a group of site electricians who have just had their old 884 Modicon PLCs replaced with Quantums, and are having to come to grips with the full IEC set, as well as maintain their old programs written in 984 LL. Most of them seemed to be enjoying the challenge and could see the potential of the extra formats - for the right types of application.

I think it is probably easier to teach a motivated electrician what he/she needs to know about programming techniques for the relatively restricted set of tasks needed for industrial work than it is to teach a programmer what he/she needs to know about the electrical end. I can certainly rely on an electrician to deal with the non-programmed parts of a PLC system much more effectively than would a programmer. Unfortunately, "PLC programming" has too often consisted of Mr Allen-Bradley or Mr Modicon showing how to use his favourite programming terminal to put logic into the PLC, and nowhere near enough about how to decide what logic to put in.

Bruce.