Advice needed for learning how to properly write plc code for machine control

SilverLoop

Member
Join Date
Oct 2002
Posts
87
i would like some advice from those who write plc code for machine control. i am very new to plc programming and have looked at a lot of code that others have written.

it is difficult to really know if the sample code i have seen even works well because there are few comments and there does not seem to be a "flow" to the programs because of all kinds of latching/unlatching instructions, timers, and one shots.

i was wondering if there is a source where i can look at sample programs that perform relatively few operations for a simple machine and are easy to follow?

i am thinking of something like a machine that has a few conveyor belts and a few proximity switches that could be used to detect parts being conveyed through various "stages" of the machine.

i realize that you learn more and more by just writing code, but i want to start with a good basis for breaking code into manageable parts and would like to follow techniques that others have found to work.
 
Last edited:
i realize that there is no set way to write a plc program, but surely there are some ways to break code down that are generally accepted as good practices. in the same way, surely there are generally accepted practices to writing code for machine control.


i am familiar with most instructions and can usually figure out how to use others from help files, but i would like to be able to go from a very detailed theory of operation that i wrote for the functionality of a machine to a program that truley does what it was intended.
 
The most important steps you take in creating good logic are those taken before you start writing the program. They include:

A good point list, with signal levels, ranges for analog I/O, and addresses for each point

A list of alarm functions, including the events that trip an alarm and the actions taken as a result of an alarm, such as alarm horn, stopping the machine, etc.

A list of operator adjustable parameters required, such as time delays for alarms, process limits, etc.

A list of operator data displays on the HMI if you have one

A text description of the principal functions of the system, including objectives, production rates, communications requirements, etc.


After you have all of this you can organize your logic into blocks to satisfy each function and control loop. Then you can start writing code, using all of the previous information as a check list to insure you are meeting your goals. Use lots of comments, clear descriptions and tag names, and avoid thingsl like one shots, jumps, and set/reset functions that are hard to view and debug.
 
When writing new code I generally use the concept of a state machine to organize how my sequence or process works.

1. State machines have states and transitions
2. When system is in a particular state it performs actions, i.e. in a "fill" state a valve might open for a period. A state following it might be "end filling", which closes the same valve.
3. The system transitions between states based on inputs or internal state conditions. For example, the "end filling" state might complete when the valve closed feedback comes on, or if it fails to come on in a reasonable time the system might transition to a fault state.

Note that while state machines make code easier to document and troubleshoot (especially for complex code or machines) there is a lower limit below which they are too much trouble.

State machines are especially nice in that you can design the function of a machine using diagrams and then code to that diagram (or list, whichever works).

General note -
It is a bad habit to start coding too soon when desigining a machine. Good program designers don't touch code until they have know their machine, understand the sequence and can document this in a way they can use while amongst the heat and noise of coding. In a way, it's the reverse of the traditional engineering 20/80 rule - rather than spending 80% of your time designing and 80% building it's more like the reverse. Spend the bulk of your time planning how things should work and the actual business of coding should be relatively short.

One standard way of representing state machines is sequential function chart, which I find very easy to follow. Check out (admittedly poor) example here.
 
Tom Jenkins said:
The most important steps you take in creating good logic are those taken before you start writing the program. They include:

A good point list, with signal levels, ranges for analog I/O, and addresses for each point

A list of alarm functions, including the events that trip an alarm and the actions taken as a result of an alarm, such as alarm horn, stopping the machine, etc.

A list of operator adjustable parameters required, such as time delays for alarms, process limits, etc.

A list of operator data displays on the HMI if you have one

A text description of the principal functions of the system, including objectives, production rates, communications requirements, etc.


After you have all of this you can organize your logic into blocks to satisfy each function and control loop. Then you can start writing code, using all of the previous information as a check list to insure you are meeting your goals. Use lots of comments, clear descriptions and tag names, and avoid thingsl like one shots, jumps, and set/reset functions that are hard to view and debug.

this is actually where i am at. the last time i worked with plcs was three years ago. i mostly write code these days for database applications. i took a project that someone did not have time to complete themselves. it is a new machine that is currently being built.

i was told that there was a similar machine and that i could use that program as the basis and merely "cut and paste" to save time. that definitely was not the case! the code is cryptic and i can hardly make an sense out it because i have never seen that other machine and do not have the electrical drawings for it to really understand that code.

there are 14 separate "stations" to this new machine and the first thing i asked the customer for was a "theory of operation". i was given a very strange look and was told that none existed. i then told the customer that i would have to write one myself. the customer went through the machine station by station in an attempt to explain how it worked. i have been spending quite a bit of time translating these notes into a very detailed theory of operation that includes all the I/O and exactly what i think everything should do. i have been breaking the theory of operation into each station and have forwarded these to the customer and tried to explain that they MUST read what i have written very carefully and agree to it because that is going to be the basis for the program. at first the customer thought i was just wasting time with needless documentation.

at this point my theory of operations suggest how each station will be broke down and it seems to have a nice flow that would work well for a "sequence" for each station. i just hope i can truly translate this to plc code now!

the customer may not like it, but as you say i will also need to have the same kind of detailed document for alarms, because i have no idea at this point what they constitute as an alarm for each and every condition!
 
Binaural said:
General note -
It is a bad habit to start coding too soon when desigining a machine. Good program designers don't touch code until they have know their machine, understand the sequence and can document this in a way they can use while amongst the heat and noise of coding. In a way, it's the reverse of the traditional engineering 20/80 rule - rather than spending 80% of your time designing and 80% building it's more like the reverse. Spend the bulk of your time planning how things should work and the actual business of coding should be relatively short.

One standard way of representing state machines is sequential function chart, which I find very easy to follow. Check out (admittedly poor) example here.

This is great advice. I had the bad habit of being too anxious to start writing code which proved inefficient in the long term. Live and learn.
 
An example of what not to do:

I just finished working on a machine where the state bits were latched and unlatched all over the place in the routines. I have run across this a few other times through the years also. This kind of logic is very hard to troubleshoot when you don't know the machine like the back of your hand. I had to add a lot of traps in the program to figure out what was causing motors to stop, valves to close, etc.

I generally have a simple rung that seals itself in for controling a device, and I expand on the bits used to conrol the device in another rung. This way I can monitor one rung and see which leg of the logic caused the device to change state, then go to the rung that derives that bit for troubleshooting.

This is advice for a pretty specific problem instead of a broad how to, but it is high on my pet peeve list at the moment.
 
jtn said:
An example of what not to do:

I just finished working on a machine where the state bits were latched and unlatched all over the place in the routines. I have run across this a few other times through the years also. This kind of logic is very hard to troubleshoot when you don't know the machine like the back of your hand. I had to add a lot of traps in the program to figure out what was causing motors to stop, valves to close, etc.

I generally have a simple rung that seals itself in for controling a device, and I expand on the bits used to conrol the device in another rung. This way I can monitor one rung and see which leg of the logic caused the device to change state, then go to the rung that derives that bit for troubleshooting.

This is advice for a pretty specific problem instead of a broad how to, but it is high on my pet peeve list at the moment.

this is what i have found in the program that was given to me as as an example. in looking at the code it makes me even wonder if it actually worked.

it sounds like what you are suggesting is the kind of approach that i would like to take. use my theory of operation to develop the sequence logic first, then use that sequence logic to go back to the individual devices (motors, solenoids, etc.) to change their state to support the conditions needed in the sequence.

i would like to develop code that is not scan dependent. at this point though i am not sure how to handle interruptions to the sequence logic and avoid unintentional restarts of motors.

i have not really seen good examples of this approach yet.:(
 
Last edited:
In the appendices of the Allen Bradley PLC-5/0x instruction set reference there are examples of basic programs which illustrate certain concepts. The programs are tied to a hypothetical machine which is to be controlled. The programs are small, as befitting examples, but they contain the germs of larger, more sophisticated projects.

Finding out what the machine is to do and how it will know this (inputs) and accomplish it (output) is an excellent start.
 
Doug-P said:
In the appendices of the Allen Bradley PLC-5/0x instruction set reference there are examples of basic programs which illustrate certain concepts. The programs are tied to a hypothetical machine which is to be controlled. The programs are small, as befitting examples, but they contain the germs of larger, more sophisticated projects.

Finding out what the machine is to do and how it will know this (inputs) and accomplish it (output) is an excellent start.

where may i find such examples for RSLogix5000?
 
start simple

The easiest way for me to write PLC logic is to start with over simplified logic. "push button=Motor to energize"
 SOR XIC I:001/1 OTE O:001/1 EOR 


then as the system progresses so does the logic.
"push button=motor energized" unless "photo eye=0" or "no product" what ever the statement might be.
 SOR XIC I:001/1 XIC I:001/2 OTE O:001/1 EOR 


I know this sounds over simplified but it is the method I use for ladder logic and RSveiw/WW scripts. I has helped me avaid missing steps or overlooking simple functions.
 
i have the book that is being sold on this site and it is good for introducing plcs.

if someone were to put together a compilation of small projects into a book, i am sure that would be of interest to a lot of people. what i mean is something like a "plc project cookbook" that would show a couple of small projects and how to proper build them from beginning to end. it could show how to properly develop the documentation needed in the beginning before any code is written and then how to translate this into code that is easy to debug and turn over to other people. commonly used devices such as motors, limit switches, proximity switchs, estops, vfds...etc could be used to illustrate proper control. finally, the use of an hmi could be illustrated. i suppose the difficulty in something like that is not to have something so geared toward a specific plc manufacturer.

i have the book "Programmable Controllers: Theory and Implementation" by Bryan and Bryan. it is basically a 1000 page door stop.
 
SilverLoop said:
where may i find such examples for RSLogix5000?
I can't speak to the 5000 series but the one mentioned is online at A-B's site under "manuals online".
 

Similar Topics

Hello PLCS nation, I am a newbie hoping you can point me in the right direction in starting my journey. I work for a company that has several...
Replies
11
Views
3,063
Hi I'm immensely glad to be here with wonderful people like you all. I'm new in this interesting field but I need an advice. I'm a young...
Replies
3
Views
2,434
Hello gents, I've started with Siemens PLC's about 10 years ago and worked with Step7, TIA Portal and am now involved with PCS7. The PLC's I...
Replies
7
Views
2,636
Hi I have a potential project , we have 5 lines with all Allen bradley 2 lines with compactlogix and 3 x slc plc , I have been asked to look...
Replies
11
Views
4,627
I'm testing a new application before downloading it to the HMI installed on the line and I'm getting a write attempt error. Write attepmt for...
Replies
5
Views
2,227
Back
Top Bottom