An Advanced PLC Programming Book


Thread Starter

Hugh Jack

Over the past 6 years I have taught courses on PLC based control systems. In that time I have been unable to find a controls book that got beyond covering the basic principles. Out of frustration I first made a note set to enhance the existing books. Since then I have been turning it into written chapters, and I am over half way done. You can see the results to date at <A HREF=""></A> The book is organized so that it encourages hands-on contact with PLCs. The book also focuses on the Allen-Bradley PLC-5 processor. This is because I would rather go deeply into one processor, than lightly brush over all others. Please let me know if you have strong opinions about what should, or shouldn't be in such a book, or you like/don't like something already in the book.

Yosef Feigenbaum

The thing that I've found most lacking is the lack of knowledge of the basics of good programming. Laying out the project. Style. Design for maintainability. I've found that before beginning to teach PLC courses I often had to teach the students how to think more like a programmer than like an electrician. Good luck (8{)} ( .)
It's a good idea you stick with one processor. I have seen all system's birth date. No one educated me. I hated so much AB: they were unable to translate a simple relay logic. I mean a relay logic like we did on schematic diagram. After translation, a three columns schematic ended several times the original length. About 15 years ago Reliance was lot more advanced, and easier to use. Where do they stand today ? Few years ago, there was a graphical approach for representing logic. It was called GRAPHCET, originating from Europe. Some entreprises in North America adopted it. PLC's were inadequate for manipulating advanced loops. Whatever is your appreciation of these comments, a normal user is interested knowing what the system can do, yes. But he needs to know as well what the system can not do in the future. Which other piece of hardware software will be available. Yours: [email protected]
A good programming book should give project structuring examples. i.e/ Anyone can program a PLC to move object A to position A. The difficulties lie when outside influences affect this transition. If the program is well structured, it makes fault finding that much easier for maintenance personnel. Emphasis should also be made on program comments and labelling!! I disagree that you should teach people to think like programmers. The best examples of programming i have seen to date all come from engineers with a maintenance background.
Perhaps a chapter could be devoted to Safety oriented programming concepts, such as sensor verification and fault handling. I have increasingly seen these issues surfacing in the manufacturing industry. I believe that the detected failure of any action or process needs to be acted on in a safe manner to protect personnel, the machine, and the product quality.
And another chapter devoted to the various stages of testing and commissioning procedures. A formal and documented verification and testing procedure is essential. Bradley Timm South Africa
I would like to take this opportunity to reiterate Mark Millers comment about proper fault handling, reliability and safety. I have been working closely with PLC's, HMI's, and a host of electrical devices, sensors, switches, drives etc. for about 5 years. As a maintenance electrician in a harsh industrial environment I have adopted some rules that have helped me alot. The first rule is :pLC's don't break, nor do they do things without being programmed to do them. Although this is far from being a reality, it can save alot of time troubleshooting from within a PLC program when the vast majority problems occur because of influences external to the PLC. The second rule is : when dealing with input from field devices, understand what effect a failure of any device will have on the entire system and if possible handle this fault in the logic. In my pre-PLC Navy days we called it understanding the Big Picture. This idea is analogus to the computer programming concept of verifying the robustness of your program. In my experience there is no field device that cannot fail, in fact I have found that most do and probably will fail. In the past 5 years this fact has led to some rather unpleastant adventures. Looking back I see that in all of the applications I have worked with, compared to the complextity of the data, mathematical and process control routines in most PLC programs, I/O is a fairly small part. Of course I'm sure there can be acceptions to this. Since the messes can get really big if a failed input is not handled I now make it a point to take the time to consider "How is this thing going to break ie. open/short, fail high/fail low, etc." and "What is going to happen when it does break?"
The area of interest that is hard for me to find without having to expense myself is PID control concepts. I'm use to using RSLogix software for Allen Bradley processors (MicroLogix, PLC5, SLC and now Control Logix). Do you know where I can get more substantial info on these types of processors. I would like to find more info on how to copy M0/M1 files from an analog card thru the ASB card thru DH+ to the processor. I know AB now has software that you can flash the processor and then use read/write messaging...but I would still like to learn...any help would be greatly appreciated.