Can anyone give me some keypoints on how to construct ladder diagrams?

ronpittc

Member
Join Date
Jun 2003
Location
San Francisco CA
Posts
13
Hi there, im reading some ladder diagrams and i know pretty well how they work, but sometimes i find it hard to construct one... im thinking maybe there are certain steps in making them like a techniques....bec. sometimes they give me some examples and they just give me the operating manner Ex:

- Once the START button is pressed, a 'start' indicated light will be on to indicated the counting sequence of up to 10 is in progress.

- A "finish" indicator light will be activated after the process of counting is completed.

- the circuit should incorporate an Emergency stop buttton to stop the counting operation.


Please show me how to construct it, its really confusing.. im thinking if you guys have any effective techniques or steps on constructing ladder diagrams Thanks
 
You should try to get a basic understanding of electrical relay logic and the fact that in relay logic, current flows from left to right through each "rung" and that is why ladder logic is set up the way it is.
 
You've outline the basics with you sequence of operation, so now you just have to 'explain' that to the PLC. That's what the ladder diagram will do.

Your explanation sounds simple enough, but the PLC will have some 'questions'... :unsure:

  • "Are you saying that the 'start' light controlled by the START PB, or by the COUNTER, or BOTH?"

    "Is the START PB held down continuously, or just pressed momentarily?" and "If momentarily, what should I do is some bozo holds it down continuously?"

    "At the start of cycle, should I turn on the IN PROGRESS LIGHT immediately, or wait until the counter has counted to at least '1'?"

    "When the EMERGENCY STOP PB is pressed, do I see that as ON, or OFF?"... "Same for the START PB?"

    "If the EMERGENCY STOP PB is pressed, should I 'remember' the current count, or start again at zero?"

    "If the EMERGENCY STOP PB is pressed AFTER the process of counting is complete, should I leave the FINISH lamp illuminated?

    "On what event should I increment the counter?"

    "Where will I get this 'number to count to' from?"

    "What should I do if that number is greater than 10?" and "Could it be less than 1?"

    ....

Once you answer these preliminary questions, the PLC will probably have LOTS MORE! It's method of questioning will be by not working as you expected it to, but by working E-X-A-C-T-L-Y as you TOLD it to!... :nodi:

That's called "debugging"... :D

Remember, the PLC can not read your mind. As Terry says, "BE THE PLC", and you will understand how IT sees 'the outside world'... (n)
 
Ron my boy you are asking for far too much for this forum. They have PLC classes and instructors that get paid for such things. If you choose not to shell out the bucks for formal training then you will need to take advantage of the FREE information and advice on the Internet but you will need to STUDY. We can’t force feed the knowledge.
The terminology ladder & rung are used because like the rungs of a conventional ladder you logically step to you destination one rung at a time.
Logically, on the conventional ladder, if you wanted to go to the roof you would proceed UP one rung at a time but if you did something not logical such as step to the left, right or down then the outcome is going to be something other than what you wanted.
That is how you want to construct your ladder program, logically one step at a time, rung by rung until you have arrived at your destination. How logical your logic is will improve with STUDY and PRACTICE.(maybe)

Clear as mud, huh?
Roger
 
The term "ladder logic" comes from ladder diagrams that electricians and instrument technicians use for troubleshooting and wiring. When they came up with the concept of the PLC they had to figure out how to make this technological transition without loosing the older group of engineers and technicians still in the workforce. Since both the engineers and technicians were familiar with "relay ladder logic" they decided that this would be the key to educating the new guys while at the same time making it somewhat painless for the older guys to learn. Learn relay logic and the rest will come. :)
 
im pretty good in ladder diagrams and PLC :)

hi probably you mis-interpreted me, im really quite good in relay logics, actually its what I do for a living i'm just asking for some techniques, you know "there are many ways to kill a chicken" if there are like personal techniques, because i have a technique and maybe you guys have better techniques than I do Because i know you guys are experts
 
Oh sure, NOW you tell me...

ronpittc said:
Please show me how to construct it, its really confusing..

I don't know how we could have misinterpreted that statement, but anyway...

I don't really think there's a 'technique' to writing code for something like you original example. You just write it, then 'fine-tune' as necessary. I think you're really looking for hints and tips.

Most importantly, PLAN AHEAD! Don't just pick adresses at random. Come up with your own 'standard' allocation for bits. Group them in a logical way that makes sense to you. These will vary from brand to brand, so you have to decide what's best for you.

If this still isn't the stuff your after, then give us an example of a 'technique' you have, and maybe we'll understand what you're looking for... ;)

beerchug

-Eric
 
constructing

The first thing I do in a new project is create (specifically AB projects) the I/O list, and enter it into logix. Then from there create a the data tables and files needed for it (ie, (files) H2 valve, zone 1 burner control, (data files) zone 1 bits, zone 1 ints, zone 1 pid, etc). This allows me to create a logical arragement and skeleton for the whole project before ive written a single line of code. I try to give each physical device its own ladder and its own data files.

Matt
 
You should give some structure to your ladder program. i.e.
1. Keep separate distinct portions of the equipment in individual subroutines or files.
2. Keep the flow of the program in some logical order, i.e.
a. Monitor inputs and apply logic
b. Group all physical outputs in one area of the program.
c. Clean up latched internal bits and data files at the end of the ladder.
3. Document, Document, Document what it is you where thinking when you wrote the line of code.

Everyone does it different, but keep the troubleshooting guys in mind as you write code, unless you want to be the only one to understand your code.
 
Got it. One thing to think about is what's called "sectionalizing" or "compartmentalizing". In other words, try to keep the elements that control specific components together. Some ways of doing this is with subroutines, mcp's, or sfc's. Another good idea is to keep alarms and fault finding routines in a file by themselves. As an example lets say you have a press which is used to manufacture metal pieces in a continuous manufacturing process. Now lets say that you have a feeder which feeds a role of steel into a die installed in this press, and this die has a component that cuts the steel to the proper length. Now if you had three different lenghts you need for different costumers you could use say subroutine 1 for the logic used to start and control the speed of the motor that drives the press. Now subroutine 2 could be used to control the die for length 1, subroutine 3 for length 2, subroutine 4 for length 3, and subroutine 5 for alarming and fault finding. The idea is to keep common things together, as it will make you're program easier to de-bug, troubleshoot, and modify. Hope this helps.
 
Ladder Logic/Ladder Diagram

Ron

"Ladder diagrams are specialized schematics commonly used to document industrial control logic systems. They are called "ladder" diagrams because they resemble a ladder, with two vertical rails (supply power) and as many "rungs" (horizontal lines) as there are control circuits to represent." Thus the termonology carried over to PLCs because there too the rungs of logic resemble a ladder, making the transition easier for repairmen.
No job is done until the paperwork is complete. Although it is tempting to jump right in and start programming it is not wise and will cause you a great deal of headaches in the future. Organization and documentation will be your key to a good program.
Follow the advice in previous post, Eric Nelson, Matthias von Zorn, glenncovington,jrayburn they are right on target.

The following link may or may not assist, depending on your skill level.
http://www.ibiblio.org/obp/electricCircuits/Digital/DIGI_6.html

Roger
 
Ya know ronpittc, I've been meaning to ask the same question....

What tips (are there industry standards or common practices???) have you guys used to develop the structure of a program (it looks like jrayburn and glenncovington have an idea what I was looking for)?

I know from working with guys working with embedded code (C++) that got wrapped up in manitaining / modifying past employee's code that have been tied up in knots trying to follow things thru.

Any ladder logic I've put together has always been laid out with maintenance in mind so I grouped inputs, alarms, special functions, outputs, etc.. together in some organized fashion (at least as best as possible). I've also either grouped related I/O or named I/O points so that they made sense. Lastly I've documented everything as best as possible keeping all this in mind.

Fortunately the few projects I've worked on (using A-D DirectSoft and Modicon Concept) I made the modifications / fine tuning so I didn't have the pleasure of trying to figure out what was going on in someone else's mind :unsure: (only my mind banghead ). So I've always wondered about this topic.

I know that a lot of this is learned thru experience but any basic info would appreciated!
 
I always try to write my ladders in order of machine operation.
Starting at the moment the start button is pushed, I look at what operations are supposed to happen next.
This is a simple way to make the ladder and helps keep it organized.
 
Just read all answers and advices -they are very important. It’s a pity that I have not them at the beginning of my work. This is a real gold for the beginners!
 
Bottom line after reading all this is that all the "subjective" stuff people want defined for them is an ART!

One guy might spray paint a Peace sign on his VW, while the other guy paints a flaming skull on his Hog. Who is right in the way they did it? Airbrushing? Aerosol Cans? A brush? What color should the flames be?

The bottom line is there are as many ways to program as there are people (I've heard this here before from someone).

You can't regulate a field that is constantly changing. If some really experienced guy tells you the only way to program is with some old DOS software package, he is wrong. That's his way, not THE way.
 

Similar Topics

Hello everyone, I am currently working on a project that uses a Rockwell L33ER controller and the FTV Studio V13 as Supervisory computer...
Replies
0
Views
84
I have an old PLC (circa 2007) consisting of Telemecanique/Modicon/Schneider Electric devices. The system has developed errors and unfortunately...
Replies
2
Views
179
Need some help here (again). I tried to download my HMI to the PLC and I get this error message about a missing file. Can anyone help?
Replies
3
Views
670
Hello expert I have migrate legacy project that use Applicom OPC DA with 3rd client and S7-400. I see in client code add item string call...
Replies
0
Views
344
Hi there, I have a job where a bunch of the existing tags contain "PRO1" at the beginning of the tag name. All these tags are for different...
Replies
0
Views
465
Back
Top Bottom