In the now classic commercial a group of men sit around a table and generate "Man-Law" usually related to beer.

A Sample Man Law Ad on youtube

It is my hope in an equally light hearted way we PLC guru's can sit around our keyboards and draw from our own personal histories those jewels of PLC-Law that should pass to the up and coming programmers.

PLC LAW #1 - DON'T OVERCOMPLICATE THE SIMPLE.

In other words use the simpliest easy to understand logic allowable. Using a sophisticated high level instruction just to look cool doesn't help anyone.


NEXT??


9/6/2008 - Just Published the Edited Downloadable 2008 Edition of the PLC Laws to the MRPLC Download Section. We are now at Law #51. Note: The Posting has the 2006 and 2007 versions in the ZIP file as well.

PLC LAW #2 - MAKE SURE YOU PLUG THE CABLE IN BEFORE YOU TRY TO FIGURE OUT WHY YOU CAN'T GO ONLINE.

Don't laugh, I don't know how many times this one has gotten me

PLC LAW #3 DURING STARTUP, ALWAYS VERIFY I/O BEFORE TESTING THE PROGRAM

I don't know how many times I have seen people troubleshooting their program and the I/O is still not wired or tested. Then they try to fix the problem by modifying their program.

PLC LAW #4 WHEN CONNECTING YOUR LAPTOP TO THE PLC, DON'T TIGHTEN THE SCREWS ON THE SERIAL CABLE AT THE LAPTOP SIDE.

Any damage or confusion caused by an intermittent disconnect pales in comparison to the damage done when somebody walks by your laptop (which is sitting on a 55-gallon drum) and trips over the serial cable dragging your laptop to the floor.

PLC LAW #5 Read the manual BEFORE trying to install/commission an unfamiliar piece of hardware.

Man Law requires us to NEVER read the manual!

PLC LAW #6 Allways have all possible backup files (plus read from PLC etc.) before starting any changes...

Once you touch it, you own it. If you can't at least restore previous condition, you are sc***ed.

PLC LAW #7 Allways double check you have the right cables for your CPU type and backup install software with you before you step on the plane.

(especially when it involves special connectors/converters/adapters)

Not sure this counts as a law, but what the heck...

PLC LAW #8 - Each vendor has their own programming software, so plan accordingly.

Believe it or not, I had a call one where someone asked me if they could use RSLogix to program a Square D Symax. 'Well they're both PLCs right?"

Duh...

PLC LAW 8.1 - Some vendors software may not play well with others... See RSLinx...

PLC Law 9

When powering up a PLC the first time, make sure that the power supply voltage switch is set to the right voltage.


Once when settinp up a compact logix it was wired to 120 but the switch was set to 240. All the lights lit up but I couldn't establish communications. I swapped out the processor, still no good. Five frustrating hours later, I noticed the swtich position.

PLC Law 9.1
When powering up a PLC the first time, make sure the PLC is in program mode or I/O is disconnected.

PLC LAW #8.1 - Order the correct software from your vendor instead of asking for it on MrPLC

Yes, I know... I'm the woman who has to find & keep copies of the manual that the men never read.

<g, d & r!>

PLC LAW #7.1 When working in a LAN or WAN environment always triple check processor ID's before erasing and downloading new code.

PLC LAW #10 Try to stage and test as much as possible before making big changes.

PLC LAW #11 Spares should not sit of the shelf. They should be used for training and tesing.

PLC LAW #12 Programs should have many rungs of diagnostic ladder that can be enabled or disabled quickly.
This includes timers for timeouts. These determine when input devices are not working properly. FIFOs are good for logging real time events. Counters that count errors are handy too.

PLC LAW #13 The best PLC programs are able to recover from error conditions quickly. This can make a big difference to overall production.

These are not specifically PLC LAWs. These are things I see customers continually over look.

I was going to second LAW#11 but all of these are such good point I'll second the whole thing.

But LAW#11 is one I have never understood. Why have all of those components sealed in boxes waiting for the next breakdown. One they are great for test simulation of changes but the greater reward is letting your programmers hone their skills. If work is low let them go in there and work with them. A little bit a day can make a tremendous difference

If this keeps growing we'll have to issue a compilation for use as a training guide. LOL.

PLC LAW # 14 ALL PROGRAMS SHOULD BE WELL DOCUMENTED
This is so that when you go back to a project say twelve months later you know and any one else knows what is actuallly happening in the program.

Here, Here on Law #14!

I've spent many, many hours redocumenting PLC programs that someone else wrote & lost the original file. But there's always one comment I have to include near the bottom of the program...

"You realize that since you understand this, I'm going to have to kill you..."

It always gets a smile from the electrician.

Ok Susan, I'm probably going to get an answer like MAN can't understands but I have looked and looked at this and still can't figure it out. I give up, what is it?

Grin Duck and Run

www.acronymfinder.com

And here I thought Susan was strong enough to make a comment like that and stand her ground.

Oh boy, that comment might get the wrath of Susan.

Bob said it, not me

PLC LAW #15 MAKE SURE YOU ACTUALLY UNDERSTAND THE QUESTION IN THE DIALOG BOX BEFORE HITTING "OK"

For example "all changes will be lost, are you sure you wish to continue?"

I am. I'm the only woman on the floor in this plant so I know how far I can push "man laws" and still get away with it.

Ok, it's my turn...

PLC Law #16: Remember to put a paper copy of the latest PLC ladder in the electrical cabinet.

If all other PCs & backups fail, this one won't.

PLC Law #17: When all else fails, add a TIMER, and a one-shot too just in case.


This is a really kewl thread, who thinks of all this stuff? LOL

This thread is getting really good! I'm enjoying it (and learning too).

PLC Law 11.1 - THERE MUST BE SPARES FOR CRITICAL PARTS!

You have no idea how many times someone has called me looking for an obsolete part because they're down and need one. And when I ask didn't you have a spare on hand..... I'm sure you all know the response...

PLC Law #18: When a non PLCite tells you that a machine is not working because of "programming errors", ask for proof before changing your masterpiece.

PLC Law #19: Make sure that your PLC and or process will run without the HMI (if using one).

I'll second that one. This happens all the time in motion control. However, you are still no better off if the proof can't be provided. I have seen cases where everyone is point the finger at everyone else without cause. The problem just doesn't get resolved. The PLC program or motion controller itself should be able to prove it was doing what it should. That is why one uses FIFOs, trends and graphs. I am a BIG believe in graphs and trends. I believe in defensive programming. We provide lots of debugging information with our product. We have graphs and event logs that can record events down to the millisecond. Sometimes, but rarely, the evidence points at us. That is OK because now we have the information to fix the problem rapidly no one expects everything to be perfect. One does expect quick resolution to problems.

PLC Law #18.1: When the machine is down, the blame will be assigned to whichever component the person assigning the blame understands the least.

"I don't know nuthin' 'bout them PLCs, but there's sumthin' wrong with the program".
"It's been working fine for the last six months, but this morning it just stopped working. Something's wrong with the program".

This is a law of human nature. I would have come up with the blame the person that is there at the beginning. BTW, the motion controllers are what are understood least in almost all cases.

It is amazing how someone can assign blame to something that hasn't changed. It is amazing how 3 out of four identical axes are working perfectly and yet the motion controller gets blames for the 4th not working because the 'software is bad'.

That is why we have good diagnostic tools.

Or "the drive must have gotten out of tune" when the system actually has a little backlash in it

Thats funny you must have worked with the same people that I have in the past because I have heard that more times than I care to share.

No joke, I have heard that statement almost word for word, multiple times. You would think that they would come up with a new line!

Thanks for the positive feedback chako - hey even a blind squirrel finds an acorn once in a while.

I'll second that one bigtime. Nothing worse than allowing a PC crash to wreck your process!



Those 18.1 quotes are timeless classics!

PLC Law #18.2: American Money says "In God we Trust" - with PLC's all others bring relevant data.

PLC LAW # 20 (are we at 20 already )

A good programmer will never believe the guy who says nothing has changed since it worked.

And as for the 18.1 quotes... "It's been working fine for the last 10 years, but then this morning the power light on the PLC won't come on.'

I actually had an occasion where a guy told me that the PLC stopped working, so I had to go on site. Get on site, find out that the PLC (FX from Mitsubishi) battery had NEVER been replaced. It finally exploded and the acid ran down the circuit board. I wonder why it didn't work... Hmm... No backup of their program except for an old printout they weren't even sure was for this PLC. Took a few hours, but we did finally get a new FX2N in place.

Now you get a feel how hard it must have been for Almighty to reduce things to just 10 commandments.

Well, according to Mel Brooks it was originally 15.

#21: Make sure you don't have any cables connected to the PLC making it startup in programming mode, unless you'd like to drive 160 km for faultsearching one early morning after a blackout.

The cable was an adapter for a CQM1 system, converted from peripheral port to serial. And the PLC was set (by default) to start up with the mode set on the programming console. The adapter apparently defaulted it to the programming mode...



Giving the customers 2-10 kg of paper won't really help in an urgent breakdown. Neither would their electricians nor probably anyone else at their plants understand it (this obviously differs at your plant). At my company we much rather give out the programming files, burnt on a CD together with all the other documentation (which also contains overviews of settings made in memories). That way our customer has a current version, without getting more paper than necessary. Also, HMI programs would be preservable, which wouldn't be possible with printouts.

I was going to mension this one myself but I thought it would be more appropriately considered Omron Law. I can't count how many times this has bitten me in hind at least for a couple of minutes.

Ok, here's a slight modification:

#21: Make sure that the default settings doesn't cause the PLC to fail from starting to operate properly after a blackout.

and my earlier law would then be #21A. :)

Could also be said by using a classical Albert Einstein quote: "Make everything as simple as possible, but not simpler." :)

#22 PLC Logic can not change by itself.

cool thread!!!! I hope this stays going

#23 - NEVER UNDER ANY CIRCUMSTANCES LEAVE FORCES IN A PROCESSOR. THEY SHOULD ONLY BE USED FOR TEMPORARY TESTING WHICH MEANS REMOVE THEM BEFORE GOING OFFLINE

THIS thread just reminded me of why

Or as the most wanted t-shirt in the automation world says - The program never fails !

(if it will become a collectors item... everything is for sale )

#24 - Always be sure that the rung / ladder / block you are troubleshooting is being scanned BEFORE you make major changes or spend 6 hours troubleshooting it!!!

I was actually in a factory troubleshooting a machine while an OEM / Designer was in another part of the building trying to install a new system. He had a prox sensing shaft rotation and counting revolutions that appeared not to be working. As I was walking by, I decided to introduce myself and he asked me "Have you ever seen a GEQ statement that doesn't work (that's greater than or equal to for all you non-AB guys ). I looked at his rung, moved the shaft by hand, the input worked, the counter incremented, but the rung didn't go true once the count was achieved. I looked at his Ladder 2, and, if the machine is in manual, that ladder was not set to scan. Guess what...he was in manual! He was super embarrassed that he had spent 6 hours trying to find the problem, had called the factory (to no avail), had rewritten the code, and even changed cards and rewired. I guess the KISS method also applies to TROUBLESHOOTING!!

PLC LAW #25 When teaching points on a robot, or programming a vision system that interfaces with a machine designed with a dial indexer, make sure your index table is on station...