advertisement
from the department...
PLC code standards
Engineering and workplace issues. topic
Posted by Stephen Wright on 3 July, 2002 - 3:37 pm
I am a controls engineer working in support of a mid-sized manufacturing plant. At this plant we purchase a variety of special machines from a variety of vendors. Generally these machine controls take care of themselves. However when I need to solve a process problem with one of
these machines I am always forced to understand the programming style of each.

Is there a way I can direct my vendors to a more standard, widely accepted programming style? I myself am guilty of some individual programming idiosyncracies, but is there a way I could point myself and my suppliers to a more universal approach without compromising originality?


Posted by Curt Wuollet on 3 July, 2002 - 3:55 pm
A software spec. and sign off?
If it's reasonable it shouldn't raise costs too much. Making your needs definite up front as part of the sales agreement is usually the best way.

Regards
cww


Posted by Dale Witman on 3 July, 2002 - 4:08 pm
Stephen,
I have a document that I wrote some years ago, probably needs updating, but will probably suffice for vendors. E-Mail me at Dale.Witman@WestPharma.com and I can forward a copy to you.

Dale


Posted by Michael Griffin on 3 July, 2002 - 4:31 pm
There is no single universally accepted approach to programming PLCs. The fact that when left to themselves every supplier does it a different way
shows that.

What you can do is to write a programming guideline which shows how you would like things done. Send out a copy of the guideliine (preferably in PDF format) with each request for quotation so that each supplier knows you are
asking for this before they submit a quote.

The guideline should be broken down into functional areas such as mode transfers, alarming, sequential control, parameter editing, etc. for whatever it is you are trying to specify. If you would like to block out areas of
memory for particular uses, then describe those as well.

The guideline should be written with actual code examples to illustrate each point. It is important though to include an explanation of why you would like things done that way, rather than just show something and say "do this". The person who is writing a program using your guideline will need to understand your intent in order to comply with your general objective. No guideline can cover all possibilities, so you want people to be able to extrapolate from what you have written.

For your examples, I would suggest using code that you have tested in an actual application to ensure that it works correctly. I would also suggest using examples from a project that you (or one of your co-workers) has written, rather than lifting them from programs written by your suppliers.

Some people would not like code samples from their own work being handed out to all and sundry. You may find it best to write a special program which is very carefully written to show as an "ideal" case. I think it is important
though that if you ask someone to do something a particular way, that you have tested it carefully to make sure it works.

Don't forget to specify internal program documentation requirements as requiring symbols for all addresses used and rung comments. If you have a preferred convention for symbol names and abbreviations, you can state those as well.

Expect to put a considerable amount of work into this document if you want something which is useful. Regardless of how detailed it is though, you will find that no one else will ever do things exactly the way you would have. This particularly applies to the finer details. Your objective should simply be to have the broad approach being similar enough that each machine does not become a major reverse engineering project when it comes time to understand it.

One thing to keep in mind in all this is that a guideline on programming style should not also be a specification on how a machine should work or on what the operator interface should look like. If you wish to deal with those issues as well, they deserve separate documents themselves.

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


Posted by Trevor on 5 July, 2002 - 10:13 am
I agree with Michael on all points. I would like to repeat that standardized documentation is very important. It allows you to search for items, areas of code, or inputs/outputs very quickly and efficiently. It also allows you to print out and sort lists in an orderly fasion. Segregate memory, document consistantly, and show your vendors as many examples as you can. This should really make a difference. You will also find out which vendors are worth a darn, or just pass on the job to the most inexperienced/cheapest programmer on their staff.

Aloha


Posted by Bob Peterson on 5 July, 2002 - 3:59 pm
I have seen a fair number of attempts at this. Most of them fail pretty miserably because they usually are oriented around a certain type of
machine/control. To do it well would take a lot of time, and most people don't have the time to do this kind of thing. What I have seen done tends to be one of the following:

1. Samples of code. Sometimes I have gotten samples that are almost undeciperable as to the intent, others don't even work. Some are written OK but don't really address things outside of the things the programmer thought of when writing the code snippet.

2. Data structuring techniques. These tend to be a little better thought out but usually are pretty simple An example was a Modicon 984 program where they specified all the digital inputs would be 1xxxx addresses, the digital
outputs would be 0xxxx addresses, and register inputs would be 3xxxx addresses (I kid you not -this was part of a spec I worked on once). For
those with no PLC experience, this is the only I/O addressing scheme allowed in a 984 processor. Why they felt it was necessary to put in their spec was kind of beyond me.

3. I have seen code specs that require ALL logic be done with only coils and contacts. Makes it near impossible to do any analog at all, yet the project had dozens (maybe as many as 100) analog I/o points.

One spec said all code must be in a single program file. I talked them out of this by showing their engineer how to call up the seperate files and explaining why it was important to structure the code this way.

4. Documentation specs. One spec I ran across said all PLC addresses must have descriptors. The programmer that worked on it before me called timer T4:0 "Timer #1", T4:1 was called "Timer #2", etc.

Another spec required ALL rungs must have rung comments. One of the niftier things about RLL is that if you are careful, most rungs are pretty much self documented via the address descriptors so rung comments are not really needed MOST of the time. My theory on rung comments is that if your code is so badly done that you need to explain it, its probably in need of redoing. I
only put rung comments where its not obvious what is going on (such as when setting up analog input points for filtering/ranges/ etc.

The worst thing I see is not so much the code but the fact that there is little or no description on how the machine is supposed to work. The code
becomes the sequence of operation, and the only reference available on how it works.

I would make two suggestions.

1. Insist that a written sequence of operation be supplied, also subject to approval. Make it part of the spec that no code can be written until this document is in your hands and approved. You may have to do this in steps,
but this is well worth it. I don't really care what format this takes, but it should be COMPLETE and UNEQUIVICAL. Often I read sequences where things are missing like:

- how are alarms reset?
- does an alarm have a time delay associated with it?
- does a startup sequence have time delays associated with it? For instance its not uncoomon to start up a series of spindle motors on a dial machine sequentially rather then all at once.

The document should be written such that its completely unequivical. No interpretation allowed. It says what it means and means what it says.

This does not mean the sequence of operation cannot be revised along the way, but only that when it is revised it is documented and the SOO is updated.

2. Make the PLC code an approvable item, just as the schematics are. Make it clear in your spec that if the code is not understandable and consistent, it will not be approved. Check a couple of sections of the code you get against the sequence of operation. make sure it actually does what it says. If it does not, then one of the other is wrong and needs correction. I would
not be all that worried about stylistic differences, but I might put a few requirements into the spec such as:

- sequential items must be controlled via a number in a register that corresponds to the step number. that way you get rid of most logic races, and its obvious where you are. You can only be in one step at a time this way, and its relatively easy to jump out of sequence if you have to without strange looking code.

- limit the use of latches in the logic. You may not be able to eliminate them completely, but use them sparingly.

There are probably other things that are useful you might thinks about. Give it a month or two and I am suree you will come up with a decent document. Try to do it in a few hours and it will be useless.

Bob Peterson


Posted by Michael Griffin on 6 July, 2002 - 7:14 pm
<clip>
> I have seen a fair number of attempts at this. Most of them fail pretty
> miserably because they usually are oriented around a certain type of
> machine/control.
<clip>
This is a good point and raises something I should have mentioned in my earlier reply. I don't think that it is feasible to write a useful single programming guideline that covers all types of machinery. It is inevitable that it will make certain assumptions about the type of machinery or process being controlled. The fact that these machines or processes are broadly similar is what makes the guideline feasible and useful to begin with.
These assumptions should however be stated clearly at the beginning of the document. If a particular application does not fit these assumptions, then the sections of the guideline which cannot be applied to it should be set aside for that project.

> What I have seen done tends to be one of the following:
>
> 1. Samples of code. Sometimes I have gotten samples that are almost
> undeciperable as to the intent, others don't even work. Some are written
> OK but don't really address things outside of the things the programmer
> thought of when writing the code snippet.

I am sure that you will agree that code samples or "example programs" by themselves are not very useful. A set of disjointed "snippets" without accompanying explanation don't tell you how they should relate to one another. Large example programs take an excessive amount of time to read and analyse without any guarranty that the reader will understand what it is you had in mind.

> 2. Data structuring techniques. These tend to be a little better
> thought out but usually are pretty simple An example was a Modicon 984
> program where they specified all the digital inputs would be 1xxxx
> addresses, the digital outputs would be 0xxxx addresses, and register
> inputs would be 3xxxx addresses (I kid you not -this was part of a spec
> I worked on once). For those with no PLC experience, this is the only
> I/O addressing scheme allowed in a 984 processor. Why they felt it was
> necessary to put in their spec was kind of beyond me.
<clip>

On the other hand, I have seen people use output addresses in spare slots as flags (internal coils) because they didn't know what the flag addresses were in that brand or model of PLC. This makes things rather interesting when you are trying to understand a program, or even worse, trying to add an I/O card into that previously unused slot.
It would not be unreasonable to specify something to the effect of using the PLC's addresses and features in a manner corresponding to convention and the manufacturer's recommended practices. Some of the worst programming practices I have seen have arisen from people going to great lengths trying to program a piece of hardware using methods which were derived from something they were more familiar with, but completely unsuited to the hardware in question.

> Another spec required ALL rungs must have rung comments. One of the
> niftier things about RLL is that if you are careful, most rungs are
> pretty much self documented via the address descriptors so rung comments
> are not really needed MOST of the time. My theory on rung comments is
> that if your code is so badly done that you need to explain it, its
> probably in need of redoing.
<clip>

On the other hand, if the code *is* unreadable but works, you are not likely to be able to force the programmer to re-write it. It will come down to an arguement with you saying you don't like it, and the programming saying your objections are unreasonable. You are probably better off as a customer specifying having rung comments, and then over looking their absence if the program is reasonably readable without them.

> The worst thing I see is not so much the code but the fact that there is
> little or no description on how the machine is supposed to work. The
> code becomes the sequence of operation, and the only reference available
> on how it works.
<clip>

This of course, is a separate issue. A good documentation specification is probably more important than a programming guideline. It is easier to figure out how a program works if you understand exactly what the machine does, than the reverse would be.



--

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


Posted by Bruce Durdle on 7 July, 2002 - 7:47 pm
One way to get improved readability of a PLC program is to link it very strongly to the Functional Description.

If every clause in the Functional Description is translated as directly as possible into a block of ladder logic or SFC or FBD or whatever, then the
documentation is already done and need only be pasted in. There is direct traceability between the requirements and the final code, and testing (which should be aimed at verifying operation against the FDS) is simplified.

Another useful thing to insist on is that documentation uses standard tags and the same descriptors as other plant documents. Switches etc need to be explicit as to whether they are open on High or open on Low, etc.

One point I have come to accept is that the automation industry has a tradition of accepting things that work, regardless of whetther or not they comply with the "politically correct" view of how things ought to be done. It is particularly evident that theories develoiped in the academic community take a long time to gain acceptance on the shop floor, unless they offer some immediate and obvious benefits. Perhaps that might help to
explain why RLL is still going strong ...

Bruce.


Posted by Dave on 20 July, 2002 - 2:21 pm
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"


Posted by Bob Peterson on 20 July, 2002 - 9:09 pm
> 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


Posted by Edward W. Oskam on 5 July, 2002 - 11:03 am
Your complaint is one i hear a lot. I'm sorry to have to admit that you are right. As a software engineer I often switch to my own style of programming.

The reason for that is simple; it's effective and takes less time. All principals are proven by other projects.

I realize that the customer is not always happy with that end result, but until problems arises, who cares?

The only way to prevent problems is by demanding documentation of every part of the software. A programmer that does not keep it's documentation up-to-date is a menace to its own program.

I hope this helps you (in the future)
Edward


Posted by Bruce Durdle on 6 July, 2002 - 7:21 pm
OK Edward,

So you come to me and say you want a new kitchen designed for your home. I just happen to have a portfolio of standard designs that I have built up over past projects. All have worked successfully for their clients.

You give me a list of your requirements, including colour, preferred appliances, and your required layout.

I give you in return a design cobbled together from my past projects, which uses different hardware, has a different colour scheme, and doesn't quite fit into the space you have available.

But the design process is "effective" - (to me) and has taken "less time" (to me). The design has been "proven".

You, as the customer, are not happy with the end result, but can still cook a meal and wash the dishes. I walk away with my nice fat designer's cheque - who cares?

This is not "software engineering" - it's imposing your notion of what is needed on the end user. Yes, I know it's how Microsoft work and there are a lot of people out there who accept the result, but it is totally unacceptable in an industrial automation environmment. If a client has a site standard to use negative logic for shutdown systems, but your preference is for positive logic, that's your problem. You cannot just go ahead and design using positive logic regardless.

An engineer in any other discipline will insist on a detailed brief and specification before work starts, and the project will not be accepted by the end user unless it meets that specification. This can be done with software as well. But there seems to be something in the mind-set of software jockeys (as opposed to true software engineers) that forces them to do their own thing regardless of the situation.


Bruce.


Posted by Brian E Boothe on 8 July, 2002 - 2:26 pm
Our Company Only Keeps Documentation on site In-case of a lose of our software On the Local machine.. so we dont have to retrace our steps. my question is how can there be a standard to Ladder Programming? There isnt THAT Much to it..To Really Impose a Standard.. Except Maybe
Subroutine Usage. can someone give me Some examples. Bit file usage?? Integer file usage.
(EXPLAIN).


Posted by Bruce Durdle on 10 July, 2002 - 10:36 am
Some items for standardisation -

Positive vs negative logic - does an energised coil mean an active or inactive condition?

Rules for using latches - if the language set has Latch/Reset contacts, are they used? If they are, I prefer to see them once only in a scan, in
adjacent rungs.

Arithmetic format - are analogue values handled in raw form or converted to engineering form?

Allocation of coils to parts of the system.

etc

Bruce.


Posted by Bob Peterson on 15 July, 2002 - 2:17 pm
Bruce Durdle wrote:
> Some items for standardisation -
>
> Positive vs negative logic - does an energised coil mean an active or
> inactive condition?

At the very least the descriptor should indicate what logic 0 or 1 means.

> Rules for using latches - if the language set has Latch/Reset
> contacts, are they used? If they are, I prefer to see them once only
> in a scan, in adjacent rungs.

AMEN! Best bet is to avoid them altogether. You can always tell when someone is using too many latches because they end up with a bunch of singleshots in the code to get rid of the scan races. Overuse of latches is probably the best single indicator of low skill or experience level on the part of the programmer.

> Arithmetic format - are analogue values handled in raw form or
> converted to engineering form?

Another thing is that if at all possible the values should be in floating point format so the value is always in engineering units, thus not requiring some kind of implied scaling. That way you can read the value directly. If for some reason you are forced to use integers the descriptor for the value should clearly state any implied scaling. The descriptor should also indicate the units (i.e.-psi, inches, etc.).

Bob Peterson


Posted by Dobrowolski, Jacek on 15 July, 2002 - 2:18 pm
Bob Peterson wrote:
>AMEN! Best bet is to avoid them altogether. You can always tell when someone is using too many latches because they end up with a bunch of
singleshots in the code to get rid of the scan races. Overuse of latches is probably the best single indicator of low skill or experience level on the part of the programmer. <snip>

Dear Sirs,

There're machines to control which is enough to use combinatorial logic approach only - then no need to use the latch/reset instructions. But there are also a little bit more advanced machines to which the automata theory must be applied. As far as I remember to implement this kind of beast in a hardware way, there's required a device called latch (what a coincidence). So usage of the latch/reset or set/reset instructions in a PLC program is one of the most straightforward implementations of the state
machine (remember that not every PLC programming package supports state flow languages nor every customer wants to see other than ladder languages in the PLC program).

And in the end I'd be careful with adopting skill indicators.

AMEN!

Best regards,

Jacek Dobrowolski, M. Sc. E. Eng.
Software Eng.


Posted by Bob Peterson on 15 July, 2002 - 2:27 pm
I have seen hundreds of PLC programs written by other people that used a lot of latches. I am pretty sure there was no attempt at creating any kind of state machine in any of these programs. It was just really awful code, written by people who just were not very good. If you will remember what I said was "You can always tell when someone is using too many latches because they end up with a bunch of singleshots in the code to get rid of the scan races." If it was good code, and a well thought out state machine, it would not have the one shots or the scan races.

As for being "straightforward", I am not all that sure that it is. You can create something much simplere by using a number in a register to define the current machine state. Its a whole lot simpler and easier to code and debug, than any number of latches and unlatches.


Posted by Vladimir E. Zyubin on 16 July, 2002 - 1:26 pm
Hello PETERSONRA,

PAC> As for being "straightforward", I am not all that sure that it is.
PAC> You can create something much simplere by using a number in a register
PAC> to define the current machine state. Its a whole lot
PAC> simpler and easier to code and debug, than any number
PAC> of latches and unlatches.

But the right solution is to use the right programming model. Unfortunately for all of us, there is a large class of tasks that can not be implemented in the LD... despite on our wishes
to be both wealthy and healthy... :-)

"Can not" because the brain will get the cancer because of working with the current-machine-state-registers. Overcomplexity because of an inadequate tool.

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


Posted by Dobrowolski, Jacek on 16 July, 2002 - 2:35 pm
Bob Peterson wrote:
>I have seen hundreds of PLC programs written by other people that used a lot of latches. I am pretty sure there was no attempt at creating any kind of state machine in any of these programs. It was just really awful code, written by people who just were not very good. If you will remember what I said was "You can always tell when someone is using too many latches because they end up with a bunch of singleshots in the code to get rid of the scan races." If it was good code, and a well thought out state machine, it would not have the one shots or the scan races. <

I see your point now and agree with it.

>As for being "straightforward", I am not all that sure that it is. You can create something much simplere by using a number in a register to
define the current machine state. Its a whole lot simpler and easier to code and debug, than any number of latches and unlatches.<

Sometimes there's a need to split the flow into simultaneously executed paths. Then using a register is no longer so easy. On the other hand simple logic (bit) instructions are usually executed faster and occupy less memory than integer instructions. Less and faster code.

Regards,

Jacek Dobrowolski, M. Sc. E. Eng.
Software Eng.


Posted by ScienceOfficer on 17 July, 2002 - 1:29 pm
Bad code can be defined many ways, but I don't understand declaring Latch/Unlatch usage as a symptom of it.

Latch and Unlatch are useful in the cases where the conditions for setting a bit are not the opposite of the conditions for resetting it. Time is the best example; technically, Monday is not the opposite of Friday. I know of many applications (outdoor lighting, pump control, etc.) where an output is latched at a start time and unlatched at an end time, or after a duration,
or after a completion signal.

Latch and Unlatch are also a natural for _two-state_ situations. For example, on a gravity ride (e.g., a roller coaster), when a vehicle or a
failure is detected in a zone, the blocking mechanisms at the beginning of the zone are unlatched. When the zone is known to be clear, the blocking mechanisms are latched. There is actually quite a bit of code involved with something like this, and the logic supporting the Latch and Unlatch decisions is quite complex in each case. (I once did one of these without
using Latch/Unlatch, just to prove I could do it. The code was unmaintainable, and got rewritten using Latch/Unlatch at the next
engineering change!)

I'll agree that attempts to create state machines using chained latches can be a mess, but I've also seen it done well. I recall a very complex and successful machine with dozens of states in at least ten different execution threads, and the technicians could tell everything that was going
on by looking at one data table display on the programming terminal.

Wherever a "1" quit marching from right to left, they knew to look there for the problem. This was before HMIs as we know them today, though, and I doubt I would encourage anyone to go to this much design effort today.

All that said, I find it unforgiveable when the Latch and Unlatch are not next to each other, or when the output bit is addressed by more than a
single instance of each.

Hope this helps!

Larry Lawver
Rexel / Central Florida


Posted by Bob Peterson on 17 July, 2002 - 2:18 pm
ScienceOfficer writes:

> Latch and Unlatch are useful in the cases where the conditions for
> setting a bit are not the opposite of the conditions for resetting it.
> Time is the best example; technically, Monday is not the opposite of
> Friday. I know of many applications (outdoor lighting, pump control, etc.)
> where an output is latched at a start time and unlatched at
> an end time, or
> after a duration, or after a completion signal.

I would agree there are good reasons to use latches, time is probably not one of them, since it does have more than 2 states, I would be inclined to represent a day of the week as a number from 0 to 6, rather then as would 7 seperate latches. It seems to me this is inherently more obvious. I would probably not use a latch to turn on anything time based, but would probably use a compare statement to compare the current time to the period of time the output is supposed to be on and use that logic to control the output. One reason for doing so is that the idea of latching a bit on, then off works most of the time, but what happens if someone resets the time of day clock, such that the off time does not happen, An example - on at 8 off at 5, at 4:55 the operator realizes the PLC TOD clock is wrong and sets it to 5:05. Now it won't unlatch. BUT, if you used a limit test to turn the output on when the time is between 8 and 5, it would still work correctly, and it seems more obvious to me do to it this way. I realize there are ways to avoid this situation and still use latches, but I prefer something that is more obvious to me.

The main problem I have with latches is not that they are used at all, but that really badly written programs seem to rely on them and the associated single shots that are used to clear the scan races the poorly written code produces. I agree there are other ways to write bad code, but this seems to be a common way of doing so. I have even seen code where the programmer created single shots in RLL to unlatch bits and apparrently either did not realize he was doing so or did not know the PLC had a single shot instruction.

Another indicator of bad code is code that has a lot of short timers in the logic to keep things synched together. I hate this cause its just as easy, and more consistent to write the code so that the timer is not required. For example - I have seen code where a timer was used after a sequence was completed to allow part of a machine to move out of the way, before another seqeunce started that would have crashed into it. The problem with using a timer is that what happens if it does not move. Its a little easier to code this way, but its much better to code a permissive into the sequence rather then just relying on the thing working OK every time for the next 30 years.

bob


Posted by Michael Griffin on 18 July, 2002 - 2:59 pm
On July 17, 2002 11:26 am, Larry Lawver wrote:
<clip>
> All that said, I find it unforgiveable when the Latch and Unlatch are
> not next to each other, or when the output bit is addressed by more than a
> single instance of each.
<clip>
If I understand what you are saying correctly, then I think that this can have problems of its own. For example, when you have conditions which require several latches to be set or reset together, then if you always want to put your set and reset conditions next to one another you have to duplicate the rung logic to accomplish this. This increases the chance of bugs being introduced.
Another problem is when the states of groups of latches must be consistent, but they are located in different parts of the program. This results in zones where one bit has been modified, but the other has not yet. Suppose
that 'A' is set under some condition, 'B' is set under some other set of conditions, but when 'A' is reset, then 'B' must also be reset. Can I always contrive to ensure that there are no side effects if 'A' and 'B' are reset some distance apart from one another? Would it not be simpler and more fool proof to simply reset them in the same rung?

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.
Suppose that at a particular point in my sequence, I set a flag to indicate "weld complete", and I want to remember this until I have released the part from the machine. Now where should I reset this flag? With the logic
which is related to releasing the part from the machine or with the logic which is related to weld complete? With the first method (releasing the part), the operations conducted on the flag are related to the sequence of operations, while with the second (welding), they are not.

I think you should use latches sparingly and carefully because you always need to make sure that you clean them up under all possible conditions. However, I think that arbitrarily avoiding them because someone once used them when he wrote a bad program can be a cure which is worse than the disease.

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


Posted by Ralph Mackiewicz on 19 July, 2002 - 3:34 pm
> 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.


Posted by Michael Griffin on 16 July, 2002 - 4:17 pm
Bob Peterson wrote:
<clip>
> As for being "straightforward", I am not all that sure that it is. You can
> create something much simplere by using a number in a register to define
> the current machine state. Its a whole lot simpler and easier to code and
> debug, than any number of latches and unlatches.
<clip>

You can write a bad program using just about any method there is. The integer number approach has its problems as well. If the sequence has exceptions (loops, jumps, etc.) you end up writing "magic numbers" as constants in the instructions that write to the step register. Because there is nothing obvious about what the number itself means it is easy to make a mistake and type in the wrong number (I've made enough of these mistakes to know what I am talking about with this).

The biggest problem with this method though is when the sequence itself is not a simple linear sequence, but diverges into parallel paths and converges back again. With a "step number" approach, you typically end up with multiple interlocking software sequences which have to handshake with each other in
order to try to describe parallel execution paths. This can get quite messy and error prone as well, especially the interlocks between the multiple sequences.

However, when the machine sequences are always simple linear sequences which aways execute in the same order, then the "step number" approach does have the advantage of being easy to describe. What makes the method easy to use in
some applications but difficult in others is that it contains assumptions about the type of process you are trying to control (the simple linear
progression). I suppose your opinion on the method may depend upon the type of machinery you are exposed to.

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


Posted by Vladimir E. Zyubin on 17 July, 2002 - 1:25 pm
Hello Michael,

Michael Griffin wrote:

MG> You can write a bad program using just about any method there is. The
MG> integer number approach has its problems as well. If the sequence has
MG> exceptions (loops, jumps, etc.) you end up writing "magic numbers" as
MG> constants in the instructions that write to the step register. Because there
MG> is nothing obvious about what the number itself means it is easy to make a
MG> mistake and type in the wrong number (I've made enough of these mistakes to
MG> know what I am talking about with this).

Yes. Finite state machine in the LD leads to unreliable programs. Identifiers and adequate programming model are the only medicine. Even
SFC makes the problem much simpler.

MG> The biggest problem with this method though is when the sequence itself is
MG> not a simple linear sequence, but diverges into parallel paths and converges
MG> back again. With a "step number" approach, you typically end up with multiple
MG> interlocking software sequences which have to handshake with each other in
MG> order to try to describe parallel execution paths. This can get quite messy
MG> and error prone as well, especially the interlocks between the multiple
MG> sequences.

The divergence is not a problem. The convergence is. It demands a strict technique, dicipline... especially, when there is need to work up errors
in algorithm, when the response of control system on errors is algorithmically complex... The other case - if the errors are system errors, meta-level errors, e.g. errors issued by a I/O module defect... This kind of problems is complex in itself... Any aditional complexity (e.g. because of an inadequate linguistic means) then the problem becomes insoluble.

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


Posted by Brian E Boothe on 17 July, 2002 - 1:47 pm
By the over use of Alot of Latches is it Going to effect that Output from Going HI in ms or us Resolution. if thats the case get outta ladder logic and goto C++..


Posted by Joe Jansen/ENGR/HQ/KEMET/US on 18 July, 2002 - 4:19 pm
What are you talking about? The *A*ffect of latches in your logic on the time it takes to send the output high or low is insignificant. If your PLC scan time is measured in microseconds, you already have a lot more to worry about.

--Joe Jansen


Posted by Brian E Boothe on 19 July, 2002 - 3:08 pm
Soo... Im supposed to be worried over a Container valve Opening at 1ms less or more because of the scan times were off... because of the effect of latches... seems a little picky


Posted by Vladimir E. Zyubin on 18 July, 2002 - 2:44 pm
It seems to me Mr. Peterson states that any program will be more simple if it will be expressed by homogenious (simple) means.

Really, it depends on. If the algorithm is homogenious - yes, the homogenious (and adequate) means lead to a more readable program. If the algorithm is non-homogenious - no, the homogenious (and non-adequate) means lead to awgful unreadable code. (As an example we can keep in mind that every program can be expressed with the "decrement" and "jump if zero"
operands only... but these simple means will lead to unreadable code for vast majority of algorithms)

In the discussed case Latch/Unlatch are the means that do not consist in the Relay Model. It is the issue of Mr. Peterson's statement, i.e., the issue is the wishes to keep simple means. IMO.

On Wednesday, July 17, 2002, 9:26:45 PM, List Manager <listm@CONTROL.COM> wrote:

LM> Bob Peterson wrote:
>> I have seen hundreds of PLC programs written by other people that
>> used a lot of latches. I am pretty sure there was no attempt at
>> creating any kind of state machine in any of these programs. It was just
>> really awful code, written by people who just were not very good.
[...]

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


Posted by Bob Peterson on 18 July, 2002 - 4:46 pm
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. I really could care less if someone wrote a program using all latches and no coils. I myself use very few coils for actual sequencial control, as its much easier for me to visiualize a sequence as being a series of mutually exclusive steps, a logic state that is generally better described as a single value with more then two states, rather than multiple bits with 2 states each. A whole lot easier and eliminates the need to go back in and reset latched up bits with a cleanup routine.

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.

I do not like jump instructions because they are some what inherently non-obvious. Its really annoying to be trying to debug code inside a jump zone and not relaize you are in a jump zone. OTOH-with some PLCs, its a handy way to implement a do-while or for-next loop inside a single processor scan. But in that case the jump zone is usually only a rung or two long away so you can see it.


Posted by Michael Griffin on 19 July, 2002 - 3:11 pm
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
************************


Posted by Vladimir E. Zyubin on 19 July, 2002 - 3:30 pm
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


Posted by Stew Morris on 25 July, 2002 - 11:07 am
Spot on Bob. Some of the threads above are overly prescriptive - even though we are talking standards. There's nothing wrong with varying approaches to coding. What's missing in most PLC programs that I've come across is careful design & above all structure. Let's face it, our plant engineer has to maintain a variety of systems, each doing a different job function. All the guy needs to do is to get in there quickly & find the route cause. If the programming language does not support encapsulation ( and maybe abstraction & reuse also ) may be he shouldn't be specifying it. Break it down into manageable chuncks !


Posted by Bruce Durdle on 16 July, 2002 - 10:42 am
I was referring to the use of a Latch/Unlatch instruction combination as opposed to building a latching circuit out of coils and contacts. With the circuit, the "programmer" has the option of deliberately determining whether the reset or set contact dominates, whereas with L/U coils it
depends purely on the order in whicxh these are in the ladder. (It is also possible to have the same coil behave differently in a scan if a L is
followed by a U and then by another L acting on the same address.)

Bruce


Posted by Dobrowolski, Jacek on 17 July, 2002 - 2:21 pm
What can I say ? Stop thinking of coils (as an electrician) start thinking about memory areas (as a programmer). It will make your life easier.
Particularly as this "differently behaving coil" phenomenon is considered.

Regards,

Jacek Dobrowolski, M. Sc. E. Eng.
Software Eng.


Posted by Brian E Boothe on 19 July, 2002 - 3:16 pm
THERE IS YOUR DIFFERENCE...(programmers Vs electricians.) .......


Posted by Vladimir E. Zyubin on 20 July, 2002 - 2:28 pm
Programmer ought to think in terms of algorithm, purpose functions...
coders think in terms of memory areas, registers, interrupts, datatypes...


Posted by Bruce Durdle on 21 July, 2002 - 4:20 pm
... 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.


Posted by Michael Griffin on 10 July, 2002 - 10:38 am
The reason for a "standard" (i prefer the term "guideline") is to make a program easier for the final customer to understand by making it more consistent with the general usage they are familiar with. This is rather similar to the reason why there are "standards" in most human languages for capitalisation and punctuation. When these standards are ignored, then programs (or messages) become more difficult to understand or decypher.

A PLC or PLC language is intended for universal (or at least very wide) application in automation areas. In any particular industry or application class however, there are common problems which can be solved in a common way. A standard (or "guideline") is intended to specify what this common approach is. When programs are written to a standard, you know what to expect when you read a program you haven't seen before.
Unfortunately, there are no published widely accepted programming practices which can be used, so any company which desires a common standard ends up with their own rather than being able to adopt one.

There are several aspects to a standard. One can be a naming and abreviation convention for symbols (these should hopefully also be similar to what is on the electrical schematics). This would also normally include the human
language you would like program documentation to be in (do you want your rung comments in english, or is french OK?).
Another is a data memory usage standard. For example, you may specify a particular memory area for alarms, and another for parameter storage.
Still another aspect can be programming language representation. You may specify ladder rather than instruction list for general use, but allow instruction list for certain limited applications (e.g. inside function blocks which perform data manipulation rather than direct control).
A further type may be code methods for common problems, such as machine sequence control. There are at least a half a dozen common methods of controlling a multi-step sequence. A "standard" would state which of them to use.
Yet another type may be to specify the general program organisation. For example, mode transfers may be in one subroutine, MMI control in another, alarm decoding in another, machine control functions in a particular range of
subroutines, etc.
A final type may be to specify using certain proven function blocks which the customer has written for particular application problems (e.g. to interface to particular hardware). Using these proven function blocks saves time (and therefore money) and eliminates a source of bugs.

I think the above gives a general idea of what a standard (or guideline) would cover. It is mainly of benefit with larger programs. With small "relay replacement" programs, the benefit may not be as great.

The above discusses the "what". As to "why", the reason is the customer will sooner or later have to read the program to solve a particular problem, and it is likely they will have to do so when they cannot afford to waste any time getting the machine running again. If every machine was programmed using different methods, a great deal of time would be lost understanding each one.

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


Posted by Brian E Boothe on 12 July, 2002 - 3:31 pm
geesh thats the LAST thing we want is the FINAL: customer getting into our Ladder and screwing around with it..then there Machines screw up and Guess what ITS ALL OUR FAULT.
what Customer Knows Ladder Programming and C/C++ anyway??? Documentation to Installations and scada procedures. YES . BUT NOT the Ladder
Program for even access to the Windows Environment..................


Posted by Gord Graham on 15 July, 2002 - 5:45 am
I am one of those FINAL: customers that you are referring to and I take great offence to your "Holier Than Thou" attitude. First of all you were paid $$$ to put the code into the plc and that is where it ends. The program may require modifications due to operational changes (3 am).

Are we supposed to call YOU to make the change? You may not know it but there are a lot of plain electricians out there that are EXCELLENT programmers.

Electricians were trained to understand and design ladder since it is a representation of the old world hard wiring. No rocket science to me.


Posted by Bob Peterson on 15 July, 2002 - 2:19 pm
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


Posted by Brian E Boothe on 17 July, 2002 - 2:15 pm
Well in OUR Company AN ELECTRICIAN Reads PRINTS,,, and Fixes&Repairs Motor Starters, runs Conduit Pulls Wire..Wires Outlets. Panel Building. (The Electrical Division). WE on the other Hand (CONTROL DIVISION) Install Processors Troubleshoot CONTROL Related issues, AB-PLC / NETWORKING. / C++ / VB CODE issues..Active-x Developement..Project Design and Engineering Specification. SURE our Electrician has A little Knowledge of Ladder Logic Paper And Pencil (BASIC-Knowledge) even Ours...NO quibble there at all..... But throw him on a 2Ghz Computer with The Software,, Using A Control-logix Processor with 500Tags+ in RS-VIEW..w. RS-SQL And He is Completly Lost. Even Windows Navigation itself Is a Struggle for Them... AND NO we Dont Want Tinker's / Play arounds in our Software. But we DO Document And Give Hardcopies of the Program...You must Only Implement In one location like a factory Setting or Something. then I Could understand your Meaning ......We on the Other Hand Work All over the US...


Posted by Joe Jansen/ENGR/HQ/KEMET/US on 18 July, 2002 - 11:58 am
That would be those of us that fall into the catagory of people you deem unworthy: The FINAL: customer. Those of us who actually pay the money to buy the stuff you build to pay your salary. Remember the saying about biting the hand that feeds you, and all of that.

All you are saying, really, is that -your- electricians are incapable of handling software. The electricians in our plants (more than one, and in more than one country) happen to be capable of handling ladder logic, because they have been trained to do so.

Having worked at 2 different robotics integrators prior to taking work as an end user, I can agree that at those companies, the electricians did not
work with the code at all. No need, as there were programmers there to do that.

However, when one of your systems is installed, are you on site for the entire install? Do you go with if there is a warranty issue that requires
a service tech to go out and repair the machine? The point is that if you are the only one that you allow near your code, then you are the one who
gets called at 3 am (or whenever) if something goes wrong.

In a machine builder setting, downtime is meaningless, as it is typically debug time. In production, downtime is measured in dollars/minute, and if you only have one person that knows how to write the program, then your
line sits down waiting for that person to come fix it. Better to have people on site, trained, that can cover the line round the clock.

--Joe Jansen


Posted by Vladimir E. Zyubin on 19 July, 2002 - 3:20 pm
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:zyubin@iae.nsk.su


Posted by Bob Peterson on 19 July, 2002 - 5:50 pm
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


Posted by Vladimir E. Zyubin on 22 July, 2002 - 3:39 pm
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


Posted by Bob Peterson on 22 July, 2002 - 3:41 pm
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


Posted by Vladimir E. Zyubin on 23 July, 2002 - 2:54 pm
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:zyubin@iae.nsk.su


Posted by Michael Griffin on 24 July, 2002 - 12:24 pm
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
************************


Posted by Vladimir E. Zyubin on 26 July, 2002 - 2:05 pm
Hello Michael,

On Wednesday, July 24, 2002, 8:49:54 AM, Michael Griffin wrote:
[...]
MG> The ideal for a manufacturer in this business (as well as various others) is
MG> to be as flexible as possible, and to be able to respond to changes as
MG> quickly as possible. Speed of response and flexibility are just as important
MG> as efficiency. There is increasing emphasis on flexibility as product life
MG> cycles are getting shorter, and there is a proliferation of special models
MG> and versions being produced.

Yes. Flexibility is a good characteristic of any system. What we do - we provide special linguistic tools to do it and DB of algorithms. It
permits to change algorithms EVERY day, EVERY technological loop... There are only technologists on the top level of flexibility (they don't know about PID, sensors, accuracy, deviation, nonleniarity, filters, adjustment etc.), they think of their specific problems only.. The other level of flexibility demands programmer-specialists in control algorithms, but they communicate with the technologists in the same language. And only on the lower level of control program they (programmers) deal with the objects (sensors, servos, pumps, valves, etc). The next level is the logical signals level. The next level is the physical signals level (level of I/O cards). There is the most bottom level of programming - OSes. We never correct it. We prefer to migrate or to use the stand alone concept. :-)

I think that the multilevel structuring like ours gives suboptimal flexibility. (Really I think that flexibility of our methodology is the best)

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

Yes. I see. I just can not catch how do the programmer do the changes in the LD. The programs they correct must be extremely simple. Kinda
physical parallelism on the objects level...

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

MG> <clip>
MG> If the machine isn't running or runs very poorly, your biggest concern is
MG> going to be that you can't supply your customer. If you don't do something
MG> about that very quickly, you aren't going to have any business to calculate a
MG> return on.

On the other hand lack of estimations can lead us to a wrong direction. On the other hand, Does quality lead to prosperity? Have a look at the MS story. :-)

MG> Realistically though, if you make an improvement to the machine which
MG> involves only $100 worth of hardware and it makes a noticable problem go
MG> away, it will be well worth the expenditure. Remember that gathering data and
MG> conducting analyses also costs money. The procedures and calculations should
MG> be proportional to the risks and costs involved.

Agreed.

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


Posted by Michael Griffin on 20 July, 2002 - 2:34 pm
> 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
************************


Posted by Vladimir E. Zyubin on 22 July, 2002 - 1:30 pm
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:zyubin@iae.nsk.su


Posted by Michael Griffin on 23 July, 2002 - 3:06 pm
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
************************


Posted by Jiri Baum on 25 July, 2002 - 10:29 am
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 <jiri@baum.com.au>
http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools


Posted by Vladimir E. Zyubin on 26 July, 2002 - 3:44 pm
Hello List,

On Thursday, July 25, 2002, 8:46:43 AM, Jiri Baum wrote:

JB> 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.

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

To Mr. Baum:
Jiri,
Inderect effects are considered as well. It is obvious, though it is difficult to calculate.

Another question is "is it right aproach to conside an influence on the stock price?".

And a couple of words to Mr. Griffin:
I see no reason to insist that "adding a sensor or valve [..] are typically very small compared to the down time saved".

So, where is the proof?

Please have a look at this.

The situation: an error happens.

What we must do? - 1. To clarify the cause. 2. To develope a plan to fix the cause. 3. To fix the cause 4. To test the modification/correction...

Did I say we must avoid to modificate the system? If there is a good reason, nobody have objections. Ever two valves and seven sensors...

But if we can solve the problem without additional hardware (! Note: it decreases MTBF and encreases MTTR!)... i.e., if we can fix the error via a correction of the program only, then IMO it is more preferable way.. it is a more economic effective way in most cases...

I believe that just to load a program is a less timeconsuming thing comparing to (to mount a sensor + to load the program)...
(I hope you agree that this new sensor leads to a program correction). Plus: In the second case program becomes more complex (again in most cases).

Or it is just an example? If so, it is a good example of economic effective solution: with a small investment (a cheap sensor) we have the result - a minute per a month of the working plant.

example of calculation (roughly):

1. investment: sensor price - $100, MTTF - 1 year, repairing - $100

2. result : a minute per a month of working plant (a car a month, i.e. the overheads (components, wages, etc.) is $9 500, the selling
value is $10 000, the profit is $500 a month or $6000 a year)

the same in the pure economic terms:
1. investment - $100 a year
2. result - $6000 a year

i.e. we have $60 per a dollar per a year.

The end.

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


Posted by Michael Griffin on 27 July, 2002 - 4:09 pm
On July 25, 2002 10:19 am, "Vladimir E. Zyubin" wrote:
<clip>
> And a couple of words to Mr. Griffin:
> I see no reason to insist that "adding a sensor or valve [..] are typically
> very small compared to the down time saved".
>
> So, where is the proof?
>
> Please have a look at this.
>
> The situation: an error happens.
>
> What we must do? - 1. To clarify the cause. 2. To develope a plan
> to fix the cause. 3. To fix the cause 4. To test the
> modification/correction...
<clip>

I think that at this point, we are just repeating ourselves.

However, the identify/plan/fix/test cycle does not always require big meetings and long reports. Not every problem is a difficult one, and not every cure is an expensive one. This in fact describes what a good industrial electrician is expected to be able to do - identify the cause, figure out how to fix it properly and once and for all, fix it, and verify that it works.
The engineering staff do the same, but they typically operate on a larger scale and over longer periods of time.

We are missing the point though. The question was why an electrician would need to change a program. One reason they need to change it is because they need to fix it and if the program was written in a readable format to begin
with (remember the subject of this discussion?), it really won't be that difficult for anything he will typically want to do. We've discussed before
why a program may not be correct to begin with, so I won't repeat myself on this point.

The other reason why an electrician would need to change the program is because he was assigned to make a minor improvement to the machine. Typically in this situation someone else has had a look at it and decided that it is worth doing. Again, if the program was written in an understandable format, there is no reason why the electrician can't make the program change as well.
Most of these sorts of things reallly aren't that difficult. If we need to make an improvement by adding a sensor to tell if a feeder bowl is getting low and then signal this to an operator via a beacon, why can't we give the whole job to an electrician to do in his spare time (between servicing breakdowns)? The most difficult part of the job to do right is probably going to be making the bracket, not programming the PLC. Perhaps the bracket is the
part of this project that engineering should be doing for him.

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


Posted by Vladimir E. Zyubin on 29 July, 2002 - 1:29 pm
Hello List,

On Sunday, July 28, 2002, 1:21:20 AM, Michael Griffin wrote:

LM> On July 25, 2002 10:19 am, "Vladimir E. Zyubin" wrote:
LM> <clip>
>> And a couple of words to Mr. Griffin:
>> I see no reason to insist that "adding a sensor or valve [..] are
>> typically very small compared to the down time saved".
>>
>> So, where is the proof?
>>
>> Please have a look at this.
>>
>> The situation: an error happens.
>>
>> What we must do? - 1. To clarify the cause. 2. To develope a plan to
>> fix the cause. 3. To fix the cause 4. To test the
>> modification/correction...
LM> <clip>

LM> I think that at this point, we are just repeating ourselves.

LM> However, the identify/plan/fix/test cycle does not always require
LM> big meetings and long reports. Not every problem is a difficult one,
LM> and not every cure is an expensive one. This in fact describes what a
LM> good industrial electrician is expected to be able to do - identify the
LM> cause, figure out how to fix it properly and once and for all, fix it,
LM> and verify that it works. The engineering staff do the same, but they
LM> typically operate on a larger scale and over longer periods of time.

Did I say "big meeting" or "long report"? I just say there ought to be a discipline. There ought to be a list of the changes. The maintenace
process must be reflected in a doc. Error / cause / action, error / cause / action, error / cause / action... even if every item is just
a sentence. Or a word.

LM> We are missing the point though. The question was why an electrician
LM> would need to change a program. One reason they need to change it is
LM> because they need to fix it and if the program was written in a readable
LM> format to begin with (remember the subject of this discussion?), it really
LM> won't be that difficult for anything he will typically want to do. We've
LM> discussed before why a program may not be correct to begin with, so I
LM> won't repeat myself on this point.

LM> The other reason why an electrician would need to change the
LM> program is
LM> because he was assigned to make a minor improvement to the machine.
LM> Typically in this situation someone else has had a look at it and
LM> decided that it is worth doing. Again, if the program was written in an
LM> understandable format, there is no reason why the electrician can't make
LM> the program change as well.

LM> Most of these sorts of things reallly aren't that difficult. If we
LM> need to make an improvement by adding a sensor to tell if a feeder bowl is
LM> getting low and then signal this to an operator via a beacon, why can't
LM> we give the whole job to an electrician to do in his spare time (between
LM> servicing breakdowns)? The most difficult part of the job to do right is
LM> probably going to be making the bracket, not programming the PLC.
LM> Perhaps the bracket is the part of this project that engineering should
LM> be doing for him.


>From the parallel thread "ENGR: PLC code standards" Mussel wrote:

"FYI: I've placed many machines in US, Japan, Sing, Europe. Depending on machine complexity and number of stations, the OME will be 90-95% when it leave the SI. In the US, OME will decline (esp automotive), In Japan, it will increase after a machine is delivered. Another topic for another time, many factors. BTW: I'm USA and would love to report that differently."

I must confess:
After Mr.Peterson stories about automotive industry in the USA, there is no wonder in the facts about the OME (Overall Machine Effeciency).

My personal point is simple:
Lack of discipline during maintenance leads to chaos. Lack of competence during maintenence leads to chaos. The language topic is less valuable in the case (though I see an influence as well). The main problem of the automative industry Mr. Peterson speak about is on the other level: Standardisation of the maintenace procedure.

The strategy of "continous improvments" lead to
decline of OME. I.e. the strategy is not an economic effective one.

BTW, the personel that is liable for soft can be called even "dustmen", but maintenace process must be properly organized.

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


Posted by Vladimir E. Zyubin on 24 July, 2002 - 2:04 pm
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:zyubin@iae.nsk.su


Posted by Bouchard, James \[CPCCA\]" on 13 July, 2002 - 12:18 pm
I am a customer and all our technicians ( 42 of them ) know Ladder logic and other things. In may cases we know the machines better that the builder. That is why we want the programs well done. Remember we run the machines 24 hours a day making real product and have more experience with how they operate than the builder who operates them only a few days and scraps all the production. We do not want machines with C/C++ because it is impossible to follow.

James Bouchard


Posted by Pierre Desrochers on 15 July, 2002 - 5:59 am
I do a lot of work for OEM. I do comissionning and service them machines over modems and Ethernet...

What J. Bouchard said is more than the real thing. When I talk to end-users technical department, I listen. They do know these machine more than I ever will.

We build them, test them in the shop, spend a few days comissionning them but THEY used them 24/7 in the real world. I often see Operators discussing the Ladder diagram when they troubleshoot. These guy are not dumb, they pickup bits and pieces along the way and they look and listen at these machine for more time than me.

Ladder... everybody knows that. If they don't, there nobody. What's the saying about getting out of the kitchen ???

Pierre D.

===========
Quote:
I am a customer and all our technicians (42 of them ) know Ladder logic and other things. In may cases we know the machines better that the builder.

That is why we want the programs well done. Remember we run the machines 24 hours a day making real product and have more experience with how they operate than the builder who operates them only a few days and scraps all the production. We do not want machines with C/C++ because it is impossible to follow.

James Bouchard


Posted by Curt Wuollet on 16 July, 2002 - 10:39 am
Hi Pierre, James.

I'm not sure anyone has proposed C/C++ as a general use automation language. Just because the hardware is programmed using C or C++ doesn't
mean that's what the end user sees. In fact, I would expect almost all current PLC system code was done in C or C++ with possibly some
assembler thrown in. My applications use C because it would be very difficult to describe machine vision procedures in ladder. Even in these applications the logic portions are done with boolean operators like "if( I2 && I17 )
Q1;" which describes a rung. I don't think many people would mistake what that does. It is also possible to make a graphical ladder editor that
outputs that statement when you draw the rung. I just didn't have the need or the time for that application. What we are discussing are other
ways to describe that rung. My preference would be that you could see and work with the logic graphically like any other ladder product. or
you could use an "english language" method like: If fill_valve is open and tank_full is on, turn on klaxon_horn. Or find another plausible
method to describe logic and processes that everyone can understand. Anyway, my point is that you are almost certainly using code written in
C/C++ every day and _all_ the machines you use probably run C at some level. If you don't want machines using C you need to invest heavily
in mechanical drums and relays. Leave it to the CS guys to find an interface that makes the job easy. No one is forgetting that that's the
whole idea of a PLC. I hate to see people scared off for no reason. It should be possible to accomodate all tastes.

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.


Posted by Jiri Baum on 17 July, 2002 - 2:17 pm
Curt (about using C in control):
> It is also possible to make a graphical ladder editor that outputs
> that statement when you draw the rung.

FWIW, MatPLC has a module that takes PLC-style mnemonics and translates them into C. Normally, you wouldn't look at the C, of course - MatPLC
then goes on to compile it into a full module which you then run.

It's not particularly readable code, because it's not expected to be read by humans and it has things like Master Control even if you never use it in your program, but it's not too bad. If you run the program in a debugger (like ddd), it'll show you the original mnemonics anyway.

Jiri
--
Jiri Baum <jiri@baum.com.au> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools


Posted by Michael Griffin on 13 July, 2002 - 12:20 pm
I don't know what type of machinery you may build or what your customers are like, but normal practice in the industries that I am familiar with is that most machines are custom built for the application and controlled by PLCs. Once the machine has been formally accepted by the customer, they take responsibility for operating and maintaining it, including the software. Warranty for software problems is normally invoked only for problems which are serious and repeated. The customer isn't going to sit with a production line down while waiting to contact the company which built the machine.

As for "what customers know ladder programming", well an industrial electrician would have difficulty finding employment in this area without knowing how to at least read a ladder program. 'C' or 'C++' knowledge is less common, but then I don't believe that was the subject of our discussion.

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


Posted by Jim Terry on 25 July, 2002 - 7:28 am
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.


Posted by Leigh Phillips on 25 July, 2002 - 11:39 am
There is a standard which can be applied by most PLC vendors it is called IEC1131 if you specify that all code be written to this standard including the use of sequential function charting it makes the subsequent fault finding much easier as it is a standard fomat and can be followed by most people with software experience


Posted by Bob Peterson on 26 July, 2002 - 1:40 pm
Thats a lot like specifying it be done in English. There are an infinite number of ways to code the same function. Specifiying a specific brand of PLc or IEC1131 does not ensure that machine A's code looks like machine B's.

Bob Peterson


Posted by Bouchard, James on 29 July, 2002 - 11:25 am
Or even that the same function will be coded the same way by different programmers on the same platform.

James Bouchard


Posted by emader on 25 July, 2002 - 11:47 am
There is no way to force anyone to program a specific way...that would be like tellng everyone to act the same way...it ain't gonna happen!!

I have been servicing and engineering motion control, cnc and plc control systems since 1972. There are a couple things I think would be of benefit to you based on my experience.

First of all, standardize on a specific brand of controller and then specify that system with your purchase order.

Secondly, generate a spec for documentation and specify that all of it (and I mean all - schematics, plc and parameter listings, manuals, etc.) be included in duplicate with your purchase order.

Last but not least, become intimately familiar with the products you have specified so you know how to service them. It takes some time, but it's not to hard to do when you have a factory full of the same brand of hardware.

Hope this helps.


Posted by Everett Arellano on 25 July, 2002 - 12:00 pm
I am also a controls/electrical engineer, however I work for a systems intergrator where our business is not manufacturing but supplying automated machinery. We program in state logic. It is a standard that we use and I also used it at my previous job. All of our engineers and end users can read each others code with relative ease. It helps when you are dealing with a hundreds of I/O. Weve used this method on multiple platforms. Personally I have used it on Automation Direct and Allen-Bradley PLCs


Posted by Mussel on 25 July, 2002 - 1:57 pm
WOW - what a cool thread going on here!
FYI: I'm a software manager at a large system integrator, been doing SI for 16 years. I can see all sides of this thread and each persons viewpoint.

However, to your original point...

If you purchase many machines of the same type, you should make a standardized specification. Just as you probably specify which PLC's, wiring color codes, safety guidelines, spare parts, etc. It may cost you a little more up-front to force your vendor to go that way, but it will save you time on your floor.

Being an SI, probably about 30% of my customers specify a standard architecture. Most of these are semiconductor, aircraft, or large consumables plants. Not so many automotive tier mfg's have this requirement - they mostly just specify AB/RA and IEEE 1131 and leave it at that.

We have many engineers of all disciplines. We are ISO certified and have all our own standards. However, when a customer comes to us, we will quote the machine with our own standards (because we know it best, etc.). A customer may specify via documents how the machine is to coded. We will review that, (usually raise the price accodingly) and provide that as a quote.

We turn MOST code over to the customer for them to maintain. From the time it leaves our hands, it usually remains on the floor (esp automotive) for electricians to deal with.

If any of you reading this and you're an SI, you'd better be flexible. After all, your job is _CUSTOM ENGINEERING TO CUSTOMERS REQUIREMENTS_. Just as you use specific wiring, color codes, recommended parts, etc. Your software should fit the needs of the customer as well. I'm not preaching here, it's tough market conditions right now.

As for some notes about the replies in this thread, this is a great reading thread (maybe best ever). Typical is _ENGINEERING_ vs _PRODUCTION_. ENGINEERING wants well organized and controlled machines, SW and HW maintenance records, scheduled downtimes for fixes, libraries of code, etc.

PRODUCTION is a different food chain. The Prod Mgmt can dynamically change requirements and 'expect' that the floor can accomodate them. Changes must be made on the fly, get the machine up, etc.

Ok, sounds like I'm middle of the road. Well I'm not at all. Just pointing out where both sides are coming from. A few recommendations:

1) If you're ISO, you'd better make changes temporarily on the floor, proper reports should be sent back to engineering for a permanent fix. ISO police will get you.

2) If you automotive, esp ILVS, there can be no excuse for errors in order timing or sequencing. Also, because this is highly network intensive, an engineer should be involved in the work.

3) If you're union, the electricians control a lot. They'll make changes on the floor and rarely document. Sometimes changes that are meant to be only temporarily become permanent.

4) If you're a mix (or all of) the above.... well, thats another matter.

Bottom Line. The OME (Overall Machine Effeciency) of a machine should go UP! Engineering and Production both want to see this! If your OME goes down and electricians are working on it, then one way or another, they are not maintaining the machine as good at they can. (Don't let sensors, part availability be an excuse - you'll need to measure OME for a month or two). If engineering maintains the machine and OME goes down, then they are too slow (specialist at 3AM, to much analysis, etc.). Look at the OME and evalueate your needs.

FYI: I've placed many machines in US, Japan, Sing, Europe. Depending on machine complexity and number of stations, the OME will be 90-95% when it leave the SI. In the US, OME will decline (esp automotive), In Japan, it will increase after a machine is delivered. Another topic for another time, many factors. BTW: I'm USA and would love to report that differently.

JR


Posted by Geoffrey Dell on 25 July, 2002 - 2:33 pm
You may want to begin with standardizing the make of PLC's you accept in the machines you purchase. There may be an upcharge if it is not the OEM's preferred PLC but I believe it pays off in the long run


Posted by Thomas Ng on 26 July, 2002 - 10:44 am
I find a compelling argument is made by Alan Cooper (creator of VISUAL BASIC and winner of
a MICROSOFT Genius award) that programmers
should design with the average user in mind.
A great, non-technical argument is in his book,
THE INMATES ARE IN CHARGE OF THE ASYLUM. Try to
get your bosses to read it!
VB goes a great way towards implementing this for ordinary PC's. Wish we had the same for PLC's.


Posted by Michael Griffin on 27 July, 2002 - 4:05 pm
On July 26, 2002 11:58 am, Thomas Ng wrote:
<clip>
> I find a compelling argument is made by Alan Cooper (creator of VISUAL
> BASIC and winner of a MICROSOFT Genius award) that programmers
> should design with the average user in mind.
<clip>
> VB goes a great way towards implementing this for ordinary PC's. Wish
> we had the same for PLC's.
<clip>

Unfortunately, the "average user" seems to use Visual Basic to write programs which they (or their customers) can't maintain, or even get to run reliably in the first place. If someone wrote a good program in Visual Basic, they did it without any help from the language design.
Any problems I have seen in PLC programs pale to insignificance when compared to those which I have seen in typical Visual Basic programs. Making PLCs more like VB would be a big step *backwards*.

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


Posted by Anonymous on 26 July, 2002 - 11:16 am
Great question, it is a shame that the thread has become a battle ground for different programming styles.

I have been looking for just such a 'style sheet' to guide me in 'standardizing' my new programs and to make life easier when recieving new equipment.


Posted by Mohammed Moosa on 1 August, 2002 - 10:59 am
Dear Stephan,

A standard way of programming and a very user friendly one, which we have been using for so long is the Ladder Logic. This is a PLC programming structure. From my point of view I think this is the easiest and simplist way of programming.

regards,


Posted by Walter Swietlik on 16 August, 2012 - 12:48 am
Hello,

I totally agree there should be a rule or guide. However there is not any coding standard in place of any kind. However if you are interested in knowing how I do it email me back and I will share it with you for free.


Posted by Hal Popplewell on 30 August, 2012 - 1:08 pm
Please e mail it to me at hal@agentwaresystems.com. I've been trying to create a workable standard for quite awhile and this could probably help.

Thanks!


Posted by Bob Peterson on 30 August, 2012 - 7:02 pm
It has occurred to me that maybe a generic PLC code standard would be something that the people on this list could create for use by anyone that wanted it.

I wonder if anyone(s) with sufficient experience in actually writing PLC code might be willing to take on guiding such a task.

Personally, I would like to see not only a standard but maybe an appendix that explains why.

--
Bob


Posted by Ken E on 31 August, 2012 - 8:27 am
I think there should be documented standards, or more likely "design patterns" that people can fall back on. Most of the code I inherit needs to be partially or completely rewritten to be logical, predictable, and well designed code. Good programmers know what I'm talking about. Engineering vs. Hacking. It is bad when you have to tell your machine operators or your boss that you can't really fix the problem with the "other guys" code without upending tons of new bugs. It seems that many people don't understand the problem with spaghetti code, they just spackle on a new layer of ladder over the previous 3 layers. Some managers seem to only care about the immediate end result and the true problem of a code base that is unmaintainable is not apparent until much later after the "expert" has left to go to greener pastures.

I know it is not always possible with deadlines and people breathing down your back to fix things, but always strive to make your code consistent and easy to maintain, both for yourself and for others. Try to deal with your fault handlers consistently. Use data structures where you can, Name things consistently, and try to write your code so that it is self documenting (and only document the things that need documenting, like the reason you have that funky time delay at the end of the cycle where it shouldn't be necessary.....etc).

I was just yesterday dealing with a program someone else had written with an older PLC (predating the IEC and tag database style PLCs). Some faults where acknowledged/cleared by hitting the stop button when the machine was already stopped (The panel had limited buttons). Some other faults got cleared when they hit the run button. In the code the reset of all of the faults was dealt with in different areas of the program, and not in any logical manner. Relay assignments of the functions weren't in any consistent order and their comments were named inconsistently. There were about a dozen rungs of conditions just to start and stop the machine. There were relays setting relays that then set other relays making me have to juggle many complex rungs just to see how something simple was done like what happens when the operator hits the run button. I deleted most of it and will replace it with one or two simple rungs that will be documented and consecutive. A good programmer can take a complicated looking program and make it appear simple. Any idiot can make a complicated looking program. If anyone is starting out and reads this do yourself a favor and don't fool yourself into thinking complex=genius. Always strive to make your programs simple because one day your or your colleague will have to troubleshoot it and I can guarantee you that you won't remember that tricky tangled spaghetti mess of ladder in 5-10 years time.

Honestly, from what I've seen so far in this field I don't think any two people will agree on any standard way to do things. Maybe if there was a perceived "guru" or expert people would follow their advice, but I don't know if it would really happen. PLCs are just so very different from brand to brand the programming styles are just night and day.

KEJR


Posted by David Ferguson on 3 September, 2012 - 8:14 am
I couldn't agree more with this last post by KEJR, I have been trying to write a code and graphics standard for 20+ years. The best I can do is a standard for our company as any time I try to go beyond that.....too many "experts" get involved and I get nowhere. Most don't have a clue what they are talking about and inflict "opinion". As the customer I can control some of what gets written, as a supplier when trying to implement standards, everyone "thinks" they are experts and think "your standard" stinks......most haven't thought past the first layer of that onion.

As this poster says, shoot for naming conventions, document the he%# out of your code (usually to save you) even though time consuming, try to build a library of code and graphic snippets. I have old ladder chunks of reusable code for motors, valves, sequences, interlock diagnostics etc. And I have code chunks for the same stuff in modern controllers, ie objects for motors, valves etc that I just drop in, assign tags and code done.

But the "magic" is still in process knowledge and problem solving.....as said here, with any processors old code, a bad programmer can write "spaghetti" code. With new object oriented PAC's, nothing changed only now they can create code chunks, I can now write "ravioli" code if I want to.

The software programmers book from the 70's and updated in the 90's, "The Mythical Man Month, essays in software engineering" still has concepts for writing software that apply to control code.....simplicity, reusability, design, documentation etc. This is a must read for anyone doing any code....but that requires reading it.

What is the difference between an Artist and a painter......one does houses.

Dave Ferguson
Control Systems Engineer

Sent from my iPhone


Posted by Rob on 3 September, 2012 - 1:11 pm
Yes, there is a huge gap between writing Automation Software and Writing Modern IT applications. And unfortunately Automation Software is the area that is lagging a long long way behind the rest of the IT world.

Some very excellent programming methodologies do exist - Object Orientation, Agile, SCRUM, to name just a few - and these can be applied to developing Automation Software as well. (And we've had some excellent results doing just that).

At first glance, Object Oriented Design might seem a long way from writing a PLC program. But the reality is that something like a PID function Block is just a software "object" and it is surprisingly easy to use many of the ideas behind object orientation to design your software.

Unfortunately, a few posts on an automation board are not going to be enough - This subject really does require an entire book.

Rob
www[.]lymac.co.nz

http://en.wikipedia.org/wiki/Agile_software_development
http://en.wikipedia.org/wiki/SCRUM
http://en.wikipedia.org/wiki/Object_oriented_design


Posted by Luca Gallina on 3 September, 2012 - 5:14 pm
WOW, resuming a 10 years old thread...

I think there's more need of a "standard programming methodology" rather than simple "standard coding". There's not such a thing as a "standard" application nor a "standard" customer: it's the automation software that must adapt to the specific application, not the application to a "standard" PLC coding.

Standard libraries and functions seldom cover all applications' flavors and, trying to be all-inclusive, they tend to grow huge and difficult to maintain.

My way is to keep everything as light and neat as possible, and this means rewriting most of the code for each different kind of applications. The keys to keep it reasonably cheap are:

- accurate project engineering
- accurate software design
- dexterity with PC HIDs (namely keyboard an mouse) and developing environments shortcuts
- use of programming tools and aids external to the developing environment.

All things no school, no university nor programming courses teach you in any way.
At least as far as I know.


Posted by Ken Emmons Jr. on 4 September, 2012 - 9:44 am
Hi Luca,

I felt guilty replying to the more recent posts of this old thread, but I guess that goes to show how glacial progress has been in this field! :o)

I encourage you to try developing some Building-Block function blocks that you find yourself coding over and over again. I've done this and it really cuts down on the keyboard/mouse work if you can encapsulate functionality. Its always a trick to try and only develop functions in your library that you think you can re-use. Sometimes you paint yourself into a corner, but other times it can really save your bacon or save you time.

I do agree with your other points. A well designed system that is as lightweight as it needs to be is ideal. I've found that embellishments get in the way when you go back 10 years later.

KEJR


Posted by Ken E on 4 September, 2012 - 9:33 am
Dave,

It is good to know there are like minds out there. I'm starting to realize that without proper support from the top you can't expect to have consistent standards or consistent design patterns or philosophies or whatever you might call them. I think good managers should be checking the code, but then many managers can't read the code. I partly blame the mentor process (or lack thereof). Does this ring true with what others are seeing at their companies?

I like my Ravioli, but I find the code still gets written in spaghetti even with modern Object Oriented IEC 61131 style PLCs. I think it definitely helps and I've written a library of routines that should help to lessen some of the bad code in the future. Lately I've been maintaining old C++ and "traditional" ladder projects since the systems are older and more people have come and gone and left me with their legacy. BTW, I love Italian food, just not in my programs. :o)

I will check out that book. I am mostly an automation guy, but I do write some C/C++/C# code and I think I am really a closet Software Engineer. I noticed it is available on the nook.

I have heard the artist analogy before and even to the excuse that "I prefer to do it *my* way", as if Engineering as a career is some kind of grand creative outlet (I am a creative person at heart, but I get paid to do Engineering). In some senses I have an understanding of that viewpoint because I think I would have a hard time if someone dictated to me how to program. On the other hand I do find myself seeking others that are true experts (through books or forums) and solicit their style and philosophies. Maybe that is the difference?

At the end of the day I think it is difficult for all of us Automation Geeks (I use that term with honor) because we are asked to wear so many hats. I can't speak for others but I find myself writing modern ladder, ancient ladder, HMIs in C#, database work, Electrical Schematics, Advice and debug on mechanical design, process troubleshooting, selecting sensors, vision systems, motion control.... It just seems to go on and on these days. No wonder things get butchered.

Still, when your program consists of a 5 step sequence and it is spread out of order over 15 pages of butchered ladder you have to ask why? Did they just not know it could be 5 rungs? More and more I wonder if some of these people get off by over complicating things, which is sad.

KEJR


Posted by Cervantes on 20 September, 2012 - 8:37 am
IEC 61499 may be something for you to look into. Loytec released a working IEC 61499 system targeting building automation. You could maybe look there or possibly something on a website called holobloc (I think).


Posted by Sangmin Lee on 26 November, 2012 - 4:47 am
All,

> It has occurred to me that maybe a generic PLC code standard would be something that the people on this list
> could create for use by anyone that wanted it.

I work for a company that provides automatic PLC static analyzer that reviews PLC programs automatically and alerts and warns if there is any issue with coding styles, complexity, dead codes, etc. You can find more information at http://www.automationsquare.com/plc-checker.html. You can also contact me at sangmin.lee@automationsquare.com. I can also send you a PLC programming guideline which you can refer to when setting up your own PLC coding standard.

Thanks
Sangmin

Your use of this site is subject to the terms and conditions set forth under Legal Notices and the Privacy Policy. Please read those terms and conditions carefully. Subject to the rights expressly reserved to others under Legal Notices, the content of this site and the compilation thereof is © 1999-2014 Nerds in Control, LLC. All rights reserved.

Users of this site are benefiting from open source technologies, including PHP, MySQL and Apache. Be happy.


Fortune
Once, adv.:
Enough.
-- Ambrose Bierce, "The Devil's Dictionary"
Advertise here
Advertisement
our advertisers
Help keep our servers running...
Patronize our advertisers!
Visit our Post Archive