PLC code standards

M

Michael Griffin

Bob Peterson wrote:
<clip>
> Mr. Peterson's main issue is badly written code. I really do not care much
> what method is used as long as it is consistent, works well, and has few
> gotchas. The worst programs I have had to fix generally seem to have an
> overabundance of latches in them, and inevitably there are a few somewhere
> in the code that don't get reset along the way, so things don't work quite
> right.
<clip>
I think I see your point. I believe however that bad programs tend to have an overabundance of a lot of things in them. The way the worst programs tend to come into being is when someone tries to fix a bad program by adding more stuff onto it instead of taking the bad parts out. If they can't add more latches though, they'll just add something else instead.

I once had to add a new feature to a machine. After several days I gave up trying to understand the existing program, and wrote a whole new one with the new feature in a few hours (it was a simple machine). My new program was one
eighth (1/8) the size of the original, but did more.
I regret having discarded the old program, as it made such a good example of a bad program. One feature of it which I recall rather well was a couple of pages of statement list full of jumps and obscure instructions which was basically equivalent to a single rung of ladder logic with a few contacts controlling an on-delay timer. The original program was written by an electrical engineer who worked as a programmer for a large machine builder, so it's not as if he was inexperienced.

> And I do believe in keeping the code as simple as possible. Occassionally,
> you have to program an algorithm that is not particularly simple. These
> are fairly rare in general purpose automation projects. Most of it is
> pretty simple stuff, just a lot of it. Break it down into managable
> chuncks and program that chunk. The worst part tends to be interlocks
> between the chuncks.
<clip>
It's really rather easy to write a large complex program, people do it all the time. Writing a simple program is what many people find difficult to do. This is what takes thought and experience.
I think that what you have described in the above is a much better guide on how to write a good program than a detailed list of "things to avoid" would be. Identifying various general things as bad practices doesn't mean you will end up with a good program. The things you are proscribing are the symptoms, not the causes of the problem. A good method used for the wrong thing still results in a bad program.

************************
Michael Griffin
London, Ont. Canada
************************
 
V

Vladimir E. Zyubin

Hello List,

I can not understand the specific of your kind of plants.

Software has a bit different nature comparing with hardware. It can not fault in manner of hardware. So you need just copy software if
your hardware is fault.

Why do electricians constantly write programs? If you have 10 identical machines, why do you have to change 10 times the same programs? What kind of causes do you have to do the changes? "something goes wrong"?
I suspect that it can be just a consequence of a bad discipline, chaos, when every electrician makes change in program. If it is a logic fault then the more cheap way to fix it is to do it by a competent programmer and with the proper
procedure (analysis of the docs -> finding the bug -> solution -> changes of the program -> testing of the program -> changes of the docs).
No other ways.

How many times do you get the faults? If it happens frequently then it is a sign of a (pardon) bad discipline on the plant, if it
happens rare - none of electricians can make qualified changes because of lack of the experience.

If there is a need of the flexible production line (the algorithm is changing frequently), the proper medicine is to get a proper software with adequate user interface that LIMITS the
boarders of the changes. I.e., again, I see no reasons for electrician-programmers in the LD. At a pinch, (if the proper soft is impossible) an algorithms library in the LD can help in the case of flexible production line. Again, the more cheap way is the discipline (qualified programmer, DB of program, docs, etc.) But again for what reasons do you need the LD in the case if there are more adequate tools (e.g. SFC)?

Please explain the situation. I can not imagine anything but a plant with one machine and one electrician (who combines jobs of programmer,
technician, engineer, manager and chief accountant).

--
Best regards,
Vladimir mailto:[email protected]
 
V

Vladimir E. Zyubin

Hello PETERSONRA,

[...]
PAC> And I do believe in keeping the code as simple as possible.
PAC> Occassionally, you have to program an algorithm that is not particularly simple.
PAC> These are fairly rare in general purpose automation projects.
PAC> Most of it is pretty simple stuff, just a lot of it.
PAC> Break it down into managable chuncks and program that chunk.
PAC> The worst part tends to be interlocks between the chuncks.

I believe that all automation projects is pretty simple stuff. Yes, sometimes they look like "not particularly simple", but just because the programmers do not use adequate linguistic means and have problems with the structuring.

--
Best regards,
Vladimir mailto:zyubin @iae.nsk.su
 
R

Ralph Mackiewicz

> Really, the choice is one of whether you wish to group together
> rungs which are related in terms of what the machine is doing, or
> whether you are grouping together rungs which are related in terms
> of the memory location used.

The really sad thing is that after all these years PLC programmers still have to worry about memory locations.

Regards,
Ralph Mackiewicz
SISCO, Inc.
 
B
Vladimir Zyubin wrote:

> I can not understand the specific of your kind of plants.
>
> Software has a bit different nature comparing with hardware. It can
> not fault in manner of hardware. So you need just copy software if
> your hardware is fault.
>
> Why do electricians constantly write programs? If you have 10
> identical machines, why do you have to change 10 times the same programs?
> What kind of causes do you have to do the changes? "something goes wrong"?
> I suspect that it can be just a consequence of a bad discipline, chaos, when every
> electrician makes change in program. If it is a logic fault then the more
> cheap way to fix it is to do it by a competent programmer and with the proper
> procedure (analysis of the docs -> finding the bug -> solution ->
> changes of the program -> testing of the program -> changes of the docs).
> No other ways.

It appears you have no experience in a large working plant. They are amorphous critters that are difficult to define exactly and are constantly changing as small (and not so small) improvements are made. Machines are rarely identical. Similar perhaps, but rarely identical, except for lower level machinery like lathes, and these type of machines typically require little in the way of reprogramming.

> How many times do you get the faults? If it happens frequently
> then it is a sign of a (pardon) bad discipline on the plant, if it
> happens rare - none of electricians can make qualified changes because
> of lack of the experience.

Most large plants have electricians who are quite capable of making these types of changes. They are well skilled and trained to do so. Perhaps you are unacquainted with the typical skill level of elctricians on the floor at large US factories. They might be better described as control technicians rather then electricians since very few of them spend much of their time pulling wire or bending pipe. Virtually all of their time is spent maintaining, repairing, and upgrading the machine control systems. In a pinch they do traditional electrician tasks as well, but that is usually a small part of their jobs.

> If there is a need of the flexible production line (the algorithm
> is changing frequently), the proper medicine is to get
> a proper software with adequate user interface that LIMITS the
> boarders of the changes. I.e., again, I see no reasons for
> electrician-programmers in the LD. At a pinch, (if the proper soft
> is impossible) an algorithms library in the LD can help in the case of
> flexible production line. Again, the more cheap way is the discipline
> (qualified programmer, DB of program, docs, etc.) But again for what reasons do
> you need the LD in the case if there are more adequate tools (e.g. SFC)?

SFC works Ok for some very limited purposes but rapidly becomes unreadable for others. Most general purpose automation is not all that complex. The simpler instructions can easily cover the vast majority of situations. If its a complex problem, its not likely the electricians would even attempt to implement it themselves anyway. They are pretty good are knowing their limits, something many engineers seem to have problems with.

> Please explain the situation. I can not imagine anything but a plant
> with one machine and one electrician (who combines jobs of
> programmer,
> technician, engineer, manager and chief accountant).

Consider that a factory is almost a living thing, in that it is in a constant state of change and growth. Trying to nail down every possible contingency during the design phase is flat out impossible. As you run machinery or processes you learn about it, and come up with things that can be done to improve it. In fact, its not unusual for machinery to have yearly upgrades along with the constant little improvements that are done. A lot of the smaller improvements are done to alleviate operator stress. Having to manually operate things on a continual basis is annoying. Many times it is easy to automate such things. At the design phase it was thought "less expensive" to not automate it, but the operator ends up with monotonous tasks that could be greatly simplified, so some money is appropriated for parts and a task is simplified.

often these small improvements are things done because during the design phase certain decisions were made. A typical decision might be made based on the idea that an operator is in constant attendance and can respond to an alarm or out of spec situation. this often turns out not to be the case, and assigning an operator to stand around and press the alarm reset button is not very efficient anyway.

A lot of this stuff is hard to explain to people with no real experience in large scale manufacturing operations, so I can understand your difficulty in that respect.

Bob
 
Ah...another example of all pegs fit into my holes..........I happen to be one of those trumped up techs.......I have built complete machines and complete factories from scratch doing all of the PLC programming all of the
HMI design, all of the "Engineering" and all of the ERP integration and equipment setup.

Am I perfect no, not at all but I will compare my code writing ability to anyone in our plant and also to yours..........I have been doing this for a long time, have read just about every book on the topic, worked with just about a thousand different vendors, engineers, Masters degree's personnel, and plant floor people and have seen many "programming styles" and one thing
I can guarantee you............"You cannot judge a book by its cover".

As has been said, there are extremely good Engineers and horse sh** Engineers, extremely good lowly Electricians/Instrument people and horse sh** ones. I can tell by your snobbish attitude that you probably fall into the later just for your ignorance of the profession you claim to excel in.

An example that I just love to quote came from an Employee where I work, this particular person was a process engineer with what I consider very little experience probably at the time 5 years or less. There was another person I will call Sam who had 40 years in the plant, had never gone to "school" for in this case papermaking but had worked every job from the
bottom to the top person on our top "high tech" line. This "green" person made a comment to me one time about how "Sam was pretty sharp for an
uneducated man".......I literally took 3 steps back and looked him straight in the eye and informed him that Sam had more "schooling" than all of us combined through the school of being there". He still did not get it......................

An Electrical Engineer leaves school with only knowledge that was good that day in this fast paced changing technological world..........I always say I want the guy who I can hand a box of lawnmower parts to and tell him to put
it together without any instructions......I will take that person over most as he has the ability to learn and think on his own and has what I consider to be the most important skill of all "troubleshooting skills" which I see very rarely and even more rarely from fresh out of school people........

Learning is life long and those who think they know it all because they hold a particular piece of paper or have been there for 10 years or are owed something, need to experience to quote a good book title that "their cheese has been moved" (Who moved my cheese).............

Wake up and quit putting people into boxes and you will go farther and get far more work................Your kind of attitude is the same as the old IT person who thought he was the most important mainframe cog and would never
have to look for work.........a modern dinosaur.

DAVCO Automation
"The Developing Automation Value Company"
 
V

Vladimir E. Zyubin

Programmer ought to think in terms of algorithm, purpose functions...
coders think in terms of memory areas, registers, interrupts, datatypes...
 
M

Michael Griffin

> Software has a bit different nature comparing with hardware. It can
> not fault in manner of hardware. So you need just copy software if
> your hardware is fault.

Not exactly. Sometimes you have to change the software to accomodate the way you fixed the hardware. Fixing the problem doesn't necessarily mean the machine is exactly the same as it was before. This isn't always possible or desirable. Making it the same as it was before may not fix anything.

> Why do electricians constantly write programs?
<clip>

Very simple, the original program may never have been correct to begin with. This isn't unusual with one-off machines. There was an earlier discussion concerning the need for better engineering practices for software design in automation projects, so this shouldn't come as a revelation to you.
In addition as others have pointed out, any good factory conducts continuous improvement projects. If the electrician is competent enough to find the root cause of and fix the sort of problems they are expected to deal with, then they should be more than competent enough to undertake the various minor improvement projects which are assigned to them.


--

************************
Michael Griffin
London, Ont. Canada
************************
 
B
> Ah...another example of all pegs fit into my holes..........I happen to be
> one of those trumped up techs.......I have built complete machines and
> complete factories from scratch doing all of the PLC programming all of the
> HMI design, all of the "Engineering" and all of the ERP integration and
> equipment setup.

Must have been awful small factories. :) I have spent a thousand man-hours on a single machine, and most plants have a lot more then one machine.

> Am I perfect no, not at all but I will compare my code writing ability to
> anyone in our plant and also to yours..........I have been doing this for a
> long time, have read just about every book on the topic, worked with just
> about a thousand different vendors, engineers, Masters degree's personnel,
> and plant floor people and have seen many "programming styles" and one
> thing
> I can guarantee you............"You cannot judge a book by its cover".

If you are trying to suggest that there is a rare case where a plant floor electrician can write better code then I can, I would bet you are right. The general case just isn't that way though, at least not from what I have seen. And I have been in a lot of different plants over the years. I also agree that many engineers also write really bad code. I have made a lot of money for the company fixing such code.


... rant about experience versus education clipped ...


> > I have a lot of experience with end user electricians. I have
> > not run across any "excellent" programmers, in fact the code they
> > write is usually pretty awful. What they are often
> > extraordinarily good at is understanding the machine and knowing
> > what it takes to keep it running. I am often amazed at how
> > clever they are in this respect. But there is a huge difference
> > between tweaking an existing piece of code to improve/fix/upgrade
> > it, and sitting down to write a significantly sized PLC program
> > from a blank piece of paper.
> >
> > Bob Peterson

I stand by what I have said. I have run across a lot of code written by plant electricians. Most of the short snippets (short = < 50 rungs) are OK. Anything substantially sized usually isn't. As you can tell from my original comments, I am quite in awe of how well they understand the machines and how it fits into the rest of the plant, far better then I do. There is still a huge, huge difference between tweeking, upgrading, and maintaining existing code and writing anything substantial from scratch.




Bob Peterson
 
B
... and a control systems engineer has to think in terms of what needs to be done to make the process work as required - whether this be software, hardware, pneumatics, hydraulics, of the Armstrong method.
 
V

Vladimir E. Zyubin

Hello Michael,

Michael Griffin wrote:

MG> On July 19, 2002 12:31 am, "Vladimir E. Zyubin" wrote:
MG> <clip>
>> Software has a bit different nature comparing with hardware. It can
>> not fault in manner of hardware. So you need just copy software if
>> your hardware is fault.

MG> Not exactly. Sometimes you have to change the software to accomodate the way
MG> you fixed the hardware. Fixing the problem doesn't necessarily mean the
MG> machine is exactly the same as it was before. This isn't always possible or
MG> desirable. Making it the same as it was before may not fix anything.

Yes. Agreed: if we _modificate_ hardware then we have to correct software. But I spoke about the repairing. MTBF(MTTF) is inapplicable to
software. Reliability of software has a differ nature. Correction of a program is needed if there is errors in the program. When all errors
are fixed there is no reason to touch the codes. NEVER. The soft is an eternal thing... just information. Nobody can destroy information, we
can destroy information carrier only. And so on...

>> Why do electricians constantly write programs?
MG> <clip>

MG> Very simple, the original program may never have been correct to begin with.
MG> This isn't unusual with one-off machines. There was an earlier discussion
MG> concerning the need for better engineering practices for software design in
MG> automation projects, so this shouldn't come as a revelation to you.

If I correctly undrestand your words, you say that it is impossible to write a complete program... Hm.. I am sorry, I miss the proof of the statement. But rather there is no any proof. As much as I can imagine it was a faith in progress draped in pathetic words, so called progressivism. (But according to the list I see the industry crys: we need no upgrades, hard/soft changes bring a headache only! (see USB-RS232 problem, MS-glitches, etc.))

You are right, the reason to rewrite the program could be hardware changes... or software changes (if we keep in mind the recidivists from MS :). But it is the only reason. And it is specific changes... so called PORTING... Porting does not touch the algorithm... And so on...

MG> In addition as others have pointed out, any good factory conducts continuous
MG> improvement projects. If the electrician is competent enough to find the root
MG> cause of and fix the sort of problems they are expected to deal with, then
MG> they should be more than competent enough to undertake the various minor
MG> improvement projects which are assigned to them.

Perhaps it is the main difference in our points of view. As I see you speak about continous improvement... IMO, any improvement is a little revolution. It is an investment: proposition -> research (economic culculation) -> plan of introduction -> changes (investment) -> result in return... The result of any improvement must be an increase the efficiency of production... i.e., profits in percents... AFAIK, the threshold level of profits in engineering industry is about
10% a year... about 10 cents a dollar. In computer industry is about 15-20% a year... (for every industry the numbers are different) If the profit is less then the improvement must be rejected.... because such a change is not lucrative.

Are there many improvements that satisfy the criterion? It is a big question.

--
Best regards,
Vladimir mailto:[email protected]
 
V

Vladimir E. Zyubin

Hello PETERSONRA,

On Saturday, July 20, 2002, 12:34:36 AM, Bob Peterson wrote:

PAC> In a message dated Fri, 19 Jul 2002 10:31:18 +0600, Vladimir Zyubin writes:

>> I can not understand the specific of your kind of plants.
>>
>> Software has a bit different nature comparing with hardware. It can
>> not fault in manner of hardware. So you need just copy software if
>> your hardware is fault.
>>
>> Why do electricians constantly write programs? If you have 10
>> identical machines, why do you have to change 10 times the same programs?
>> What kind of causes do you have to do the changes? "something goes wrong"?
>> I suspect that it can be just a consequence of a bad discipline, chaos, when every
>> electrician makes change in program. If it is a logic fault then the more
>> cheap way to fix it is to do it by a competent programmer and with the proper
>> procedure (analysis of the docs -> finding the bug -> solution ->
>> changes of the program -> testing of the program -> changes of the docs).
>> No other ways.
>>

PAC> It appears you have no experience in a large working plant. They
PAC> are amorphous critters that are difficult to define exactly and are
PAC> constantly changing as small (and not so small) improvements
PAC> are made. Machines are rarely identical. Similar perhaps, but
PAC> rarely identical, except for lower level machinery like lathes,
PAC> and these type of machines typically require little in the way of
PAC> reprogramming.

Yes. You are right. I have no experience with the plants you describe... and I have no idea what is the industry you deal with. The picture differs from both the plants I saw and the idea of mass production I had before...

BTW, the industry you speak about has to have problems with efficiency of production... (to be short - the constantly "improvements" can not allow to do something useful to sell)

>> How many times do you get the faults? If it happens frequently
>> then it is a sign of a (pardon) bad discipline on the plant, if it
>> happens rare - none of electricians can make qualified changes because
>> of lack of the experience.
>>

PAC> Most large plants have electricians who are quite capable of making
PAC> these types of changes. They are well skilled and trained to do so.
PAC> Perhaps you are unacquainted with the typical skill
PAC> level of elctricians on the floor at large US factories. They might
PAC> be better described as control technicians rather then electricians
PAC> since very few of them spend much of their time pulling
PAC> wire or bending pipe. Virtually all of their time is spent maintaining,
PAC> repairing, and upgrading the machine control systems. In a pinch they
PAC> do traditional electrician tasks as well, but that
PAC> is usually a small part of their jobs.

Very expensive aproach.. IMO... Multi-trained specialists are very expensive... or you will have two half-specialists in one. It is expensive as well.

How many electricians do you have per a machine in the industry? "maintaining, repairing, upgrading"... What are the percents of working
time in the industry? MTTR? mean-time-to-repair?

For the industries I aware of, a hard/software failure is a state of emergency. The stuff deal with only maintaining... planed maintaining,
PID-loop adjustment, precautions, etc. Alas, upgrading is rare economic effictive... So, it is a kind of an emergency as well. :)

>> If there is a need of the flexible production line (the algorithm
>> is changing frequently), the proper medicine is to get
>> a proper software with adequate user interface that LIMITS the
>> boarders of the changes. I.e., again, I see no reasons for
>> electrician-programmers in the LD. At a pinch, (if the proper soft
>> is impossible) an algorithms library in the LD can help in the case of
>> flexible production line. Again, the more cheap way is the discipline
>> (qualified programmer, DB of program, docs, etc.) But again for what reasons do
>> you need the LD in the case if there are more adequate tools (e.g. SFC)?

PAC> SFC works Ok for some very limited purposes but rapidly becomes
PAC> unreadable for others. Most general purpose automation is not all
PAC> that complex. The simpler instructions can easily cover the
PAC> vast majority of situations. If its a complex problem, its not likely
PAC> the electricians would even attempt to implement it themselves anyway.
PAC> They are pretty good are knowing their limits,
PAC> something many engineers seem to have problems with.

For most cases the SFC-like descriptions allow us to speak in an unified language.... in the language that is adequate to the tasks. The LD'
expression means are not adequate to the task.
Yes, there are simple tasks we can cover with the DEC, JZ instructions... But, alas, simple expression means do not lead to success fulfilment of task.

(I speak not about SFC a la the IEC 1131-3, when I write "SFC" I speak about the ISO 1028)

>> Please explain the situation. I can not imagine anything but a plant
>> with one machine and one electrician (who combines jobs of
>> programmer,
>> technician, engineer, manager and chief accountant).

PAC> Consider that a factory is almost a living thing, in that it is
PAC> in a constant state of change and growth. Trying to nail down every
PAC> possible contingency during the design phase is flat out
PAC> impossible. As you run machinery or processes you learn about it, and
PAC> come up with things that can be done to improve it. In fact, its not
PAC> unusual for machinery to have yearly upgrades along
PAC> with the constant little improvements that are done. A lot of the
PAC> smaller improvements are done to alleviate operator stress. Having
PAC> to manually operate things on a continual basis is
PAC> annoying. Many times it is easy to automate such things. At the
PAC> design phase it was thought "less expensive" to not automate it, but
PAC> the operator ends up with monotonous tasks that could be
PAC> greatly simplified, so some money is appropriated for parts and a task is simplified.

PAC> often these small improvements are things done because during
PAC> the design phase certain decisions were made. A typical decision
PAC> might be made based on the idea that an operator is in constant
PAC> attendance and can respond to an alarm or out of spec situation.
PAC> this often turns out not to be the case, and assigning an operator
PAC> to stand around and press the alarm reset button is not very
PAC> efficient anyway.

PAC> A lot of this stuff is hard to explain to people with no real
PAC> experience in large scale manufacturing operations, so I can
PAC> understand your difficulty in that respect.

Yes, you are right. I never see such a plant... a zoo of machines, lack of liability, lack of discipline, lack of economic background for
the changes. Sorry, what is the industry you speak about? if you are not kidding, of course. Or perhaps I do not understand your words
correctly and have had image of an ominous uncontrollable conglomeration that evolves in unknown direction.

--
Best regards,
Vladimir
 
B
In a message dated Mon, 22 Jul 2002 21:13:49 +0600, Vladimir Zyubin writes:

> Yes. You are right. I have no experience with the plants you
> describe... and I have no idea what is the industry you deal with. The pictire
> differs from both the plants I saw and the idea of mass production I
> had before...
>
> BTW, the industry you speak about has to have problems with
> efficiency of production... (to be short - the constantly "improvements"
> can not allow to do something useful to sell)

Actually, they are very common. This is the norm for large US plants. The idea is constant improvement. And for the most part it works.

> Very expensive aproach.. IMO... Multi-trained specialists are very
> expensive... or you will have two half-specialists in one. It is
> expensive as well.

Its not so much that trained specialists are not useful, its that they are expensive and uncommon. Its a lot like having a brain surgeon apply a bandage when it could be as easily done by someone with a few hours of first aid training.

> How many electricians do you have per a machine in the industry?
> "maintaining, repairing, upgrading"... What are the percents of working
> time in the industry? MTTR? mean-time-to-repair?

Typically, I would say there are multiple elctricians per shift per area of most plants, depending on size of course. The car plants I am most familiar with have perhaps a half-dozen electricians on at a time, that are typically responsible for perhaps 500-1000 PLC or CNC controlled machines/systems.

> For the industries I aware of, a hard/software failure is a state of
> emergency. The stuff deal with only maintaining... planed maintaining,
> PID-loop adjustment, precautions, etc. Alas, upgrading is rare
> economic effictive... So, it is a kind of an emergency as well. :)

Upgrading here in the states is considered a critical part of staying competitive. There is also the planned maintenance as well.

> PAC> Consider that a factory is almost a living thing, in that it is
> PAC> in a constant state of change and growth. Trying to nail down every
> PAC> possible contingency during the design phase is flat out
> PAC> impossible. As you run machinery or processes you learn about it, and
> PAC> come up with things that can be done to improve it. In fact, its not
> PAC> unusual for machinery to have yearly upgrades along
> PAC> with the constant little improvements that are done. A lot of the
> PAC> smaller improvements are done to alleviate operator stress. Having
> PAC> to manually operate things on a continual basis is
> PAC> annoying. Many times it is easy to automate such things. At the
> PAC> design phase it was thought "less expensive" to not automate it, but
> PAC> the operator ends up with monotonous tasks that could be
> PAC> greatly simplified, so some money is appropriated for parts and a task is simplified.
>
> PAC> often these small improvements are things done because during
> PAC> the design phase certain decisions were made. A typical decision
> PAC> might be made based on the idea that an operator is in constant
> PAC> attendance and can respond to an alarm or out of spec situation.
> PAC> this often turns out not to be the case, and assigning an operator
> PAC> to stand around and press the alarm reset button is not very
> PAC> efficient anyway.
>
> PAC> A lot of this stuff is hard to explain to people with no real
> PAC> experience in large scale manufacturing operations, so I can
> PAC> understand your difficulty in that respect.
>
> Yes, you are right. I never see such a plant... a zoo of machines, lack
> of liability, lack of discipline, lack of economic background for
> the changes. Sorry, what is the industry you speak about? if you are
> not kidding, of course. Or perhaps I do not understand your
> words
> correctly and have had image of an ominous uncontrollable
> conglomeration that evolves in unknown direction.

Hardly a zoo, but cetainly a controlled chaos. It sometimes amazes me how well it works. And trust me on this, they never forget the economic side of things. They do not change things just to spend the money. Its for a good reason.

Often its because equipment has become obsolete or is old and needs replacing with something more modern so it can be maintained. The old stuff still works, but its been there 10 years and spares are hard to come by. Consider that the net margin on a single SUV to GM is something close to $10,000. And one comes off the line about every 60 seconds. In that environment, you do whatever it takes to keep the line going, even if it means making a judgement that its better to replace some older, but still servicable equipment for some thing more modern and maintainable.

Bob
 
V

Vladimir E. Zyubin

Hello PETERSONRA,

On Monday, July 22, 2002, 8:35:58 PM, Bob Peterson wrote:

Pac> Actually, they are very common. This is the norm for large US plants.
Pac> The idea is constant improvement. And for the most part it works.

Just a remark:
IMO, it is bad defined idea. Not all improvements must be implemented. Only economic effective improvements ought to be implemented (it is an other topic, so I shut up here)

Return to the electricians:
It seems to me it is impossible to constantly improve 60-rungs LD program... ("60" is according to your data). It indicates that something is wrong in the concept.

<clip>
Pac> Its not so much that trained specialists are not useful, its that
Pac> they are expensive and uncommon. Its a lot like having a brain
Pac> surgeon apply a bandage when it could be as easily done by
Pac> someone with a few hours of first aid training.

Electricians constantly rewriting small programs indicate that we deal with the opposite case: nurses are trying to carry out a trepanation of the skull.

<clip>
Pac> Typically, I would say there are multiple elctricians per shift per
Pac> area of most plants, depending on size of course. The car plants I
Pac> am most familiar with have perhaps a half-dozen
Pac> electricians on at a time, that are typically responsible for perhaps
Pac> 500-1000 PLC or CNC controlled machines/systems.

The number is not too bad to pass out. It is a very good number at the first glance at least.

Just one question:
Do your electricians really program the CNC machine tools in the LD?
Our electricians (we call them "operators") program CNC machines in ISO-7, G-functions. AFAIK, It is a world wide practice... Please have
a look at COSCOM, FACIT, FANUC, GNT, MAHO, OLIVETTY CNC machine tools.
It is a language that allow the operators think in terms "rotate", "move", "repeat frame", etc. It is more productive... IMO.

In our industry (single crystal growth) the vendors never allow the operators to correct the algorithms. It will lead to disaster... There is a problem of liability. The vendors just provide an HMI interface in manual mode. In human-oriented terms of open/close valves, etc... with various level of complexity of commands... with continuous checking of a lot of disastrous situations... Or we provide the functioning without operators at all in auto mode...
according to a program that created by technologist... program is described in a specific language as well... within strict borders of flexibility... the language is oriented on the tasks the technologist do. It reduces the complexity of the system. It prevents human deaths.

CNC machine tools are very dangerous things as well as the growth furnace. Is there a problem of reliability/liability in your industry? I read sometimes CNC machines tore off the operators' heads... The LD is an absolutely inadequate linguistic means for CNC machine tools. I speak it as a brain surgeon: the more inadequate tools the more possible misfortune.

<clip>
Pac> Upgrading here in the states is considered a critical part of staying
Pac> competitive. There is also the planned maintenance as well.

Economic efficiency is the only criterion to do any change. Before to do a change a calculation must be made. If the return is less than 10 cents per a dollar of the investment per a year, then the change must be rejected. ("10 cents" is the threshold limit for the motor-car industry, AFAIK). I am afraid to disappoint you but any other strategy looks like a Las-Vegas and leads to the ruin.

[...] <clip>
Pac> Hardly a zoo, but cetainly a controlled chaos. It sometimes amazes
Pac> me how well it works. And trust me on this, they never forget
Pac> the economic side of things. They do not change things just to
Pac> spend the money. Its for a good reason.

But there must be a special department on the plant... department that rules... a special procedure to make the decision... specialist that
can make the calculation... Puzzled.

Pac> Often its because equipment has become obsolete or is old and needs
Pac> replacing with something more modern so it can be maintained. The old
Pac> stuff still works, but its been there 10 years and
Pac> spares are hard to come by. Consider that the net margin on a single SUV
Pac> to GM is something close to $10,000. And one comes off the line about
Pac> every 60 seconds. In that environment, you do
Pac> whatever it takes to keep the line going, even if it means making a judgement
Pac> that its better to replace some older, but still servicable equipment
Pac> for some thing more modern and maintainable.

Yes. It is foolish enough for me to criticise an approach that works in practice. But something looks very strange to me. Definitely I have to
think about the info you kindly provide. Maybe here we deal with the global economy effects... Stock exchange, speculation, agiotage, fictitious
capital, pyramidal schemes... The effects can allow industry to look alive when in fact the industry is dead. But I am not sure, of course...

--
Best regards,
Vladimir mailto:[email protected]
 
M

Michael Griffin

On July 22, 2002 12:01 pm, "Vladimir E. Zyubin" wrote:
<clip>
> Yes. Agreed: if we _modificate_ hardware then we have to correct
> software. But I spoke about the repairing. MTBF(MTTF) is inapplicable to
> software. Reliability of software has a differ nature. Correction of a
> program is needed if there is errors in the program. When all errors are
> fixed there is no reason to touch the codes. NEVER. The soft is an
> eternal thing... just information.
<clip>
I was talking about repairing as well. Sometimes you have to modify the machine in order to repair it. When you go to fix the machine, you may find that you can't get the exact same part anymore - it has gone obsolete, or it takes too long to get but you may have something else which will work. The replacement part or device may not work exactly the same way as the previous one. Or perhaps the replacement part is simply going to break the same way the original one did unless you change what you are doing. So in order to fix
the machine, you may have to modify it slightly.

As for "when all software errors are fixed", that may take a long time, perhaps forever. Many difficult errors require an unlikely combination of events to cause them to occur. This means that normal acceptance testing is unlikely to find them. However, "unlikely" is not the same as "random". The combination of events which triggers the error may suddenly occur repeatedly (possibly due to production lot variation) and need to be fixed right away.

Problems with a machine program tend to be most frequent early in its life (or after a major retro-fit), and tail off as they are discovered and fixed. You may gradually approach the ideal of a "perfect" program, but are unlikely to achieve it right away.

<clip>
> If I correctly undrestand your words, you say that it is impossible to
> write a complete program... Hm.. I am sorry, I miss the proof of the
> statement. But rather there is no any proof.
<clip>
I won't say it is impossible to write a "perfect" program, but it is difficult to do so. In addition, we are not talking about just software, but a complete machine "system". Interactions between hardware and software also
occur.
In many cases, the original programmer was working with incomplete or incorrect information about how the machine systems were supposed to work. Mechanical and electrical designers are not perfect either, yet the software must be based on their work. I believe that you would agree that it is not feasible for even the best programmer to write a "correct" program based on incorrect information.

> Perhaps it is the main difference in our points of view.
> As I see you speak about continuous improvement... IMO, any improvement is
> a little revolution. It is an investment: proposition -> research
> (econiomic culculation) -> plan of introduction -> changes
> (investment) -> result in return...
> The result of any improvement must be an increase the efficiency of
> production... i.e., profits in percents...
<clip>
> Are there many improvements that satisfy the criterion? It is a big
> question.
<clip>

No, some continuous improvements are dictated by the customer and are not subject to economic return calculations, at least this is the case in the automotive parts industry. For example, suppose you produced a defective part
and this part was shipped to the customer. The customer will then require you to take immediate action (including changes to machinery if necessary) which will prevent this problem from ever happening again. These sorts of changes
typically involve adding a sensor to detect missing or defective parts, or making a measurement, or some other such thing.
You may of course argue that these problems should have been forseen and prevented to begin with. However as I said above, the mechanical and electrical designers are not perfect either. The programmer can only work
with what information and devices he has available to him.

In addition to the above, there are many improvements which are the result of employee suggestions which are relatively inexpensive to implement. The cost of adding a sensor or valve to help keep a feeder track from jamming are
typically very small compared to the down time saved.
You have to be careful to not over-analyse a problem. The information to base these judgements on is normally uncertain and incomplete. You could easily spend more money (in manhours) "proving" a change is not economic,
than it would have cost you to simply do it.

************************
Michael Griffin
London, Ont. Canada
************************
 
M

Michael Griffin

On July 23, 2002 02:44 pm, "Vladimir E. Zyubin" wrote:
<clip>
> In our industry (single crystal growth) the vendors never allow the
> operators to correct the algorithms. It will lead to disaster...
> There is a problem of liability. The vendors just provide an HMI
> interface in manual mode.
<clip>
> It prevents human deaths.

In most assembly industries, the consequences of an incorrect program are at most a financial disaster (poor productivity, high scrap rate, or even worse - bad parts sent to the customer), but not a dangerous physical one. The safety systems should be normally independent of the PLC, so you may create a program which operates poorly, but it shouldn't be dangerous. You design the safety systems with the assumption that the PLC (software or hardware) will at some point not function correctly.
In the province where I live, the law is that you must have a qualified engineer review the safety design of the machine and approve it (this is almost always done by consulting firms - not by the machine builder or customer). You don't *want* your normal PLC control system to be part of the safety system, since this would limit your ability to change the program.

Most assembly machines in the automotive parts industry are custom built for each application. Each machine is unique, or at most a very few are built. Also, they are generally designed and built in a short period of time (a few months). This means that the engineering time devoted to design and testing is limited for economic reasons. Testing is also often limited because the number of parts available for testing is very limited (there can be a long chain of supplier dependencies involved).
A further complication is that the ultimate customer for the product being built (the auto company) is busy changing the design of their car while you are trying to build the machine which is going to make the parts being redesigned. Building the assembly machinery is just one small part of a very large and dynamic project - the car itself.
The above also means that the people who are expected to maintain the equipment are typically working with machines which have not been properly tested, and whose design is subject to change as time goes on. Although it is seldom admitted, the maintenance personnel are expected to be able to make up for some of the deficiencies in the engineering process by handling the residual "bugs" on the spot as they are discovered.

The ideal for a manufacturer in this business (as well as various others) is to be as flexible as possible, and to be able to respond to changes as quickly as possible. Speed of response and flexibility are just as important as efficiency. There is increasing emphasis on flexibility as product life cycles are getting shorter, and there is a proliferation of special models and versions being produced.

You can see that the above is different from being able to buy a standard machine produced by the hundreds or thousands whose manufacturer has had years to work all the bugs out and perfect it. We have some machines like that, and yes, with those machines we seldom make any changes. These machines tend to be the exception though.

> But there must be a special department on the plant... department that
> rules... a special procedure to make the decision... specialist that can
> make the calculation... Puzzled.
<clip>
If the machine isn't running or runs very poorly, your biggest concern is going to be that you can't supply your customer. If you don't do something about that very quickly, you aren't going to have any business to calculate a
return on.
Realistically though, if you make an improvement to the machine which involves only $100 worth of hardware and it makes a noticable problem go away, it will be well worth the expenditure. Remember that gathering data and conducting analyses also costs money. The procedures and calculations should be proportional to the risks and costs involved.



--

************************
Michael Griffin
London, Ont. Canada
************************
 
V

Vladimir E. Zyubin

Hello Michael,

MG> I was talking about repairing as well. Sometimes you have to modify the
MG> machine in order to repair it. When you go to fix the machine, you may find
MG> that you can't get the exact same part anymore - it has gone obsolete, or it
MG> takes too long to get but you may have something else which will work. The
MG> replacement part or device may not work exactly the same way as the previous
MG> one. Or perhaps the replacement part is simply going to break the same way
MG> the original one did unless you change what you are doing. So in order to fix
MG> the machine, you may have to modify it slightly.

Sorry, see no difference. It is an ordinary modification. Just we have different reasons for modification. The normal case for modification is a technical reason (to increase productivity, to increase quality, to minimise the rejects, and so on). You describe just abnormal case of modification (lack of repair parts, new MS OS, etc.) The designers should foresee the maintenance stage... If no - the machine is bad designed. The customer ought to have the agreement with the repair parts vendors... (Obvious and widespread preventive actions for the modifications)

MG> As for "when all software errors are fixed", that may take a long time,
MG> perhaps forever. Many difficult errors require an unlikely combination of
MG> events to cause them to occur. This means that normal acceptance testing is
MG> unlikely to find them. However, "unlikely" is not the same as "random". The
MG> combination of events which triggers the error may suddenly occur repeatedly
MG> (possibly due to production lot variation) and need to be fixed right away.

Yes. But as you mention the errors are very rare. Is there reason to to hire 6 specialists if errors happen once a year? Again, if a soft error was fixed then it never appear again. It is property of soft.

MG> Problems with a machine program tend to be most frequent early in its life
MG> (or after a major retro-fit), and tail off as they are discovered and fixed.
MG> You may gradually approach the ideal of a "perfect" program, but are unlikely
MG> to achieve it right away.

Agreed with the former sentence. The second is debatable.. IMO. But we have achieved common point that the errors will be very rare at least. If the frequency will once a year then we can do not fix the error but just avoid the error condition. I.e. we again do not touch the codes any more.

MG> <clip>
>> If I correctly understand your words, you say that it is impossible to
>> write a complete program... Hm.. I am sorry, I miss the proof of the
>> statement. But rather there is no any proof.
MG> <clip>
MG> I won't say it is impossible to write a "perfect" program, but it is
MG> difficult to do so. In addition, we are not talking about just software, but
MG> a complete machine "system". Interactions between hardware and software also
MG> occur.
MG> In many cases, the original programmer was working with incomplete or
MG> incorrect information about how the machine systems were supposed to work.
MG> Mechanical and electrical designers are not perfect either, yet the software
MG> must be based on their work. I believe that you would agree that it is not
MG> feasible for even the best programmer to write a "correct" program based on
MG> incorrect information.

:) Yes. Agreed.

Just a remark: there is the nuance - good programmer is a programmed specialist (i.e. he is competent in the applied field). Plus: during the programming he see logic errors... etc.

Real programmer is not a cards dummy, but an active player during the design process.

>> Perhaps it is the main difference in our points of view.
>> As I see you speak about continuos improvement... IMO, any improvement is
>> a little revolution. It is an investment: proposition -> research
>> (economic calculation) -> plan of introduction -> changes
>> (investment) -> result in return...
>> The result of any improvement must be an increase the efficiency of
>> production... i.e., profits in percents...
MG> <clip>
>> Are there many improvements that satisfy the criterion? It is a big
>> question.
MG> <clip>

MG> No, some continuous improvements are dictated by the customer and are not
MG> subject to economic return calculations, at least this is the case in the
MG> automotive parts industry. For example, suppose you produced a defective part
MG> and this part was shipped to the customer. The customer will then require you
MG> to take immediate action (including changes to machinery if necessary) which
MG> will prevent this problem from ever happening again. These sorts of changes
MG> typically involve adding a sensor to detect missing or defective parts, or
MG> making a measurement, or some other such thing.

I believe if the customer is small (or the defect part party is small) the vendor can solve the problem with more cheap way. E.g., The vendor can just replace the defective part with a good one. Or he can intensify the checkup. Well, in some obvious cases the calculation is not necessary. But every time there is an estimation of that kind.

MG> You may of course argue that these problems should have been forseen and
MG> prevented to begin with. However as I said above, the mechanical and
MG> electrical designers are not perfect either. The programmer can only work
MG> with what information and devices he has available to him.

In the case I argue that the solution should be chosen on the economic base.

MG> In addition to the above, there are many improvements which are the result
MG> of employee suggestions which are relatively inexpensive to implement. The
MG> cost of adding a sensor or valve to help keep a feeder track from jamming are
MG> typically very small compared to the down time saved.
MG> You have to be careful to not over-analyse a problem. The information to
MG> base these judgements on is normally uncertain and incomplete. You could
MG> easily spend more money (in manhours) "proving" a change is not economic,
MG> than it would have cost you to simply do it.

:) Yes. Agreed. There are various situations with various exceptions. I think that just for those cases we were equipped with the heads...

--
Best regards,
Vladimir mailto:[email protected]
 
I would request through each vendor that they provide the programming style that you specify.
Give them sample ladder diagrams etc., that portray your needs.

Specification is how they make more money but, it speeds up production on your end.
Just my .02 cents.
 
Michael Griffin:
> In addition to the above, there are many improvements which are the
> result of employee suggestions which are relatively inexpensive to
> implement. The cost of adding a sensor or valve to help keep a feeder
> track from jamming are typically very small compared to the down time
> saved.

Not to mention that implementing employee suggestions will improve morale, increase ownership of the process by the operators, encourage further suggestions, and so on, even if the direct economic impact is frankly nil.

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