BobLfoot

PLC Law

158 posts in this topic

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
1 person likes this

Share this post


Link to post
Share on other sites
This thread is getting really good! I'm enjoying it (and learning too).
1 person likes this

Share this post


Link to post
Share on other sites
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...
1 person likes this

Share this post


Link to post
Share on other sites
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).
2 people like this

Share this post


Link to post
Share on other sites
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.
1 person likes this

Share this post


Link to post
Share on other sites
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". Edited by Steve Bailey
1 person likes this

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Or "the drive must have gotten out of tune" when the system actually has a little backlash in it

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites
Thanks for the positive feedback chako - hey even a blind squirrel finds an acorn once in a while.
1 person likes this

Share this post


Link to post
Share on other sites
I'll second that one bigtime. Nothing worse than allowing a PC crash to wreck your process! Those 18.1 quotes are timeless classics! Edited by Nathan

Share this post


Link to post
Share on other sites
PLC Law #18.2: American Money says "In God we Trust" - with PLC's all others bring relevant data.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Now you get a feel how hard it must have been for Almighty to reduce things to just 10 commandments.
1 person likes this

Share this post


Link to post
Share on other sites
Well, according to Mel Brooks it was originally 15.

Share this post


Link to post
Share on other sites
#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. Edited by TERdON

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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. :)

Share this post


Link to post
Share on other sites
Could also be said by using a classical Albert Einstein quote: "Make everything as simple as possible, but not simpler." :)

Share this post


Link to post
Share on other sites
#22 PLC Logic can not change by itself. cool thread!!!! I hope this stays going

Share this post


Link to post
Share on other sites
#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
1 person likes this

Share this post


Link to post
Share on other sites
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 )

Share this post


Link to post
Share on other sites
#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!!

Share this post


Link to post
Share on other sites
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...

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now