BobLfoot

PLC Law

166 posts in this topic

I didn't know that you guys still want shirts. I stopped having them made because I thought there was no interest. I'll check into getting some made. Last I checked, everyone liked the BLACK POLO with the embrodiery logo in the front. I can put a silk screen small on the front chest: "The program never fails." What do you guys think? I'll have to post some pictures when I get home. It's lunch time now, I need to go eat. PS: Inside scoop...cmoore73 above has two of the MrPLC shirts. I gave them to him some time ago. I guess I'll have to get some more and go through another round of GIVING....
2 people like this

Share this post


Link to post
Share on other sites
The PLC Law thread is so great I didn't want it to get off topic since it is still going strong Go HERE for the MrPLC Shirt thread http://forums.mrplc.com/index.php?showtopic=9750
1 person likes this

Share this post


Link to post
Share on other sites
On behalf of Ken Moore allow me to post PLC Law #34 The cheapest price is not always the best option. The best option is the lowest price for quality workmanship.
3 people like this

Share this post


Link to post
Share on other sites
PLC Law #35: If the program already works properly, DON'T TOUCH IT Refactoring a program "at the last minute" is about the worst idea you can get. It looks so perfectly clear how you're supposed to do it, yet you'll have loads of new (and old) problems. Refactoring a program might be a good idea, but only if you have a lot of time available for the project. Having a lot of time available isn't a very usual situation...
1 person likes this

Share this post


Link to post
Share on other sites
That's a good one too. I always say don't try to fix what is not broken...

Share this post


Link to post
Share on other sites

.

1 person likes this

Share this post


Link to post
Share on other sites
PLC Law 35.1 - "Broke " or "OK" is in the eye of the beholder. How many times have we commissioned a machine and had it running to customer spec only to have the next shift report to work and complain that it's broke and they can't run it at all "that way."

Share this post


Link to post
Share on other sites
Got a couple for you to ponder, don't know if they are law worthy or not, and forgive me if they have already been posted. "There's no such thing as idiot proof, only idiot resistant." "Artificial intelligence never overcomes natural stupidity"
1 person likes this

Share this post


Link to post
Share on other sites
I am proposing PLC LAW #36: If you write a program to help make a machine "idiot proof" the HR department will just hire better idiots
1 person likes this

Share this post


Link to post
Share on other sites
"If you think you're in control, your just not going fast enough"?
2 people like this

Share this post


Link to post
Share on other sites
If debugging is the process of removing bugs, then programming must be the process of putting them in. --Edsger Dijkstra
2 people like this

Share this post


Link to post
Share on other sites
PLC Law 34.1 - The lowest Bid may simply represent the biggest mistake in estimating.
1 person likes this

Share this post


Link to post
Share on other sites
PLC Law 37 - The machine will always run when your watching, then suddenly stops running or jams up when the boss watches or when your customer comes for the sign off. PLC Law 38 - When all else fails.......PDPU...........(power down power up)

Share this post


Link to post
Share on other sites
In my experience: PLC Law 34.1a - The lowest bid may simply represent the biggest mistake in estimating... and a few more mistakes in your machine.
1 person likes this

Share this post


Link to post
Share on other sites
PLC Law 39 - Create a PM for replacing PLC batterys or an alarm for low battery. PLC Law 40 - If you change addressing, update the backup program. Example for both Edited by adamriffe
1 person likes this

Share this post


Link to post
Share on other sites
For Law 36 we have a variant in Ozz You can make things idiot proof but not operator proof.

Share this post


Link to post
Share on other sites
I'll try my hand at this. PLC law 41 - In a system where a plc and a windows computer (PC) exchange data, the plc usually isn't the one that stops the data exchange. I know there are exceptions to all laws - that's why I get a ticket and my wife gets a warning - but in my environment, when this data exchange stops working, it is usually because a service on the PC has stopped, not becuase the plc decided it didn't want the data that it had been getting for years. This also usually follows some kind of "update" in the windows machine. The last time this happened, coming up after a shutdown, there was no comms between the plc and the computer. The IT guys swore (up, down, and sideways) that they did NOT touch the computer. After 8 hours of trying to figure out what was wrong, it seems an IT did backup the computer and plugged the ethernet cable into the wrong NIC.
1 person likes this

Share this post


Link to post
Share on other sites
PLC Law 42 - Service Agreements will never meet the needs of all parties {Engineers, Maintenance, Production and Legal}

Share this post


Link to post
Share on other sites
Hey, this is a great thread! I am so familiar, and in total agreement, with this one. Please spare a thought for what happens to the safety of the area operators when people start hacking code up because they believe it is the problem. I've seen essential parts of code related to safety backchecks 'removed' because it seemed to 'fix' the intermittent problem, setting the operators up for a future disaster. I'll add my own thought to the mix. I haven't read all 82 posts, but I hope this one is original: PLC Law # XXX01: Consider what will happen sequentially when each sensor on the input system fails. Will the code stop appropriately? Will it be safe? Will it cause nuisance interruptions when a sensor starts to flicker, (they rarely fail outright), or will it pause and continue? Remember, every part of the control system is constantly degrading, and eventually, every part will fail. Production facilities aren't known to replace PLC parts on a PVM schedule. ADMINISTRATORS NOTE : THE ABOVE IS NOW LAW 50 IN THE 2008 EDITION. PLC LAW # 50 - CONSIDER WHAT WILL HAPPEN SEQUENTIALLY WHEN EACH PART OF THE AUTOMATED SYSTEM FAILS. PLC LAW # 50.1 - THE CODE MUST STOP APPROPRIATELY WHEN FAILURES OCCUR? PLC LAW # 50.2 - THE CODE MUST BE SAFE WHEN FAILURES OCCUR. PLC LAW # 50.3 - THE CODE MUST NOT CAUSE NUISANCE INTERRUPTIONS WHEN A SENSOR STARTS TO FLICKER. PLC LAW # 50.4 - REMEMBER, EVERY PART OF THE CONTROL SYSTEM IS CONSTANTLY DEGRADING, AND EVENTUALLY, EVERY PART WILL FAIL. PLC LAW # 50.5 - PRODUCTION FACILITIES AREN'T KNOWN TO REPLACE PLC PARTS ON A PREDICTIVE, PREVENTATIVE OR PROACTIVE SCHEDULE. And here's my central control strategy item. Think Asimov's three laws of robotics, as they are the inspiration. PLC Law # XXX02: All code that causes machinery, hazmat, or heavy product of any kind to interact with operators in any way should be written to protect people first, equipment second, and production last. ADMINISTRATORS NOTE : THE ABOVE IS NOW LAW 51 IN THE 2008 EDITION. PLC LAW #51 - ALL CODE THAT CAUSES MACHINERY, HAZMAT, OR HEAVY PRODUCT OF ANY KIND TO INTERACT WITH OPERATORS IN ANY WAY SHOULD BE WRITTEN TO PROTECT PEOPLE FIRST, ENVIRONMENT SECOND, EQUIPMENT THIRD, AND PRODUCTION LAST.
1 person likes this

Share this post


Link to post
Share on other sites
I second that point hugely. It applies to all parts that communicate to the PLC as well. Here's an example... We were installing a Jag Extreme scale control unit. During the same shutdown, another company was installing the exact same unit for a different application in the same department. We took the time to write a config program that ran when power was cycled to reset everything, lock out all unneccesary keys and functions, and set reasonable limits for inputing setpoints to prevent keypad errors. An extra hour of programming, and when startup came, the difference was phenominal. Our interface was slick and intuitive, and when utility power to the area bumped, the other controller lost everything. It had a four-step mystery procedure to get it working again, which only a few people knew of. The contrast was dramatic. Take the time.

Share this post


Link to post
Share on other sites
Isn't it funny with personal choice. I hate having to turn things off. Turn them on and have them turn off automatically. Turn the line off to a timer and it automatically resets - great - no need to worry about having to programs in resets. It is very easy to make a retentive timer though, if you need one. Many of the Japanese PLCs work that way but do have a memory retentive bit area that can be used. You would probably like the Omron data memory area (registers) as they have to be cleared as they are retentive. One of the things I love about Mitsubishi is that you set up a bank of registers to be retentive and a bank to be non-retentive. Great freedom of choice there.
1 person likes this

Share this post


Link to post
Share on other sites
Personal Choice is great Bob. Still even with the best PLC it takes good programming to make it great. If the programmer forgets to document or uses "spiderweb" code for sinple on/off functions then he's taken a good PLC and made it bad. IMHO.
1 person likes this

Share this post


Link to post
Share on other sites
Sure thing Bob but with every PLC being different in the way it operates, memory areas behaving differently, different instruction sets etc, it is up to the user to familiarise him/her self with the PLC before using it. Let's face it, there are things we all like and dislike with just about any brand PLC we have to use on a job. We just have to learn the darn thing from scratch. I have never seen a programmer describe how a memory area works for example. Not even how a function works fully. The same instruction in different PLCs operates in a different way quite often. We only find out when we try them and they do not work as we either expect or are accustomed too. (Poor grammar). I have seen the BSET (block set) instruction described to the extent that on the first scan flag #0000 (BCD 0000) is written to a block of registers 100 long starting at register 2000 to clear the memory but not much more. It is up to the reader of the program to use the help in the PLC programming software/manual to determine further really. The first time I used a GE-Fanuc 90-30 I got the shock of my life with how they use timers for example. Most PLCs just describe a timer - in the 90-30 one has to specify the registers that the timers use as well - the timers use 3 registers. Very easy to just describe 2 and have one timer's memory area overwriting another timer's memory area until you get used to it. The timer does not work properly I can assure you. I guess with the differences between brands it is a case of programmer/user beware and read the manual(s) very well. I do not think a bad programmer/program makes a PLC bad but it certainly makes the programmer look pretty bad. Can also make the PLC LOOK bad I guess. I tend to describe each I/O point in the program as accurately as I can. For example - "symbol" LPFP1STTPB - "description" Leisure Pool Filtration Pump 1 Start Push Button. This helps with commentary and if described properly commentary is quite often not needed in a very simple program. Others have their own ways of describing things logically - to themselves anyway. What is logical to one is not logical to another. Fact of life I am afraid. By the way, have you had a chance to play with CX-One (CX-Programmer) yet? Go to "tools" - "keyboard mapping" and "options" and customise it for yourself to work the way you want it to work. In keyboard mapping I generally tell it to behave like Syswin and it then uses Syswin or CX-P short cut keys. Nice. Edited by BobB
1 person likes this

Share this post


Link to post
Share on other sites
PLC law 43 - The PLC can always be programmed to overcome any mechanical design deficiencies - regardless of the laws of physics. This law is dedicated to the number of times I have been asked to make something work when the designer hasn't thought the operation through or done the maths!
1 person likes this

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