Updated PLC Book on-line

H

Thread Starter

Hugh Jack

My PLC based controls course wrapped up a couple of weeks ago so I updated the manuscript for the book and posted the new manuscript on-line.
http://claymore.engineer.gvsu.edu/~jackh/plcbook.html
The purpose of the book is to explore PLCs by examining AB PLCs in depth. The book is about 90% complete at this point so I would appreciate any feedback offered.

Thanks,

Hugh
 
It might be helpful if the school would provide you with a more recent copy of acrobat. Your .pdf files were looking for 2.0, which I have, but it gave me an error saying no master font found. Try converting to 4.0 or something.
 
I just glanced over a little so far, while looking for info on SFC's. I noted in the SFC chapter the conversions to Ladder Logic use Latch and Unlatch coils. You may be interested to know that in a couple of employment interviews I've had lately, within GVSU's area of operation, that the interviewers inspected the sample code I'd broutght with me specifically looking for L's and U's. And they did not want to see them used. Unfortunately I wasn't able to find out why.

Doug
 
J

Joe Jansen/ENGR/HQ/KEMET/US

"Unfortunately I wasn't able to find out why."

Because anyone who has had to troubleshoot a poorly written
program has had to suffer.

Imagine, for a minute if you will, a program that's been sitting
in a machine for several years with various fingers twiddling
with it.

Now imagine trying to troubleshoot that code where the problem
of interest is driven by L's and U's distributed throughout
several hundred rungs of logic, with little documentation
or sense of logic flow.


I have seen things far more difficult to trouble shoot than (L) and (U).
Off the top of my head, I would put indirect and offset addressing as #1 on
the list. And yet, I continue to use it. Why? because it is a powerful
means to accomplish data logging and storage *without* a lot of confusing
code....

Likewise, I continue to use (L) instructions where they are appropriate.
One of the best places for this is in alarming. Typically, I want a set of
conditions (ie: output on and position sensor not on) to run a timer (5
sec). If the timer times out, go thru a one shot rising bit to a (L)
output. This causes the alarm to go off, and stay true until acknowledged
by the operator thru a button press on touchscreen, or whatever.

These bits are grouped by word into catagories. Workstation A alarms are
all B3:1/ 0-15, for example. If B3:1 is non-zero, I know I have a
workstation A problem. The operator can quickly check, hit the alarm reset
(move 0 into the B3:1 word), and continue on. If I tried writing this
without using (L) and block moves, it would require twice as much code, and
be harder to follow. As is, all the alarms occur in a seperate file, and
the rungs are nearly identical, one after the other. This also makes it
easy to trouble shoot alarming problems by quickly scanning the program
file online.

All alarm reactions/resets are handled in the operator interface area of
the program. Again: Clean, no muss, no fuss.

In my opinion, any one who refuses to use the processor to it's full
potential, just because they have deemed that such-and-such instruction is
not "proper" is losing out on what their machines are capable of. It takes
more lines of logic to code it without the (L) and (U) instructions, so
theoretically, (L) and (U) should simplify readability.


Whether it does or not depends completely, like everything else in
programming, on the skill of the programmer.


--Joe Jansen
 
A

Anthony Kerstens

"Unfortunately I wasn't able to find out why."

Because anyone who has had to troubleshoot a poorly written program has had to suffer.

Imagine, for a minute if you will, a program that's been sitting in a machine for several years with various fingers twiddling with it.

Now imagine trying to troubleshoot that code where the problem of interest is driven by L's and U's distributed throughout several hundred rungs of logic, with little documentation or sense of logic flow.

Also, consider the following excerpts from the RSLogix 500 online help.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Warning! If an error condition occurs that halts processing, the physical output will be turned off. But once the error condition is cleared the controller will resume operation with the OTL in the state determined by its data table value.

Note: In the event of a power loss, any OTL controlled output device will energize with the return of power if the OTL bit was set when power was lost.

Rockwell Software 2000
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

If L's are improperly used, they could result in unexpected machine operation after the clearing of a fault, or power-up without operator intervention (i.e.. pressing a PB).

I view L's and U's as a last resort in programming. They should only be used when you need a bit to be retentive, and where they _cannot_ initiate machine operation.

Anthony Kerstens P.Eng.
 
B

Bruce Durdle

One problem with the use of L and U coils is that it is posible to have an activated L set a coil, then use that coil in its on condition, then
somewhat further down the ladder activate a U on the same coil. Any further use of the coil will find it off. As a consequence, it is possible to
(apparently) have the "same" coil both ON and OFF at the same time.

If you are going to use L and U (S and R) then it is good practice to make sure the L (S) and U (R) coils are in adjacent rungs. The dominant mode (ie
which one wins if both L and U are activated at the same time) also depends on which is last in the ladder - and any "feature" that can change its
action depending on order of solution of rungs is not good.

JMHO

Bruce.
 
Hello all,

> I view L's and U's as a last resort in programming. They
> should only be used when you need a bit to be retentive, and
> where they _cannot_ initiate machine operation.
>
> Anthony Kerstens P.Eng.

AAAAAAA Men!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

> > .... the interviewers inspected the sample code I'd brought with me
> > specifically looking for L's and U's. And they did not
> > want to see them used. Unfortunately I wasn't able to find out why.
> >
> > Doug

They were probably concerned about machine safety and reliability.

Bradley G. Hite
Intertech Inc.
mailto:[email protected]
http://www.myplc.comTeaching Practical Skills for a Technological World
 
M

Michael Griffin

At 16:32 07/08/01 -0400, Anthony Kerstens wrote:
<clip>
>"Unfortunately I wasn't able to find out why."
>
>Because anyone who has had to troubleshoot a poorly written
>program has had to suffer.
>
>Imagine, for a minute if you will, a program that's been sitting
>in a machine for several years with various fingers twiddling
>with it.
>
>Now imagine trying to troubleshoot that code where the problem
>of interest is driven by L's and U's distributed throughout
>several hundred rungs of logic, with little documentation
>or sense of logic flow.

I don't think that eliminating latch/unlatch instructions really solves very much. This is addressing a symptom, not the actual problem. If someone is going to make a mess out of a program, they'll make a mess of it
no matter what rules you make. I would like to point out that if you are depending upon sealing contacts to hold a state, that the logic which breaks the seal can also be "distributed throughout several hundred rungs of logic".

Latch/unlatch instructions can in many instances allow logic to be presented more clearly by allowing you to write the "latch", "conditional logic", "unlatch" rungs in sequence.

One of the genuine weaknesses of ladder logic is that it provides no inherent means of grouping related logic (especially sequences) together. One of the methods used to address this problem (bit latching) depends heavily upon well, latching (and unlatching) bits.


>Also, consider the following excerpts from the RSLogix 500
>online help.
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>Warning! If an error condition occurs that halts processing,
>the physical output will be turned off. But once the error
>condition is cleared the controller will resume operation with
>the OTL in the state determined by its data table value.
>
>Note In the event of a power loss, any OTL controlled output
>device will energize with the return of power if the OTL bit
>was set when power was lost.
>
>Rockwell Software 2000
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>If L's are improperly used, they could result in unexpected
>machine operation after the clearing of a fault, or power-up
>without operator intervention (i.e.. pressing a PB).

"Power-up without operator intervention?" Isn't power-up of a machine always under hard-wired control? There isn't anything your program
is going to do which will affect this.
Perhaps you meant logic initialisation on power-up or restart of the PLC. This however has to be handled in your logic anyway, and not just for latch or unlatch instructions. I have in addition learned that certain models of PLC will occasionally power up with random values in parts of their supposedly non-retentive memory areas, and so cannot be trusted to initialise themselves to a zero state on start-up.


>I view L's and U's as a last resort in programming. They
>should only be used when you need a bit to be retentive, and
>where they _cannot_ initiate machine operation.
<clip>

This last sentence though seems to permit latch/unlatch almost everywhere, and then forbid it almost everywhere. On the one hand, almost
any bit can need to be "retentive" in some sense. On the other hand, almost any bit could possibly "initiate machine operation" under the right circumstances (you would have to analyse the program very carefully to ensure that it doesn't).

If the objective is to prevent bad programming, then I think that specifying a list of things *not* to do is the wrong approach. Too many customer specifications (of various sorts) are written this way. If I were to compile a list of reasons for unreadable and unmaintainable programs, misuse of latch and unlatch instructions would be down near the bottom. I am
sure indeed that I could find enough examples of bad programs to prohibit virtually everything.

Rather I think good programming should be encouraged by specifying the way things *should* be done, and providing clear examples of what is
considered exemplary programming. A positive example provides a guide to what is wanted, rather than leaving this to the imagination.


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

Rick Jafrate

Anthony and Michael,

This thread kind of touched a nerve and I would just like to add my thoughts. Please don't think I am being overly critical of you. I think we are all complaining about the same things.

Michael Griffin wrote:

> Anthony Kerstens wrote:
> <clip>
> >"Unfortunately I wasn't able to find out why."
> >
> >Because anyone who has had to troubleshoot a poorly written
> >program has had to suffer.
> >
> >Imagine, for a minute if you will, a program that's been sitting
> >in a machine for several years with various fingers twiddling
> >with it.
> >
> >Now imagine trying to troubleshoot that code where the problem
> >of interest is driven by L's and U's distributed throughout
> >several hundred rungs of logic, with little documentation
> >or sense of logic flow.
>
> I don't think that eliminating latch/unlatch instructions really
> solves very much. This is addressing a symptom, not the actual problem. If
> someone is going to make a mess out of a program, they'll make a mess of it
> no matter what rules you make. I would like to point out that if you are
> depending upon sealing contacts to hold a state, that the logic which breaks
> the seal can also be "distributed throughout several hundred rungs of logic".
>
> Latch/unlatch instructions can in many instances allow logic to be
> presented more clearly by allowing you to write the "latch", "conditional
> logic", "unlatch" rungs in sequence.
>
> One of the genuine weaknesses of ladder logic is that it provides no
> inherent means of grouping related logic (especially sequences) together.
> One of the methods used to address this problem (bit latching) depends
> heavily upon well, latching (and unlatching) bits.

Another genuine weakness of ladder logic is the clumsy way that it handles sequential logic (i.e. logic with memory state, i.e. latch, unlatch, seal, etc...). I think that this is what this thread is actually about.

Ladder logic is well suited to perform combination logic (i.e. AND, OR, etc.). A ladder program containing sequential logic of significant
complexity is almost certainly a nightmare for anyone trying to diagnose, understand, maintain, it etc... It has been my observation that few PLC
programmers do any kind of state analysis or design before they begin "programming". Many frequently deny that their program even has any
states when, in fact, it most certainly has; they just don't know it.

> >Also, consider the following excerpts from the RSLogix 500
> >online help.
> >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >Warning! If an error condition occurs that halts processing,
> >the physical output will be turned off. But once the error
> >condition is cleared the controller will resume operation with
> >the OTL in the state determined by its data table value.
> >
> >Note In the event of a power loss, any OTL controlled output
> >device will energize with the return of power if the OTL bit
> >was set when power was lost.
> >
> >Rockwell Software 2000
> >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> >If L's are improperly used, they could result in unexpected
> >machine operation after the clearing of a fault, or power-up
> >without operator intervention (i.e.. pressing a PB).
>
> "Power-up without operator intervention?" Isn't power-up of a
> machine always under hard-wired control? There isn't anything your program
> is going to do which will affect this.
> Perhaps you meant logic initialisation on power-up or restart of the
> PLC. This however has to be handled in your logic anyway, and not just for
> latch or unlatch instructions. I have in addition learned that certain
> models of PLC will occasionally power up with random values in parts of
> their supposedly non-retentive memory areas, and so cannot be trusted to
> initialise themselves to a zero state on start-up.

If you are trying to initialize a program, on power-up (or parts of it) based on states that were valid before the machine was powered down you are, in my opinion, looking for trouble and will end up with an application that is sure to mis operate.

In this situation there is no way of knowing how long the machine was without power and what events may have taken place during that time. The internal variables inside a program represent things in the realworld. Just because some equipment was in a particular position or state before power was lost does not mean that it will be in the same state/position when power is restored. How would a program know that a millwright used a chain hoist to move some equipment around so that he could do his job?

My practice has always been to take nothing for granted on power-up. Analyze the initial conditions and transition to an appropriate state.

> >I view L's and U's as a last resort in programming. They
> >should only be used when you need a bit to be retentive, and
> >where they _cannot_ initiate machine operation.
> <clip>
>
> This last sentence though seems to permit latch/unlatch almost
> everywhere, and then forbid it almost everywhere. On the one hand, almost
> any bit can need to be "retentive" in some sense. On the other hand, almost
> any bit could possibly "initiate machine operation" under the right
> circumstances (you would have to analyse the program very carefully to
> ensure that it doesn't).
>
> If the objective is to prevent bad programming, then I think that
> specifying a list of things *not* to do is the wrong approach. Too many
> customer specifications (of various sorts) are written this way. If I were
> to compile a list of reasons for unreadable and unmaintainable programs,
> misuse of latch and unlatch instructions would be down near the bottom. I am
> sure indeed that I could find enough examples of bad programs to prohibit
> virtually everything.
>
> Rather I think good programming should be encouraged by specifying
> the way things *should* be done, and providing clear examples of what is
> considered exemplary programming. A positive example provides a guide to
> what is wanted, rather than leaving this to the imagination.
>

The only way to prevent bad programming is to eliminate bad programmers. If we are not willing to go to that extreme then Michael's suggestion above would be my next choice.

regards

Rick Jafrate
Mitek
 
A

Anthony Kerstens

Michael,

Let me start by saying my post was a response to another poster who said "Unfortunately I wasn't able to find out why." Since my preference is also to not use L's and U's, I offered an answer.

Now....

> Latch/unlatch instructions can in many instances allow logic to be
> presented more clearly by allowing you to write the "latch", "conditional
> logic", "unlatch" rungs in sequence.
.....
> One of the genuine weaknesses of ladder logic is that it
> provides no
> inherent means of grouping related logic (especially sequences) together.
> One of the methods used to address this problem (bit latching) depends
> heavily upon well, latching (and unlatching) bits.

We have a difference of _opinion_ on programming style. I prefer to use plenty of documentation in my logic to segregate sections of code and memory (as well as make use of AB's file provisions, when programming AB).

I manage to create complex, yet highly organised programs in this manner, and so I neither see a need nor do I prefer to use L's and U's.

> >If L's are improperly used, they could result in unexpected
> >machine operation after the clearing of a fault, or power-up
> >without operator intervention (i.e.. pressing a PB).
>
> "Power-up without operator intervention?" Isn't power-up of a
> machine always under hard-wired control? There isn't anything your program
> is going to do which will affect this.

Yes. Power-up and estop are hard-wired. Unfortunately, the use of L's and U's requires that nobody is going to mess with your logic. I don't have that much faith. Leaving control logic as non-retentive bits is an additional assurance to myself that the system will be predictable (not
moving) after power-up and reset.

> >I view L's and U's as a last resort in programming. They
> >should only be used when you need a bit to be retentive, and
> >where they _cannot_ initiate machine operation.
> <clip>
>
> This last sentence though seems to permit latch/unlatch almost
> everywhere, and then forbid it almost everywhere. ....

In other words, permitted only for data logging and other functions that do not control physical outputs. Even there I don't like it, but might
be willing to accept it as a "last resort".


> If the objective is to prevent bad programming, then I think that
> specifying a list of things *not* to do is the wrong approach. >

The objective is to make reliable and predictable systems. To achieve this, part of my "approach" is to not use L's, mainly because I cannot bring
myself to trust what other people may do in the future.

Anthony Kerstens P.Eng.
 
J

Jacek Dobrowolski

Joe Jansen wrote:

&lt;snip>
In my opinion, any one who refuses to use the processor to it's full potential, just because they have deemed that such-and-such
instruction is not "proper" is losing out on what their machines are capable of.
It takes more lines of logic to code it without the (L) and (U) instructions, so theoretically, (L) and (U) should simplify readability.

Whether it does or not depends completely, like everything else in programming, on the skill of the programmer.

&lt;snip>

Bingo !

Main causes of an erratic operation of machines are poor programmers.

Best regards

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

Jacek Dobrowolski

Anthony Kerstens wrote:

&lt;snip>
Yes. Power-up and estop are hard-wired. Unfortunately, the use of L's and U's requires that nobody is going to mess with your logic. I don't have that much faith. Leaving control logic as non-retentive bits is an additional assurance to myself that the system will be predictable (not
moving) after power-up and reset.

&lt;snip>
&lt;snip>
The objective is to make reliable and predictable systems. To achieve this, part of my "approach" is to not use L's, mainly because I cannot bring myself to trust what other people may do in the future.
&lt;snip>

Dear Anthony

In such a case you shouldn't write any control programs or some half-brained whoever can always mess with your logic and make a machine dangerous.

Best regards

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

Anthony Kerstens

Sarcasm aside...

Part of the requirements in most industrial applications is that maintenance staff must be able to access and troubleshoot systems. The result of troubleshooting may be the modification of logic by personnel who do not regularly design systems.

My personal preferences in programming style can be likened to cutting a loose thread short rather then waiting for the whole thing to unravel.

Anthony Kerstens P.Eng.
 
J

Joe Jansen/ENGR/HQ/KEMET/US

An interesting point. I have found, however, that spending extra time on the HMI, alarming, operator notification and information screens, etc. has enabled me to build systems that maintenance techs typiaclly don't need to access the control logic. I find that nearly anything that they can divine from the logic can also be told to them in a more controlled method.

Now I will admit that HMI design is one of my "pet projects" that I probably spend more (personal -- ack!) time than is typical, but it has allowed me to keep well intentioned but uninformed/untrained maintenance personnel from having to access/modify my code.

To continue what Anthony has said, my style is to keep all events monitored and reported to operators. If I tell a cylinder to extend, for example, I watch for the extended sensor to come on. If it fails to within an appropriate time period, Put an alarm up. I like using posterized graphics of the machine (tho I did one using pics from my digital camera &lt;grin>) that redden the area in question. Touching that portion of the image brings up a message ("Cylinder did not extend"). If the operator cannot understand that, touching the text brings up a detailed checklist of items. These would be things like checking the cylinder for obstruction (remember
to E-Stop!), check the light on the sensor for operation, etc. The last item on the list is always call maintenance. Maintenance has been properly trained to look for air leaks, valve problems, and other electro-mechanical trouble.

Point being, the machine should never, never, never just stop. If normal cycle is interrupted, the operator should be told why. On small devices
such as a conveyor indexer run by a micrologix with no operator interface, I will pass data through data highway, devicenet, or whatever network, to the next machine, and use it's operator interface.

I find that all the operators I have worked with prefer this method to having the machine stop, call maintenance, who also doesn't know why it
stopped because the machine isn't telling them anything either. Then Maintenance gets the 20 yr old computer-on-a-cart, searches for the program
on a floppy somewhere. gets online....... You know the drill. The operators are more than happy to correct what they can and get the line
back up and running without having to call anyone if they can help it.

&lt;soapbox off>

--Joe Jansen
 
Good points.... Everybody should do it and it starts with the design of the system to achieve good diagnostics and make it unnecessary for anyone to have to access the software. Sometimes one or two devices make a big difference to the diagnostic capability and as Joe said it can often eliminate a maintenance call. It also
allows the operator to inform maintenance of the nature of a fault so they can come prepared with the right spare/s and equipment.

Providing the facility for maintenance or operators to change values such as timer presets etc is another way of eliminating the need for software access and speeding up commissioning. I just completed a little Micrologix 1000 program and put the Microview panel on it. Limits should always be set when facilities are provided to change internal settings. The Microview itself allows the limits to be set so they don't have to be programmed. There should always be one button that resets all values to defaults. Some of the changes are password protected.... only maintence see those in "maintenance" mode.

We should all make HMI a "pet project".

Vince Dooley


 
D
I have used L/U bits for several years and have been succesful with them in machine operation, HMI, communications, etc.

It seems the big question is machine safety and unexpected operation. This is managed well in laying out the internal latched bits to copy a "0" (N7:) to the words used for latching at processor first pass. If you have latched outputs copy "0" to the word for all outputs. You can compare the unlatched word with "0" and set a MCR (AB) for continue operation.

I feel using the L/U gives better understanding of a system that has mutiple sequences of operations while using the same physical outputs with less logic.
Also if you need an output high at start up or after a defined e-stop, you can do a mask to L the desired bit(s).

The bottom line - does the machine perform the task, is it easy for maintenace to follow, using a HMI - is the machine self diagnostic, will it recovery properly and safely under all known conditions, and most of all will it be safe under all known and unknown conditions.

Don Bennett
Controls Engineer
 
Top