Your Personal PLC Tutor Site - Interactive Q & A - "Opinions wanted



This board is for PLC Related Q&A ONLY. Please DON'T use it for advertising, etc.

Your Personal PLC Tutor Site - Interactive Q & A

"Opinions wanted - Consolidating Ladder Rungs"

New Here? Please read this important info!!!

Email this topic to a friend
Printer-friendly version of this topic Archived thread - Read only
Previous Topic | Next Topic

Home Conferences *** LIVE PLC Q&A *** (Public)

Original message

Brad B - (19 posts) Jan-23-02, 01:54 PM (EST)

"Opinions wanted - Consolidating Ladder Rungs"

I have heard some people say that when programming in ladder logic, it is best to cram as much funtionality as possible into as few rungs as possible. Still others tell me it is best to do the opposite, expanding a single complex rung into several, to make it very simple to understand and read.
I would like to know where some of you weigh in on the debate and why.
Personally, I like the former option. Only because it makes the job more of a challenge, and hence "fun".
Thanks

Top

Table of contents

RE: Opinions wanted - Consolidating..., Pierre, Jan-23-02, (1)
RE: Opinions wanted - Consolidating..., Ron P., Jan-23-02, (4)
RE: Opinions wanted - Consolidating..., Tom Jenkins, Jan-23-02, (2)
RE: Opinions wanted - Consolidating..., Brad B, Jan-24-02, (15)
RE: Opinions wanted - Consolidating..., Tom Jenkins, Jan-24-02, (17)
RE: Opinions wanted - Consolidating..., Steve Bailey, Jan-23-02, (3)
RE: Opinions wanted - Consolidating..., Pierre, Jan-23-02, (5)
RE: Opinions wanted - Consolidating..., Goody, Jan-23-02, (6)
RE: Opinions wanted - Consolidating..., Tom Jenkins, Jan-23-02, (7)
RE: Opinions wanted - Consolidating..., Tom Jenkins, Jan-23-02, (8)
Hey, Lefty! Is this you? , Terry_Woods, Jan-23-02, (12)
RE: Hey, Lefty! Is this you? , Tom Jenkins, Jan-24-02, (18)
RE: Opinions wanted - Consolidating..., SteveG, Jan-23-02, (9)
RE: Opinions wanted - Consolidating..., Ken Roach, Jan-23-02, (10)
RE: Opinions wanted - Consolidating..., rsdoran, Jan-23-02, (11)
RE: Opinions wanted - Consolidating..., Rick Densing, Jan-23-02, (13)
RE: Opinions wanted - Consolidating..., Terry_Woods, Jan-23-02, (14)
RE: Opinions wanted - Consolidating..., john paley, Jan-24-02, (16)
RE: Opinions wanted - Consolidating..., Al Boake, Jan-24-02, (19)

Email this topic to a friend Printer-friendly version of this topic	Archived thread - Read only Previous Topic \| Next Topic
Home Conferences * LIVE PLC Q&A * (Public)
Original message

Lobby | Topics | Previous Topic | Next Topic

Messages in this topic

Pierre - (408 posts) Jan-23-02, 02:08 PM (EST)

1. "RE: Opinions wanted - Consolidating oregano"

What you are asking is: How much oregano is to much oregano?
When I write a program I always do it FOR someone and FOR something.
Whoever or whatever it is will be a guide to how many rungs I want to use.
More is not necessairy better. Less isn't either. Just enough is a mather of taste!
If it looks like a Cat...

Top

Ron P. - (50 posts) Jan-23-02, 03:30 PM (EST)

4. "RE: Opinions wanted - Consolidating oregano"

Somebody always has to troubleshoot it sooner or later. I say as long as it is documented, documented, documented, so someone else can follow what you are doing. And as long as it makes logical sense to others as well as your self go for it.
However, on the other hand K.I.S.S almost always works best because if someone else can't follow what you're doing when the process breaks down and all the white shirts start running around wanting to know why it's not back up and running in 5 minutes or less it may come back to bite you if you decide to make it hard to read just because you were bored.
I use to worked with a guy one time that made his programs so complicated it would take you several hours just to figure out what he was trying to do before you could even begin to start troubleshooting the machine.
To make matters worse he never documented his programs. He also had a bad habit of scattering the rungs all over the program as well as putting dead rungs that did absolutely nothing. Another annoying trick he used was never using his input to directly turn on outputs to purposely make it more difficult to follow.
I found that often he would use 30 plus rungs to do what could be done in 3 or 4. When asked why he did this, he said to make sure the end customer has to call him back for a service call. Needless to say he became unemployed very quickly. I always found it easier to re-write the program than leave it for me or someone else to have to fight.
To answer your question from my perspective a compact rung can be harder to follow because you usually can't fit it all on your programming screen nor can you print it out in a report without it being all broken up. In my opinion I prefer a simplified program rung.
But then again with advanced features such as Custom Data Monitor (RSLogix) which allows you to drag all the relative addresses on to one screen so you can watch what's going on in your program with out having to scroll through the rungs to find out whats going on. You can set up a Custom Data Monitor Folder for each specific function of the machine. That way if you have all E-Stop contact positions or machine interlocks set up in their own data monitor folder machine troubleshooting becomes a lot easier. You really don't need to troubleshoot the logic as long as you know whats has to happen on the input side to make the outputs work.
I'm sure Siemens and others probably have a similar feature.

Ron P.

Top

Tom Jenkins - (868 posts) Jan-23-02, 02:25 PM (EST)

2. "RE: Opinions wanted - Consolidating Ladder Rungs"

It may be "fun" to cram as many contacts into one rung as ya' kin if you is the programmer. I guaran-dam-tee ya' it ain't no fun to de-bug that program when you is at a jobsite with the freezin' wind blowin' up yur undies and a client screamin' and a motor roarin' in yer ear and the mornin's Grand Slam breakfast churnin' in yur guts!
Paper is cheap, memory is cheap, monitor space is cheap. TIME AIN'T CHEAP, and thet is 'specially true about field time!
Break you logic up into simple steps. Use a lot of flags to reperesent logical groupings for combinations of events. One o' the best programmers I ever worked with claimed if ya' got more than five contacts to the left o' the coil, ya' ought ta revise the rung. Thet ain't bad advice!
(Besides, ya ain't gittin' paid ta have fun! Thet is jist a side benfit o' this hyar business. Ya is gettin' paid ta git a job done!)

Top

Brad B - (19 posts) Jan-24-02, 07:37 AM (EST)

15. "RE: Opinions wanted - Consolidating Ladder Rungs"

Fortunately, all of our work is inside
I hope that I don't compact code to the point of obscurity. I certainly won't do it if it becomes too illegible. But personally, I think it's easier to follow as long as it is well-built.
I can't stand it when I see a dozen rungs with one contact each, when they could easily fit within one or two rungs. I think it's much harder to follow when you must scroll up and down to trace the logic.
I also feel that parallelism in structure is easier to see in nice compact rungs sitting next to one another. When you must modify the same feature in four simmilar operations, its far easier to notice the simmilarities between the operations when they are all adjacent. The visual cues (to me) are just as important as locigal simplicity.

Top

Tom Jenkins - (868 posts) Jan-24-02, 09:17 AM (EST)

17. "RE: Opinions wanted - Consolidating Ladder Rungs"

As Phil the-os-opher says: "All things in moderation, including moderation."

Top

Steve Bailey - (865 posts) Jan-23-02, 02:43 PM (EST)

3. "RE: Opinions wanted - Consolidating Ladder Rungs"

There was a time when PLCs didn't have much memory, and you quite often found yourself in a situation where you needed to stuff ten pounds of code into a five pound box.
Nowadays, PLCs generally have plenty of memory, so you're less apt to find yourself having to find creative methods to do something, to avoid running out of RAM.
I generally come down on the 'make it easy to understand' side of the question. Most of the code I write is for somebody else. That means that somebody else has to live with it on a day-to-day basis. I'm not a real fan of telephone calls in the middle of the night, so it's in my best interest to make my code well documented and easy to understand.
If you want, you can make even the simplest code obscure. If you use reverse logic, a simple self-latching circuit looks like this:

Start Coil Coil
---|/|----|/|--------------(/)-
|
Stop |
---| |---------|

Top

Pierre - (408 posts) Jan-23-02, 03:52 PM (EST)

5. "RE: Opinions wanted - Consolidating Ladder Rungs"

>>>If you use reverse logic, a simple self-latching circuit looks like this:>>>
If I caught you reversing around with this kind of mumbo-jumbo... I'd reverse your pay-check

If it looks like a Cat...

Top

Goody - (182 posts) Jan-23-02, 04:18 PM (EST)

6. "RE: Opinions wanted - Consolidating Ladder Rungs"

I agree with simple short logic ladder lines apart from the 'STOP' line.
I like to cram as many bits as possible into the logic lines that stop the machine (Excluding E stops)
You can often end up with 30 bits or more that will stop the machine, overloads, stop buttons limits etc.
If you cram these into 3 consecutive lines, you can monitor them all at once.
I am sure we have all had the problem of a machine intermittently stopping and not knowing why.
Your eyes can watch 3 lines at once waiting for a contact to break.
If it is spread over six or more lines, some of it might go off the page.

Top

Tom Jenkins - (868 posts) Jan-23-02, 05:23 PM (EST)

7. "RE: Opinions wanted - Consolidating Ladder Rungs"

LAST EDITED ON Jan-23-02 AT 06:16 PM (EST)
It's a question of organizing your bits into groupings. For example, if you are stopping a pump, you could have faults divided into four categories. Your Stop rung would have four contacts ahead of it.
1) Wet Well Fault
2) Discharge FAult
3) VFD Fault
4) General Fault
It's easy to see where the source of your problem lies.
Each category would then have individual fault bits that trip it.
1) Wet Well Fault
a. Low Level
b. intrusion
c. high suction pressure drop
2) Discharge Fault
a. discharge valve closed
b. high discharge pressure
c. low discharge pressure
d. high temperature
3) VFD Fault
a. under voltage
b. over current
c. over temperature
d. bypass contactor on
4) General Fault
a. stop button
b. high vibration
c. spin timer active
d. seal water low flow
e. motor water detection
It is now very simple to see what area caused the trip, find the rung for that area, and de-bug. You only need to monitor one rung! It is actually faster, in my opinion, than sorting through 16 individual contacts, some of them normally open, some normally closed, to see where the fault lies. Carying this philosophy through the whole program makes for simple, readable code.

Top

Tom Jenkins - (868 posts) Jan-23-02, 06:07 PM (EST)

8. "RE: Opinions wanted - Consolidating Ladder Rungs"

LAST EDITED ON Jan-23-02 AT 06:08 PM (EST)
.

Top

Terry_Woods - (974 posts) Jan-23-02, 10:21 PM (EST)

12. "Hey, Lefty! Is this you? "

Two cowboys from Texas walk into a roadhouse to wash the trail dust from their throats. They stand at the bar, drinking a beer, and talking about current cattle prices.
Suddenly, a woman at a nearby table, who is eating a sandwich, begins to cough and choke. After a minute or so, it becomes apparent that she is in real distress.
One of the cowboys looks at her and says, "Kin ya swaller?" The woman shakes her head, no.
"Kin ya breathe?" The woman begins to turn blue and shakes her head.
The cowboy walks over to the woman, lifts up the back of her dress, yanks down her drawers and quickly gives her butt cheek a lap with his tongue.
The woman is so shocked, that she has a violent spasm and the obstruction flies out of her mouth. As she begins to breathe again, the cowboy walks slowly back to the bar and takes a drink from his beer.
His partner says, " Ya know, Lefty, I'd heard of that there "Hind Lick Maneuver", but I ain't never seen nobody do it.

Top

Tom Jenkins - (868 posts) Jan-24-02, 09:18 AM (EST)

18. "RE: Hey, Lefty! Is this you? "

Naw - not a'tall. We drinks rye whiskey 'round hyar!

Top

SteveG - (9 posts) Jan-23-02, 09:00 PM (EST)

9. "RE: Opinions wanted - Consolidating Ladder Rungs"

LOL,
The only people I find doing that type of programming are union guys finding work for themselves.
Reminds me of a Homer Simpson quote:
"Don't strike if your job is bad, just work half-assed everyday... it's the American way."

Top

Ken Roach - (38 posts) Jan-23-02, 10:02 PM (EST)

10. "RE: Opinions wanted - Consolidating Ladder Rungs"

Slightly offtopic, but my rule has been that if I used three or more conditions in the same way in a lot of rungs, I'd consolidate them into one bit and use that instead. That's how I do most of my "The machine is warm, loaded, and has had it's coffee" bits.
Think of PLC rungs as paragraphs. When you're through with the thought or utterance, it's on to the next paragraph.
My other guiding constraint is whether I'll be able to see the whole thing on the screen at once ! The most common time I violate that is when I'm populating a table of constants with MOV and COP instructions and I want to put them all in parallel.

Top

rsdoran - (426 posts) Jan-23-02, 10:19 PM (EST)

11. "RE: Opinions wanted - Consolidating Ladder Rungs"

I see you are using AB references as examples but HOW do you make multiple conditions into one bit? Doesnt that need more rungs to create? Isnt it just as easy to branch? That way the original input is seen and not an internal bit that has to be backtracked to understand its condition?

Top

Rick Densing - (217 posts) Jan-23-02, 10:31 PM (EST)

13. "RE: Opinions wanted - Consolidating Ladder Rungs"

Yes, he is advocating more rungs. But if the single bit is commented correctly, as he states, you don't need to backtrack unless it is off. My favorite feature of RSLogix 500 ver 5- right click and find all.

Top

Terry_Woods - (974 posts) Jan-23-02, 11:17 PM (EST)

14. "RE: Opinions wanted - Consolidating Ladder Rungs"

A B C A*B*C
----| |--------| |--------| |--------( )

A A+B+C
----| |----+-------------------------( )
|
B |
----| |----+
|
C |
----| |----+

A D (A+B+C)*D
----| |----+-----| |-----------------( )
|
B |
----| |----+
|
C |
----| |----+
Didn't say it was good, only answered your HOW?

Now, with respect to the question...
Use as much code as necessary to maintain CLEAN, CLEAR, MODULARITY.
Then, between modules, use ONLY MESSAGE FLAGS. Do not use a sensor or an output from Module-A in Module-B. Even if Module-B needs to know the state of a device in Module-A, don't use that device in Module-B.
Essentially, Module-B is looking for permission to do something. Module-B should be asking "Can I do such-and-such?"
Module-A should be aware of all of the conditions in its area of responsibility. Module-A also needs to know what Mule-B needs to know. When it is OK for Module-B to do such-and-such, then Module-A should post the flag saying that it is OK, whether Module-B is looking for it or not. The FLAG does not cause anything to happen - it allows something to happen.
If you use the sensor or output from Module-A in Module-B, then that device might actually cause something to happen!
Modules should talk to each other in the same way that we do. Then the only interactions between modules are the messages. Module Messages should not go to multiple modules unless you have a case of Module-A, Module-B1 and Module-B2. In that case, Modules B1 and B2 have the same relationship to Module-A.
This eliminates spaghetti-code between modules. Spaghetti-code within the module is something else. However, if your modules are tight then it should be very easy to eliminate any spaghetti-code within the module. Modules need to be planned out very carefully and practically.
Modules need to be complete unto themselves - don't short-cut.
Many of the other ideas already posted apply as well.
I certainly do remember the days when we had 4K of memory. In those days, REVERSE LOGIC was a BLESSING!
And it still is when you are creating Fail-Safe Sensor Logic.

Top

john paley - (109 posts) Jan-24-02, 08:03 AM (EST)

16. "RE: Opinions wanted - Consolidating Ladder Rungs"

I like to use small rungs.
Say you have a string of 4 inputs that all must be on to provide an interlock. Put them in a rung, then the coil of the rung represents the condition of the string with a single bit, rather than the original 4. You can more easily use the Interlock string bit many times throughout the program.
Grouping conditions in smaller rungs allows you to represent countless examples of conditions with a single bit. It just makes things easier to follow and more organized.

Top

Al Boake - (36 posts) Jan-24-02, 09:23 AM (EST)

19. "RE: Opinions wanted - Consolidating Ladder Rungs"

When memory was limited, actually used Karnaugh maps to simplify logic, but did not necessarily improve comprehension to service people.
Now, if programming multiple similar items (like a series of 8 motor starters for conveyors) goal is simplicity. So, all outputs have the same bit address, all internals have the same address type etc.
Of course details depend on the PLC being used. If word-bit addressing, only the word changes, and the bits are the same for similar items.
Makes life simpler, tilts the field toward quicker start-up.
Conserving PLC memory does not constrain the design.
Al Boake P.E.

Top

Remove

Lobby | Topics | Previous Topic | Next Topic

Rate this topic (1=skip it, 10=must read)? [ 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 ]

Your Personal PLC Tutor Site Learn Now!!.

Brad B - (19 posts)	Jan-23-02, 01:54 PM (EST)
"Opinions wanted - Consolidating Ladder Rungs"
I have heard some people say that when programming in ladder logic, it is best to cram as much funtionality as possible into as few rungs as possible. Still others tell me it is best to do the opposite, expanding a single complex rung into several, to make it very simple to understand and read. I would like to know where some of you weigh in on the debate and why. Personally, I like the former option. Only because it makes the job more of a challenge, and hence "fun". Thanks
	Top

Pierre - (408 posts)	Jan-23-02, 02:08 PM (EST)
1. "RE: Opinions wanted - Consolidating oregano"
What you are asking is: How much oregano is to much oregano? When I write a program I always do it FOR someone and FOR something. Whoever or whatever it is will be a guide to how many rungs I want to use. More is not necessairy better. Less isn't either. Just enough is a mather of taste! If it looks like a Cat...
	Top


	Ron P. - (50 posts)	Jan-23-02, 03:30 PM (EST)
	4. "RE: Opinions wanted - Consolidating oregano"
	Somebody always has to troubleshoot it sooner or later. I say as long as it is documented, documented, documented, so someone else can follow what you are doing. And as long as it makes logical sense to others as well as your self go for it. However, on the other hand K.I.S.S almost always works best because if someone else can't follow what you're doing when the process breaks down and all the white shirts start running around wanting to know why it's not back up and running in 5 minutes or less it may come back to bite you if you decide to make it hard to read just because you were bored. I use to worked with a guy one time that made his programs so complicated it would take you several hours just to figure out what he was trying to do before you could even begin to start troubleshooting the machine. To make matters worse he never documented his programs. He also had a bad habit of scattering the rungs all over the program as well as putting dead rungs that did absolutely nothing. Another annoying trick he used was never using his input to directly turn on outputs to purposely make it more difficult to follow. I found that often he would use 30 plus rungs to do what could be done in 3 or 4. When asked why he did this, he said to make sure the end customer has to call him back for a service call. Needless to say he became unemployed very quickly. I always found it easier to re-write the program than leave it for me or someone else to have to fight. To answer your question from my perspective a compact rung can be harder to follow because you usually can't fit it all on your programming screen nor can you print it out in a report without it being all broken up. In my opinion I prefer a simplified program rung. But then again with advanced features such as Custom Data Monitor (RSLogix) which allows you to drag all the relative addresses on to one screen so you can watch what's going on in your program with out having to scroll through the rungs to find out whats going on. You can set up a Custom Data Monitor Folder for each specific function of the machine. That way if you have all E-Stop contact positions or machine interlocks set up in their own data monitor folder machine troubleshooting becomes a lot easier. You really don't need to troubleshoot the logic as long as you know whats has to happen on the input side to make the outputs work. I'm sure Siemens and others probably have a similar feature. Ron P.
		Top

Tom Jenkins - (868 posts)	Jan-23-02, 02:25 PM (EST)
2. "RE: Opinions wanted - Consolidating Ladder Rungs"
It may be "fun" to cram as many contacts into one rung as ya' kin if you is the programmer. I guaran-dam-tee ya' it ain't no fun to de-bug that program when you is at a jobsite with the freezin' wind blowin' up yur undies and a client screamin' and a motor roarin' in yer ear and the mornin's Grand Slam breakfast churnin' in yur guts! Paper is cheap, memory is cheap, monitor space is cheap. TIME AIN'T CHEAP, and thet is 'specially true about field time! Break you logic up into simple steps. Use a lot of flags to reperesent logical groupings for combinations of events. One o' the best programmers I ever worked with claimed if ya' got more than five contacts to the left o' the coil, ya' ought ta revise the rung. Thet ain't bad advice! (Besides, ya ain't gittin' paid ta have fun! Thet is jist a side benfit o' this hyar business. Ya is gettin' paid ta git a job done!)
	Top


	Brad B - (19 posts)	Jan-24-02, 07:37 AM (EST)
	15. "RE: Opinions wanted - Consolidating Ladder Rungs"
	Fortunately, all of our work is inside I hope that I don't compact code to the point of obscurity. I certainly won't do it if it becomes too illegible. But personally, I think it's easier to follow as long as it is well-built. I can't stand it when I see a dozen rungs with one contact each, when they could easily fit within one or two rungs. I think it's much harder to follow when you must scroll up and down to trace the logic. I also feel that parallelism in structure is easier to see in nice compact rungs sitting next to one another. When you must modify the same feature in four simmilar operations, its far easier to notice the simmilarities between the operations when they are all adjacent. The visual cues (to me) are just as important as locigal simplicity.
		Top


	Tom Jenkins - (868 posts)	Jan-24-02, 09:17 AM (EST)
	17. "RE: Opinions wanted - Consolidating Ladder Rungs"
	As Phil the-os-opher says: "All things in moderation, including moderation."
		Top

Steve Bailey - (865 posts)	Jan-23-02, 02:43 PM (EST)
3. "RE: Opinions wanted - Consolidating Ladder Rungs"
There was a time when PLCs didn't have much memory, and you quite often found yourself in a situation where you needed to stuff ten pounds of code into a five pound box. Nowadays, PLCs generally have plenty of memory, so you're less apt to find yourself having to find creative methods to do something, to avoid running out of RAM. I generally come down on the 'make it easy to understand' side of the question. Most of the code I write is for somebody else. That means that somebody else has to live with it on a day-to-day basis. I'm not a real fan of telephone calls in the middle of the night, so it's in my best interest to make my code well documented and easy to understand. If you want, you can make even the simplest code obscure. If you use reverse logic, a simple self-latching circuit looks like this: Start Coil Coil ---\|/\|----\|/\|--------------(/)- \| Stop \| ---\| \|---------\|
	Top


	Pierre - (408 posts)	Jan-23-02, 03:52 PM (EST)
	5. "RE: Opinions wanted - Consolidating Ladder Rungs"
	>>>If you use reverse logic, a simple self-latching circuit looks like this:>>> If I caught you reversing around with this kind of mumbo-jumbo... I'd reverse your pay-check If it looks like a Cat...
		Top


	Goody - (182 posts)	Jan-23-02, 04:18 PM (EST)
	6. "RE: Opinions wanted - Consolidating Ladder Rungs"
	I agree with simple short logic ladder lines apart from the 'STOP' line. I like to cram as many bits as possible into the logic lines that stop the machine (Excluding E stops) You can often end up with 30 bits or more that will stop the machine, overloads, stop buttons limits etc. If you cram these into 3 consecutive lines, you can monitor them all at once. I am sure we have all had the problem of a machine intermittently stopping and not knowing why. Your eyes can watch 3 lines at once waiting for a contact to break. If it is spread over six or more lines, some of it might go off the page.
		Top


	Tom Jenkins - (868 posts)	Jan-23-02, 05:23 PM (EST)
	7. "RE: Opinions wanted - Consolidating Ladder Rungs"
	LAST EDITED ON Jan-23-02 AT 06:16 PM (EST) It's a question of organizing your bits into groupings. For example, if you are stopping a pump, you could have faults divided into four categories. Your Stop rung would have four contacts ahead of it. 1) Wet Well Fault 2) Discharge FAult 3) VFD Fault 4) General Fault It's easy to see where the source of your problem lies. Each category would then have individual fault bits that trip it. 1) Wet Well Fault a. Low Level b. intrusion c. high suction pressure drop 2) Discharge Fault a. discharge valve closed b. high discharge pressure c. low discharge pressure d. high temperature 3) VFD Fault a. under voltage b. over current c. over temperature d. bypass contactor on 4) General Fault a. stop button b. high vibration c. spin timer active d. seal water low flow e. motor water detection It is now very simple to see what area caused the trip, find the rung for that area, and de-bug. You only need to monitor one rung! It is actually faster, in my opinion, than sorting through 16 individual contacts, some of them normally open, some normally closed, to see where the fault lies. Carying this philosophy through the whole program makes for simple, readable code.
		Top


	Tom Jenkins - (868 posts)	Jan-23-02, 06:07 PM (EST)
	8. "RE: Opinions wanted - Consolidating Ladder Rungs"
	LAST EDITED ON Jan-23-02 AT 06:08 PM (EST) .
		Top


	Terry_Woods - (974 posts)	Jan-23-02, 10:21 PM (EST)
	12. "Hey, Lefty! Is this you? "
	Two cowboys from Texas walk into a roadhouse to wash the trail dust from their throats. They stand at the bar, drinking a beer, and talking about current cattle prices. Suddenly, a woman at a nearby table, who is eating a sandwich, begins to cough and choke. After a minute or so, it becomes apparent that she is in real distress. One of the cowboys looks at her and says, "Kin ya swaller?" The woman shakes her head, no. "Kin ya breathe?" The woman begins to turn blue and shakes her head. The cowboy walks over to the woman, lifts up the back of her dress, yanks down her drawers and quickly gives her butt cheek a lap with his tongue. The woman is so shocked, that she has a violent spasm and the obstruction flies out of her mouth. As she begins to breathe again, the cowboy walks slowly back to the bar and takes a drink from his beer. His partner says, " Ya know, Lefty, I'd heard of that there "Hind Lick Maneuver", but I ain't never seen nobody do it.
		Top


	Tom Jenkins - (868 posts)	Jan-24-02, 09:18 AM (EST)
	18. "RE: Hey, Lefty! Is this you? "
	Naw - not a'tall. We drinks rye whiskey 'round hyar!
		Top


	SteveG - (9 posts)	Jan-23-02, 09:00 PM (EST)
	9. "RE: Opinions wanted - Consolidating Ladder Rungs"
	LOL, The only people I find doing that type of programming are union guys finding work for themselves. Reminds me of a Homer Simpson quote: "Don't strike if your job is bad, just work half-assed everyday... it's the American way."
		Top

Ken Roach - (38 posts)	Jan-23-02, 10:02 PM (EST)
10. "RE: Opinions wanted - Consolidating Ladder Rungs"
Slightly offtopic, but my rule has been that if I used three or more conditions in the same way in a lot of rungs, I'd consolidate them into one bit and use that instead. That's how I do most of my "The machine is warm, loaded, and has had it's coffee" bits. Think of PLC rungs as paragraphs. When you're through with the thought or utterance, it's on to the next paragraph. My other guiding constraint is whether I'll be able to see the whole thing on the screen at once ! The most common time I violate that is when I'm populating a table of constants with MOV and COP instructions and I want to put them all in parallel.
	Top


	rsdoran - (426 posts)	Jan-23-02, 10:19 PM (EST)
	11. "RE: Opinions wanted - Consolidating Ladder Rungs"
	I see you are using AB references as examples but HOW do you make multiple conditions into one bit? Doesnt that need more rungs to create? Isnt it just as easy to branch? That way the original input is seen and not an internal bit that has to be backtracked to understand its condition?
		Top


	Rick Densing - (217 posts)	Jan-23-02, 10:31 PM (EST)
	13. "RE: Opinions wanted - Consolidating Ladder Rungs"
	Yes, he is advocating more rungs. But if the single bit is commented correctly, as he states, you don't need to backtrack unless it is off. My favorite feature of RSLogix 500 ver 5- right click and find all.
		Top


	Terry_Woods - (974 posts)	Jan-23-02, 11:17 PM (EST)
	14. "RE: Opinions wanted - Consolidating Ladder Rungs"
	A B C ABC ----\| \|--------\| \|--------\| \|--------( ) A A+B+C ----\| \|----+-------------------------( ) \| B \| ----\| \|----+ \| C \| ----\| \|----+ A D (A+B+C)*D ----\| \|----+-----\| \|-----------------( ) \| B \| ----\| \|----+ \| C \| ----\| \|----+ Didn't say it was good, only answered your HOW? Now, with respect to the question... Use as much code as necessary to maintain CLEAN, CLEAR, MODULARITY. Then, between modules, use ONLY MESSAGE FLAGS. Do not use a sensor or an output from Module-A in Module-B. Even if Module-B needs to know the state of a device in Module-A, don't use that device in Module-B. Essentially, Module-B is looking for permission to do something. Module-B should be asking "Can I do such-and-such?" Module-A should be aware of all of the conditions in its area of responsibility. Module-A also needs to know what Mule-B needs to know. When it is OK for Module-B to do such-and-such, then Module-A should post the flag saying that it is OK, whether Module-B is looking for it or not. The FLAG does not cause anything to happen - it allows something to happen. If you use the sensor or output from Module-A in Module-B, then that device might actually cause something to happen! Modules should talk to each other in the same way that we do. Then the only interactions between modules are the messages. Module Messages should not go to multiple modules unless you have a case of Module-A, Module-B1 and Module-B2. In that case, Modules B1 and B2 have the same relationship to Module-A. This eliminates spaghetti-code between modules. Spaghetti-code within the module is something else. However, if your modules are tight then it should be very easy to eliminate any spaghetti-code within the module. Modules need to be planned out very carefully and practically. Modules need to be complete unto themselves - don't short-cut. Many of the other ideas already posted apply as well. I certainly do remember the days when we had 4K of memory. In those days, REVERSE LOGIC was a BLESSING! And it still is when you are creating Fail-Safe Sensor Logic.
		Top

john paley - (109 posts)	Jan-24-02, 08:03 AM (EST)
16. "RE: Opinions wanted - Consolidating Ladder Rungs"
I like to use small rungs. Say you have a string of 4 inputs that all must be on to provide an interlock. Put them in a rung, then the coil of the rung represents the condition of the string with a single bit, rather than the original 4. You can more easily use the Interlock string bit many times throughout the program. Grouping conditions in smaller rungs allows you to represent countless examples of conditions with a single bit. It just makes things easier to follow and more organized.
	Top

Al Boake - (36 posts)	Jan-24-02, 09:23 AM (EST)
19. "RE: Opinions wanted - Consolidating Ladder Rungs"
When memory was limited, actually used Karnaugh maps to simplify logic, but did not necessarily improve comprehension to service people. Now, if programming multiple similar items (like a series of 8 motor starters for conveyors) goal is simplicity. So, all outputs have the same bit address, all internals have the same address type etc. Of course details depend on the PLC being used. If word-bit addressing, only the word changes, and the bits are the same for similar items. Makes life simpler, tilts the field toward quicker start-up. Conserving PLC memory does not constrain the design. Al Boake P.E.
	Top

Remove	Lobby \| Topics \| Previous Topic \| Next Topic
Rate this topic (1=skip it, 10=must read)? [ 1 \| 2 \| 3 \| 4 \| 5 \| 6 \| 7 \| 8 \| 9 \| 10 ]