Vous êtes sur la page 1sur 18

learing to program great - Forums.MrPLC.

com

http://forums.mrplc.com/index.php?showtopic=15680&st=0&p=77274&#...

Page 1 of 1

learing to program great


#1 JeffKiper Posted 30 December 2008 - 12:02 AM
This will be posted in other forums just to get a wider group of guru's. As I read some post about programming this or that. I start to think about where do we learn our programming styles? Do you guys read books, manuals, and then hone them as the years go on? If it is books which ones? Manuals where do I need to go? As far a honing my skills that may be coming alot faster than I would like. Looks like it is going to be sink or swim very soon. I have read about 4 or 5 different programming styles that cover a wide spread of styles and system. Batch process, Constant flow, Motion, ect. Where do you start to getting away from LL and going to ST, SFC, or BLK and why? I am comfortable in ladder but open to something that may be better for the end user or myself as I start writing what I hope to be GREAT code. I deal with Allen Bradley 95% of the time so that is why I posted it in this forum. Hoping to get pointers to AB Manual, and Help.

#2 BobLfoot Posted 30 December 2008 - 08:09 AM


(http://forums.mrplc.com/index.php?app=forums&module=forums&section=findpost&pid=77214) JAK, on Dec 30 2008, 12:02 AM, said: As I read some post about programming this or that. I start to think about where do we learn our programming styles? Do you guys read books, manuals, and then hone them as the years go on? If it is books which ones? I'll tackle this small part of your post with my humble two cents. I learned my programming style as I learned to problem solve. Any programmer worth his salt will tell you that how he writes, at least in the first draft reflects his way of thinking or approaching a task. That said, I was self taught from books (The TRS Basic Manual in the Tandy Store at age 11) and Mentor Taught (Ham Radio / Electrical work on the Farm in my teens). This was then honed by Academic Instruction AAS adn BS Comp Sci. And then unlearned/releaned by practical Experience and More mentors. Bottom Line - There is no one way to learn the PLC progrmming business, but the day you look at someone and say "I can't learn anything from them" is the day it's time to quit.

#3 kaiser_will Posted 30 December 2008 - 09:36 AM


Few universities teach PLC programming, and the few that do have classes with professors the most likely never programmed a PLC as their primary job. There might be exceptions, but they are few. I learned the bulk of my PLC programming abilities by first gleaning as much style from technician mentors in the manufacturing jobs I have had. Old-school techs are notorious for coding in the same or similar style. They keys to my programming abilities are: 1. Style...search for how others perform a function; 2. Troubleshooting...with a thorough understanding of a problem, one can back deduce where the root cause lies 3. Flowcharting...for new programs, I build a comprehensive flowchart of the application and code from that; I can

1 of 18

8/18/2012 8:08 PM

learing to program great - Forums.MrPLC.com

http://forums.mrplc.com/index.php?showtopic=15680&st=0&p=77274&#...

have a system nearly complete from the first draft 4. Documentation...label the heck out of everything; a well-documented program has saved my bacon many times That leads into your main question...breaking away from ladder logic to other forms. For 10+ years, most PLC programming software has been IEC 1131-3 compliant as a way to insure that if a hardware company goes out of business that Company X come along and offer software to keep that legacy platform going (i.e., hardware independent). However, this scenario has never shaken out in a large way (that I know of). I have seen different hardware-software companies in the rack-mount market (VME...where you buy open-rack hardware from Company A and programming software from Company B), but not in the PLC market. This is probably due to the US government's large-base of rack-mount hardware and a requirement to have multiple sources for everything. What IEC 1131-3 has done is driven all hardware companies to offer software that can be programmed in ladder logic, function charts and structured text. All companies have followed the rule, most programs note that their products fit the requirements of the code, but the programming styles and examples are all over the map. I have had one job in my past in which we programmed all in function charts (more of a flowchart style...Steeplechase - Phoenix Contact). I have been trying to get my present employer to experiment as function chart programming can do so many things that ladder logic cannot as it is near multi-tasking. Bottom line (in my opinion) is that programming style is a function of the employer...they establish the standard for their style or they open the door for someone in their organization to develop and rubber-stamp the style. You can download a demo-license of Phoenix-Contact's Steeplechase VLC IEC 1131-3 compliant programming software. If you want a huge example of a Steeplechase program, shoot me a message and I will dig through my archives for you. That is my other 2 cents plug...I learn more by back-tracking through someone's real world program than I do reading instructional literature with broad-overviewa or non-comprehensive examples. This post has been edited by kaiser_will: 30 December 2008 - 09:40 AM

#4 JeffKiper Posted 30 December 2008 - 05:26 PM


I wanted to post a thanks just to say that I have been to busy working a shutdown to completely read the replies. I will be taking some time over the new year to read. So in short thanks for your replies I don't want any body to think I am rude by not repling. I am just covered up woth work

#5 TWControls Posted 31 December 2008 - 07:44 AM


In my opinion a "great" program functions properly and is easy for your average maintenance technician to troubleshoot. As long as it follows those two guidelines, I don't think it matters how you write it

#6 BobLfoot Posted 31 December 2008 - 09:40 AM


(http://forums.mrplc.com/index.php?app=forums&module=forums&section=findpost&pid=77257) TWControls, on Dec 31 2008, 07:44 AM, said: In my opinion a "great" program functions properly and is easy for your average maintenance technician to troubleshoot. As long as it follows those two guidelines, I don't think it matters how you write it Couldn't agree more TW - with one caveat, "Average is determined by the employer" Your average employee at your company might be a genius at mine.

#7 TWControls Posted 31 December 2008 - 11:31 AM


The average maintenance tech at my last job couldn't turn on a computer or even use a voltmeter, yet they could troubleshoot my machines.

2 of 18

8/18/2012 8:08 PM

learing to program great - Forums.MrPLC.com

http://forums.mrplc.com/index.php?showtopic=15680&st=0&p=77274&#...

The trick is that when you are called in on what seems to be the dumbest thing, do NOT complain that the maintenance techs need more training, take that moment to observe how you could improve your machine diagnostics so that they could figure it out on their own the next time

#8 JeffKiper Posted 31 December 2008 - 02:21 PM


TW I could not agree more! I try to use the KISS rule but is seems to be a balancing act. How do you balance the quick programming features vs. the easy to follow (more hours programming)? I like the SQO but following them can be little tuff if you have never seen anything like them before.

#9 paulengr Posted 31 December 2008 - 04:45 PM


(http://forums.mrplc.com/index.php?app=forums&module=forums&section=findpost&pid=77214) JAK, on Dec 30 2008, 12:02 AM, said: This will be posted in other forums just to get a wider group of guru's. As I read some post about programming this or that. I start to think about where do we learn our programming styles? Do you guys read books, manuals, and then hone them as the years go on? If it is books which ones? Manuals where do I need to go? As far a honing my skills that may be coming alot faster than I would like. Looks like it is going to be sink or swim very soon. I have read about 4 or 5 different programming styles that cover a wide spread of styles and system. Batch process, Constant flow, Motion, ect. Where do you start to getting away from LL and going to ST, SFC, or BLK and why? I am comfortable in ladder but open to something that may be better for the end user or myself as I start writing what I hope to be GREAT code. This post is extremely long winded (even for me). I've been thinking about the answer to this question for a while. The CLX processor changed everything. All of my old programming habits with regards to PLC's are getting turned upside down. Programming styles do matter. I'm sure you've read somewhere about the evils of the "GOTO" command or the power of object oriented programming, "separation of concerns", and similar terms like that. I've seen the following styles come and go (more or less) in the PC world: subroutines, libraries, object oriented programming, aspect-oriented programming, and most recently "EXTREME" programming, UML, SDLC, and unit testing. The point is that as fast as the PLC world moves, it has taken close to 2-3 decades to improve programmer productivity through changes in styles and techniques, and I wouldn't be surprised to see more techniques come in the future. PLC's have always been a bit slower for a lot of reasons but we're starting to catch up. The "styles" you mentioned are not different styles. They are different languages. I would even classify motion as a separate language, although it comes as a set of extra instructions to interface to the motion controller(s). The languages are almost interchangeable but not quite. There are missing instructions in LL (PIDE for instance), and any language can be translated directly into ST but the reverse is not true for every single case. Nobody starts directly working with PLC's. They always come from different backgrounds. A PC programmer is naturally going to like ST because it is very similar to PC programming languages. Electrical engineers, electricians and technicians naturally start with LL because that is most familiar to them. Chemical engineers, process engineers, and DCS controls guys always start with FB (function block). This is purely a matter of familiarity. I'm guessing that you are coming from an electrical background because you mentioned LL and sort of hint at the others but probably haven't used them. The best reason for using the other languages is because it is optimized for handling certain types of problems. It may be capable of handling other types but it won't be an ideal fit. SFC works best for organizing other systems when you have a sequence of steps to go through. You can't program purely in SFC, although you can attach fragments of ST right in the SFC and/or call subroutines written in any other language. SFC is slowly catching on because the PLC-5 & SLC implementations are lousy. FB works best when dealing with continuous processes such as chemical metering systems, heating systems, and anything else that deals with a "flow" or a control loop especially with PID loops. Anything that involves "signal processing" beyond trivial things like scaling is best done with FB. ST works best with "traditional" programming problems such as working with information in the form of lists or anything beyond simple statistics. LL works best with boolean logic problems. If there isn't a compelling reason to use one of the specialized languages, I'll generally put everything into LL because that is what is easiest for electricians to understand. But it may take several dozen rungs to do a good PID program compared to a one-page FB diagram. And PC programs (such as sorting & searching) written in LL can be almost impossible to understand compared with ST.

3 of 18

8/18/2012 8:08 PM

learing to program great - Forums.MrPLC.com

http://forums.mrplc.com/index.php?showtopic=15680&st=0&p=77274&#...

The advantage of these languages is that your code will be CLEANER and CLEARER and less likely to contain mistakes if you are solving a problem that these specialized languages deal with. You can still accomplish the same thing in ladder logic, but there is a greater chance of making a mistake. This means that you will be more productive as a programmer by learning these other languages. In the PC world, this is called "aspect oriented programming"...coming up with a specialized language to solve a specific type of problem that is optimized for that problem. In a way, that's what LL is all about...the only problem being that until recently, it was about all there was. Overall, I think you are asking a slightly different question than just different languages. And I can honestly say that I don't have a good answer for you because I don't think there's any "one true" popular way right now. Part of the question you are asking is the same one that everyone has been asking for YEARS with PLC's. In the past, PLC programs have always been written from scratch. There is no code reuse. This is for several reasons. For one, you couldn't make a "generic" data structure. Since subroutines aren't "self contained", it was difficult to simply copy a subroutine from one program to another without rewriting all the variables since the addresses would either conflict or be in different locations. Without these features, copying from one program to another was difficult at best. So even if I wrote a great piece of code that could be reused over and over by everyone else such as say a fuzzy logic controller, there was no good way to copy it from one program to another. Another problem came with something called "separation of concerns". For instance, take the classic starter with feedback from an auxiliary contact block. Most often, any time you need to check if the starter is running, you will simply read the auxiliary contact block directly. What if you come back later and decide to use motor amps to avoid the situation where the motor shaft broke? It becomes a giant search-and-replace hunt. The better way is to put the logic for "motor running" into a separate "motor control" routine or program. Then even if you change the logic for "motor running" status, you change it once and all parts of the system are changed at once. This can be done with LL in Logix 5 or 500 but typically doesn't happen unless you purposely do it. Logix 5000 changed all that. We have UDT's. We have AOI's (add-on-instructions). We have separate programs with their own variables, and separate routines. It is now possible to gain all the same productivity advantages of PC programming, that being modularization which allows for reuse and separation of concerns. Both of these lead to higher productivity and high reliability. The problem is that now we all have to learn new programming habits. There have been some efforts out there. Rockwell is promoting the "Power Programming" model for batch. They've published some materials and some sample code libraries written as add-on instructions. I haven't had a lot of experience yet with Logix 5000 so I'm not really clear on how I intend on changing my habits yet (I'm still learning what I can and can't do with online programming). Whatever happens in the near future, expect to see something a lot more concrete coming along as we all fumble our way towards improved practices and techniques for PLC programming. As to learning programming...anyone can learn welding theory, but until they pick up a stinger and light an arc and learn the skilled part of it (controlling the arc), they will never be a skilled welder. You've got to be able to acquire the feel for it and be able to see what is happening for yourself before you are a skilled welder. That's why it's a skilled trade. Programming is a skill. You can't send someone off to Allen Bradley training or any school for that matter and expect them to come back expert programmers. It takes practice and experience for that. It is also a skilled trade, just one that doesn't happen to have a trade union associated with it. Programming (PLC or otherwise) is similar to chess. You can very easily learn the moves that each of the 6 chess pieces is capable of doing. The key to being a good chess player though is to learn strategies and moves that involve multiple pieces spread over multiple moves. It takes a lot of practice to learn those and to recognize when to use them. A generic method for solving a particular problem in programming terms is an algorithm. Once you get past the basics of what the different commands do, you are immediately faced with how to string them together to solve a problem...what algorithm to use. Some algorithms are better than others, but this is also situation-dependent. As you get more practice and experience (your skill grows), you will recognize the situation and use the best algorithm. In this way it is just like learning how to become good at playing chess. And just as with chess players, each programmer has a slightly different set of strategies, and may be slightly better at using one than another. That's when comparing two programmers that are equally good. So the resulting code from every programmer is different. There are many ways to solve a problem, so you will end up with many methods out there. Even with a given programmer, they may only use a limited number of styles or they may freely mix and match. After working in a plant for a little while though, I can almost instantly tell who wrote a program just by looking at the style. I'm not talking about ST vs. LL vs. FB here. I mean just within 1 programming language there can be several intermixed styles. For instance I often make extensive use of indirect addressing and never use indexed addressing when it comes to tables of data. Many programmers use one, the other, or just make dozens of copies of rungs and skip indirect addressing altogether. The best programs by the way are the simplest to understand, even the most complicated ones. Ever faced a 500 rung monster PLC program all in one ladder that uses masked moves, excessive amounts of latch/unlatch instructions, one shots everywhere, code scattered everywhere, CPT instructions for everything, a few FAL's and FFL/FFU's, and maybe a botched PID or two along with some SQI/SQO instructions thrown in for good measure? Did it have more than 2 useless comments anywhere in it? Did it make excessive use of pulse logic (one shots changing states) and "onion logic" (if A, then step A; if A & B, then step B, if A & B & C then step C...)? Were there dozens of AFI's, shorted branch

4 of 18

8/18/2012 8:08 PM

learing to program great - Forums.MrPLC.com

http://forums.mrplc.com/index.php?showtopic=15680&st=0&p=77274&#...

legs, and at least a dozen forces that were left in the program (not just for troubleshooting)? In addition to style issues and good algorithms, there are two general style issues that will serve you well no matter what any of the other details are. They are Occam's razor, separation of concerns (already mentioned), and organization. Use Occam's razor aggressively. Occam's razor is the principle that "all other things being equal, the simplest solution is the best." For example, use ADD, SUB, MUL, or DIV instead of CPT whenever you have just one math operation. Use MOV instead of CPT when there is no math operation, and use CLR instead of MOV when your intention is to set something to zero. These are called "strength reductions" and make your program run faster in addition to being good practice. Another example are latch/unlatch instructions. If you have a choice between a latch/unlatch instruction, and a "holding rung" or "sealing" rung on a momentary output, the holding/sealing rung combines the latch/unlatch pair into a single rung and it is generally easier to troubleshoot/debug. In addition, it will automatically reset on power up, something the latch/unlatch instructions don't do without additional programming. In terms of this, I have actually seen plants ban certain instructions. Candidates for this are SQI/SQO, ONS (and other one shots), AFI, and OTL/OTU. In principle you can program anything without using any of these instructions. These particular instructions show up frequently in truly bad code. These instructions show up less frequently in truly good code. But good code still uses them to accomplish certain good things. I'll give you a simple example for PLC-5 and SLC. In both of those processors, there are STI (software timed interrupts). An STI is very useful for writing totalizers and PID loops. In a CLX, it has been replaced with the timer task which is a much better way of doing it. The ladder with the STI should not be called from a JSR, only from the STI. But if you read the program, unless you know about the STI, you won't realize how it works or where to look. So I always make it a practice to put the JSR in but put an AFI in front of it and use it for documentation. I also put in COP (block copy) instructions with AFI's indicating where indirect addressing is used, again for documentation. The right way to use these particular instructions is by thinking. There are ways of doing the same thing without the offending instruction. So think...is there another way to do this? Once you know the other way, then apply Occam's razor and pick the simplest approach. Most of the time it won't use the offending instruction but once in a while, it is truly the best way to do things. In addition to everything else, the key to making programs simple is organization. I can easily make a PLC program virtually unreadable. It takes real skill to make a program easy to understand. Be liberal with your documentation. Don't be afraid to use a little extra memory or to spread your program out. Use separation of concerns. For instance in a CLX, put each individual machine system (hydraulic system, pneumatic system, mixer, pump, etc.) in a separate program. Divide it all into logical pieces. There is usually one main program that runs the system and a bunch of little ones that run individual functions. If it is a "batch" or sequence-oriented operation, put each step in a separate routine. The main routine can be an SFC or just another ladder. Use program-level tags whenever it makes sense to do so. The only controller-level tags that you have should be for the hardware, and for inter-PLC, PLC/HMI or interprogram communication. Use UDT's liberally as they make your life simpler and easier. Don't use the hardware bits (input status bits) directly except in the program for that component. For instance, don't use the starter auxiliary input bit for detecting if a mixer is running. Read the bit in the "mixer program" and set a status bit for the rest of your system. That way if you are having trouble with the mixer, you can work on the mixer program and not do dozens of searches trying to find all the little pieces scattered throughout the rest of your programs where the separation of concerns principle was not followed. Most PLC programmers do things just about the same way that they did things with PC programs back in the 70's. You sit down. You may have an IO list (or not), and you start typing and clicking. After a few days, you have your program. You load it onto the processor. You debug. Load, rinse, repeat. If you do it this way, you spend roughly 30% of your time programming and 70% of your time troubleshooting. The troubleshooting part costs real money because you end up doing this out in the plant. I spend at least 50-60% of my time planning. I spent 30% of it programming, and only 10-20% troubleshooting. I always start out with a P&ID (if necessary), a sequence of steps (if it is batch), and usually an I/O list (or lists). I start by writing down what each of the major blocks of my program are and what they should be doing. I write down the tags that will be used for interconnecting the blocks. If it is a P&ID, the FB gets translated directly from it. For any timing-oriented step, I making a timing diagram. For any discrete logic or batch system where a state machine makes sense, I actually draw the state machine out first on a white board and then on paper. When I get done, I have this huge pile of notes and paper and drawings. I program literally by translating everything from my notes and drawings into code. If the program is very complicated, I may then go ahead and write the low level I/O routines and a simulator. Or skip the simulator if it's not needed. The simulator is there to do a crude approximation of what the actual hardware is or should be doing. It is unbelievably useful to have one for training and troubleshooting because you can run everything on the simulator and get some of those pesky obvious bugs out ahead of time, but it also comes with a price tag. It doesn't take long to write one (I don't go overboard on these things because often I'm the only one that will ever use it), but it does take time. The rest of the program is literally a translation directly off my notes & drawings. I don't do programming "off the cuff" anymore except for very simple/small programs. The basic structure is always documented first. The goal here is to do a bunch of planning up front. It reduces errors dramatically because hopefully you've eliminated

5 of 18

8/18/2012 8:08 PM

learing to program great - Forums.MrPLC.com

http://forums.mrplc.com/index.php?showtopic=15680&st=0&p=77274&#...

all the logic errors ahead of time. The bugs are going to be mostly simple things. If you wrote a simulator, those will probably all be eliminated before firing up everything the first time. If you use this approach, all of your bugs are going to be one of two types: 1. When you made a typo and you code does not match your design paperwork. These are the most common and usually easily fixed. Look for these first before looking for design flaws. 2. Flaws in the design. There won't be many of these but if you find one, chances are it's going to be either a show-stopping doozy or a very subtle one. Mostly I've found that these tend to be machine states that I didn't consider ("impossible" situations that always turn out to be possible after all). They are often easily fixed...just add a couple things to your design and also in the program. I think I'm more productive with this approach. But there's a twist to it. Even if I took exactly the same amount of time for the whole project (and it usually takes less time overall), my troubleshooting time is massively lower because the code quality is so much higher. I'm not suggesting that you write a book and implement anything like an SDLC (http://en.wikipedia....ment_Life_Cycle (http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle) ). What I'm suggesting is do a lot of planning and design for your program up front. You will be rewarded in the end with much better quality code and many fewer bugs. The more bugs you have, the more little "patches" you add which weren't well thought out and the more poor quality code you will end up with in the end. Getting back to algorithms, I've attached a reading list below. All of the books except Hugh Jack's book (that you can download for free) are available through Amazon. I apologize for the price of the last one. I wish I could recommend a substitute but I don't know of any other. If you have contacts with anyone from India, the series is published over there (legally) for far less than it costs here. You should be able to get a good idea of the contents from the reviews and other information on Amazon. There used to be a "silicon valley" best seller list somewhere (I haven't seen it in years) and #1, 2, and 5 always got high ratings. All are written for a crowd OTHER than engineers...they are used for text books quite often but they do not require calculus. All are good reference books too even after you've read them and digested them. They cover the theory of electronics, digital electronics, PLC's, and algorithms. If you only want to focus on algorithms and nothing else, then at least cover the 2nd, 4th, and 5th books in that order. If you want a better overall understanding then definitely get #1, 3, and 6. If you are a programmer moving into the PLC world, then my ordering changes to #4, 1, 3, 2, 5, and 6 since you need more help with the electronics. _Art of Electronics_ by Horowitz & Hill _Bebop to the Boolean Boogie_ by Clive Maxfield _Instrumentation Engineers Handbook_, 2 volume set _Automating Manufacturing Systems with PLCs_, Hugh Jack, can be downloaded (google it) _Art of Computer Programming_, volumes 1-4, Donald Knuth _Numerical Recipes in ???_ (pick a language; there isn't "N.R. in Ladder Logic" but I think there's at least Java, C, Pascal, and the original Fortran)

#10 panic mode Posted 31 December 2008 - 05:47 PM


wow.... what a post... the only thing i would add is to definitely do thorough i/o check and calibration as part of comissioning process before any code troubleshooting. happy new 2009 to everyone

#11 TWControls Posted 31 December 2008 - 06:14 PM


(http://forums.mrplc.com/index.php?app=forums&module=forums&section=findpost&pid=77272) JAK, on Dec 31 2008, 02:21 PM, said: TW I could not agree more! I try to use the KISS rule but is seems to be a balancing act. How do you balance the quick programming features vs. the easy to follow (more hours programming)? I like the SQO but following them can be little tuff if you have never seen anything like them before. That's very easy. Rule #1, which makes me very unpopular with many of my fellow programmers, is that troubleshooting a machine should NOT require a laptop. Whenever I would initially get called on a breakdown, I never took out my laptop. The HMIs had diagnostic screens to assist you in figuring out what was wrong. On the very rare occasion that I had to take my laptop out, I made notes of the situation that caused it, the state of the machine, and how I fixed it. Then once everything was running smooth again I would add it to my diagnostics routines.

6 of 18

8/18/2012 8:08 PM

learing to program great - Forums.MrPLC.com

http://forums.mrplc.com/index.php?showtopic=15680&st=0&p=77274&#...

Also, you must did deeper into recurring problems. If you can't fix them, you've got to help identify them, even if they are mechanical. For example, we had a machine that the servo drive would fault out on and I was getting called out constantly. The machine was simple. Cut steel to length, push into the press. The two situations that would cause the fault were hanging in the shear from dull blades and misalignment going into the press. Initially, it just told them "Drive Fault". How many times has someone called over the radio and said "Hey, somethings wrong with this drive, it keeps faulting out". Chances are nothings wrong with the drive, it's in a mechanical bind. We could pull the fault code of the drive...so now we know it's exceeded X amps for Y time. So what's that tell us? It doesn't tell me a thing. After watching the machine a while I realized that if the shear blades were dull, the servo would move 1/16" after cutting the steel, then fault. So if I saw a drive fault and the steel had hardly moved, the diagnostics read "Drive Fault! Check shear blades". If there was misalignment in the press, it would fault 6" to 7" before it reached its final position. So if I saw that the diagnostics would read "Drive Fault! Check die alignment". A very simple program change that not only cut out almost all of my calls to that machine, but almost all maintenance calls period since the operator knew where to look. As far as your SQO, I have lost many arguments on this forum standing up for the SQI/SQO combination. Most people prefer bit logic because it is easy to follow in a program...refer back to rule #1. I admit that since going out on my own I use bit logic on most simple step by step machines so that the customers maintenance staff is familiar with it. But on complex machines with many variables and situations, I still find that it is much easier to make HMI diagnostics for sequencer driven machines. If you've got 64 variables on a process, make yourself a 64 bit sequencer. Do an XOR between your SQI source and SQI Array[Control.pos]. Anywhere your have a 1 in your destination bits is what your waiting on. Want to make a down an dirty HMI diagnostics from this, put your destination bits in multistate indicators. Make the color Green if 0, Red if 1. Then you just look at the HMI for what's red...that's what's stopping the machine. Very basic, but will solve most of your problems such as a switch being out of alignment, an air cylinder hanging and not making a switch, position errors, etc. But the biggest thing is when you think you've got it right, realize that you should never be satisfied, there is always room for improvement. So the next time that mechanical guy tells you he needs you to look at the machine and you know it's the same problem he has had the last 20 times, don't huff and puff, think of how you could have the program better indicate what is wrong next time. Work with them and find a system that works for everyone

#12 paulengr Posted 31 December 2008 - 06:45 PM


(http://forums.mrplc.com/index.php?app=forums&module=forums&section=findpost&pid=77231) kaiser_will, on Dec 30 2008, 09:36 AM, said: That leads into your main question...breaking away from ladder logic to other forms. For 10+ years, most PLC programming software has been IEC 1131-3 compliant as a way to insure that if a hardware company goes out of business that Company X come along and offer software to keep that legacy platform going (i.e., hardware independent). The rub is that IEC 1131 is a documentation standard similar to standards for CAD drawings. It does not define a binary standard such as a text format that you could upload/download from any development system. So everyone makes their stuff have the same instruction sets and more or less conform to IEC 61131, but beyond that there's no compatibility at all. The only thing we have gained is that you stand a pretty good chance of being able to take a program for vendor A and hand-translate it into a program for vendor B. But since that has almost always been the case, we really get much of an improvement except some of the really strange stuff (GE Genius series) dropped out of sight. What you are asking for is what CoDeSys provides (hardware vendor-neutral code). This didn't happen. Quote I have seen different hardware-software companies in the rack-mount market (VME...where you buy open-rack hardware from Company A and programming software from Company B), but not in the PLC market. This is probably due to the US government's large-base of rack-mount hardware and a requirement to have multiple sources for everything. I would argue that in today's world with the exception of high speed equipment, rack-level compatibility is kind of silly. Remote I/O has gotten so fast that you can do distributed I/O now at near rack-level speeds. As long as you have bus compatibility, rack-level compatibility isn't necessary. Instead, we had the "bus wars" that are still ongoing. Modbus has more or less become a de facto standard for at least the slower device-level buses, in spite of the various "Foundation" attempts at standardization which never caught on to any great degree. It is truly open...as in every major PLC brand supports it, and the documentation is freely available.

7 of 18

8/18/2012 8:08 PM

learing to program great - Forums.MrPLC.com

http://forums.mrplc.com/index.php?showtopic=15680&st=0&p=77274&#...

In order to fend off Modbus (and Modbus/TCP), Rockwell has promoted an "open" standard (CIP...DeviceNet, ControlNet, Ethernet/IP). How it is an open standard when you have to ante up thousands even to look at the "open" documentation, and thousands more for testing to prove that you are compliant if you build a device yourself is beyond me. Other vendors have taken a tip from Rockwell and similarly plugged the heck out of their "open" standards. But when you are in the room with an 800 lb. gorilla and the gorilla says it's open, then by gosh it must be. Fortunately though because of the 800 lb. gorilla and the fact that the gorilla has made it difficult but not impossible to be compliant, there are multiple vendors supporting it. Quote What IEC (6)1131-3 has done is driven all hardware companies to offer software that can be programmed in ladder logic, function charts and structured text. All companies have followed the rule, most programs note that their products fit the requirements of the code, but the programming styles and examples are all over the map. I have had one job in my past in which we programmed all in function charts (more of a flowchart style...Steeplechase - Phoenix Contact). I have been trying to get my present employer to experiment as function chart programming can do so many things that ladder logic cannot as it is near multi-tasking. It is highly dependent on the application. Ladder has always had an incredibly strong foothold in the U.S., and Instruction List in Europe (not the same as ST). Function block is amazing agreed, but simply unknown for the most part outside of the DCS world. I love it but I started out in the process control world for a chemical plant...where P&ID's (and function block programming) are a natural fit. It is not such a nice fit for instance in a discrete manufacturing environment with bang-bang type controls for almost everything. That's a big part of the U.S. and automotive (where PLC's started) and why ladder rules even today. If I was back in a process control situation, and it was available, heck yeah I'd use FB. Quote Bottom line (in my opinion) is that programming style is a function of the employer...they establish the standard for their style or they open the door for someone in their organization to develop and rubber-stamp the style. Bottom line, I was charged with that responsibility in my shop. I'm the plant engineer. I'm the law maker, the police, judge, jury, and executioner. I make the rules, and I have to live with them. Fortunately I'm also a benevolent dictator...I accept (sound) advice and criticism, but the buck stops here. When I started here, the only standards we had were so poorly written that I never let them see the light of day outside of the copy I had. The code and PLC implementations were scary to say the least. Let's just say as bad as the "standards" were, the implementations were even worse. A lot of downtime was the direct result of not adhering to any sort of standards. And a lot of the standards were the direct result of actual downtime. The following are the 21 rules. They should be straight forward. A few are a little unusual such as the extensive provisions for armoring up the equipment which go way beyond NFPA 70 (NEC) but it's a foundry. Others focus on making the equipment safe and easy to troubleshoot. Our focus here is safety first, reliability second, production third. Rule #1: Follow NFPA 79, NFPA 70E, and NFPA 70 (NEC), OSHA, and FM standards. Plant standard for safety risk assessment shall be RIA standard. Except for safety-rated PLC's, all safety systems and interlocks must operate independent of the PLC for shutdown/interlock purposes. Interlocks kill power to actuators only (not inputs) for troubleshooting purposes. Manual resets required and only one per safety circuit for emergency shutdown systems. PLC must read safety circuits and respond accordingly (go to safe state) during shutdown. Killing power to I/O cards not acceptable (must kill power to outputs). Rule #2: Jumpers (software or hardware, including AFI's, forces, shorted branches, and similar functions) shall be treated as bypassed interlocks. They may not be left in place except with involvement of a supervisor. They can be used only if the system safety can be maintained (never jumper a safety system). A work order will be entered immediately as a safety work order (highest priority) to remove them. Rule #3: All current PLC program changes, no matter how minor, MUST be saved to the network (common) drive. NO EXCEPTIONS. Make subfolders only for development versions. Rule #4: Online programming for minor changes and troubleshooting only. Major changes made offline and scheduled for downtime. Rule #5: All PLC programs must be documented and written with troubleshooting as a first priority. Modular programming style and KISS principles shall be applied liberally. This means that the following instructions shall be avoided as a general rule: MCR, ONS, OSR, OSF, OTL, OTU, SQI, SQO. Exception: these instructions shall be allowed if it makes the program simpler and more clear than any alternative (KISS). Rule #6: Programming software shall not be left open if you leave the work area (limited licenses, issues with saving programs). Rule #7: When choosing hardware, preference shall be given to Micrologix 1100, 1400, and ControlLogix 1756-L6x series PLC's as these are the corporate standards. ML 1000, 1500, SLC, and PLC-5 series are for replacement only. The plant standard HMI is a Red Lion G-series, or a thin client on a Nematron touch screen with Cimplicity PE. Both PLC's and HMI's shall be networked for troubleshooting and maintenance whenever practical.

8 of 18

8/18/2012 8:08 PM

learing to program great - Forums.MrPLC.com

http://forums.mrplc.com/index.php?showtopic=15680&st=0&p=77274&#...

Rule #8: The plant standard for networking is Ethernet/IP. Switches shall be Hirschmann (managed or unmanaged). There are a bunch of rules on setting this up correctly. Other network types are for replacement/backwards compatibility only. Cabling shall be CAT 5E UTP, preferably armored or in conduit. On runs that exceed 100 meters, indoor/outdoor grade UV and moisture resistant 62.5/125 micron multimode fiber shall be used. For runs over 250 meters, LX/LH transceivers shall be used. All backbone runs shall be gigabit fiber regardless of the length of the run. At least one open Ethernet port and one 110 VAC receptacle designated for troubleshooting purposes shall be furnished near each PLC. Rule #9: Preference shall be given to existing warehouse parts inventories for commonality of parts. Plant color code is black/red/blue for 480 VAC (no 220VAC present) phasing, green/grey for ground, white for neutral, black for 110 VAC (red for 220 VAC second hot) power, blue for 24 VDC power, brown for 24 VDC common, red for 110 VAC signal, yellow for 24 VDC signal. All signal lines shall be labelled with preference given to PLC I/O as a reference number. Rule #10: Preference shall be given to 24 VDC IO where practical. For instance all proximity switches shall be 24 VDC but whereas starters are not commonly equipped for 24 VDC operation, 110 VAC shall be allowed. 110 VAC output terminals shall be individually fused with blown fuse indication. Diagnostic IO cards to be used when available. Consideration for arc flash shall be made with all power supply systems. The plant standard is that an arc flash PPE rating of Class 1 shall be maintained whenever possible. All cabinets shall be marked as to voltage and arc flash rating (we have a placard for the format). Rule #11: Arc flash PPE requirements are Class 1, Class 4, unrated (do not enter), regardless of the labelling. For Class 4 PPE, the written arc flash procedure shall be used. Rule #12: Contractors must supply documented copies of programs, configuration settings, etc., necessary for maintaining equipment. Except for pre-packaged noncustomer-specific products "runtime-only", undocumented, or otherwise "locked down" systems shall not be acceptable (we own the code). Rule #13: Plant dust is electrically conductive and thermally insulative. All "outside" areas are subject to potential mechanical damage from overhead cranes, fork trucks, and such. NEMA 3R shall be considered the minimum enclosure rating for "clean" areas, NEMA 4 or 12 for other areas, NEMA 4X (SS only) in corrosive areas with PVC-coated conduits or equivalent protection. NEMA 1 is strictly prohibited except in offices. Enclosure entries shall be from the bottom whenever practical or the sides (never the top). Entries must maintain box integrity through the use of Meyers hubs, cord grips with rubber stoppers, and the like. Roxtec fittings have been found to be adequate for "PC" cabling. All receptacles shall have weather proof while-in-use covers except in office areas. "M12" and similar types of connectors and connection systems are recommended and encouraged where available and where equipment can be designed to avoid physical damage. Rule #14: Our plant is subject to high temperature conditions and molten metal splash. Use of silicone coated refractory jackets (splash protection only) and/or heat shields shall be considered in hot metal areas. Wiring in those areas shall be TFE (THHN in other areas is acceptable). Rule #15: Conduit minimum size is 3/4". FMC shall not be used (LFMC only). MC & AC allowed with prior authorization. (No matter how hard we try to enforce it, somebody can and will climb on your conduit). Conduit to be secured as required by NEC rules. Rule #16: Starters and drive disconnects to be of the combination disconnect type with pull down (not rotary) handles. Instantaneous trip protection with current limiting (dual element) fuses or circuit breakers (not mag trip). Overload protection to be provided with electronic overloads (not bimetallic). Vaccuum starters to be used on NEMA size 4 or larger starters. Plant drive standard is Rockwell Powerflex (any series). Disconnects shall be made available and convenient for maintenance of all machine functions without necessity of opening panels and with good machine isolation design. Rule #18: Preference given to vibration-resistant fittings. Terminals to be insulation displacement (preferred) or spring clamp type when available. Rule #19: Plant has extensive and large inductive loads. Surge protective devices (GDT's on communication/signal lines, MOV's on others) and filtering (Islatrol) provided for all electronic components. MOV's must include "blown" indicators since they are consumable devices. A CVT is NOT an acceptable device as it has been shown to consistently provide little or no protection except against cold temperatures. Rule #20: Solidly grounded Delta-Wye configuration for transformers with disconnect on primary side and fused or electronic circuit breaker protection both upstream and downstream minimum. System coordination shall be maintained. Preference given to electronic circuit breakers where available for distribution gear over thermal/magnetic types such as GE Spectra series. Draw-out circuit breakers shall be electronic-type only. Preference shall be for lighted fuse blocks. Rule #21: PLC's and related communication equipment shall be given separate power system and designed to require a separate lockout procedure under normal circumstances (standard lockout procedures leave PLC's operational). PLC's and I/O panels shall be fused at the enclosure entrance with lighted fuse blocks that can double as disconnects. Preference shall be for 5x20 mm fuses where available. Power supplies must have a "power good" or voltage output reading for troubleshooting purposes. Rule #22: Plant standard for analog signals is 4-20mA current loops. HART digital loops will be given consideration. Analog voltage control is not a preferred option due to calibration and noise issues.

#13 TWControls Posted 31 December 2008 - 07:20 PM


(http://forums.mrplc.com/index.php?app=forums&module=forums&section=findpost&pid=77279) paulengr, on Dec 31 2008, 06:45 PM, said: Rule #5: All PLC programs must be documented and written with troubleshooting as a first priority. Modular programming style and KISS principles shall be applied liberally. This means that the following instructions shall be

9 of 18

8/18/2012 8:08 PM

learing to program great - Forums.MrPLC.com

http://forums.mrplc.com/index.php?showtopic=15680&st=0&p=77274&#...

avoided as a general rule: MCR, ONS, OSR, OSF, OTL, OTU, SQI, SQO. Exception: these instructions shall be allowed if it makes the program simpler and more clear than any alternative (KISS). I kind of brushed on this but I don't think that it is that these instructions should be avoided, but rather they should be properly used. They all have their place, and at the same time are probably the most misused instructions. Quote Rule #15: Conduit minimum size is 3/4". FMC shall not be used (LFMC only). MC & AC allowed with prior authorization. (No matter how hard we try to enforce it, somebody can and will climb on your conduit). Conduit to be secured as required by NEC rules. Is 1/2" conduit even allowed for current carrying conductors anymore? Quote Rule #16: Starters and drive disconnects to be of the combination disconnect type with pull down (not rotary) handles. Instantaneous trip protection with current limiting (dual element) fuses or circuit breakers (not mag trip). Overload protection to be provided with electronic overloads (not bimetallic). Vaccuum starters to be used on NEMA size 4 or larger starters. Plant drive standard is Rockwell Powerflex (any series). Disconnects shall be made available and convenient for maintenance of all machine functions without necessity of opening panels and with good machine isolation design. How come no rotary disconnects? Quote Rule #22: Plant standard for analog signals is 4-20mA current loops. HART digital loops will be given consideration. Analog voltage control is not a preferred option due to calibration and noise issues. Why the consideration for HART?

#14 Nathan Posted 01 January 2009 - 12:36 AM


TW - excellent advice on all responses. I agree. Paul - you're officially not allowed to complain about long winded posts Quote This post is extremely long winded (even for me).

#15 paulengr Posted 01 January 2009 - 11:17 AM


(http://forums.mrplc.com/index.php?app=forums&module=forums&section=findpost&pid=77282) TWControls, on Dec 31 2008, 07:20 PM, said: (http://forums.mrplc.com/index.php?app=forums&module=forums&section=findpost&pid=77279) paulengr, on Dec 31 2008, 06:45 PM, said: Rule #5: All PLC programs must be documented and written with troubleshooting as a first priority. Modular programming style and KISS principles shall be applied liberally. This means that the following instructions shall be avoided as a general rule: MCR, ONS, OSR, OSF, OTL, OTU, SQI, SQO. Exception: these instructions shall be allowed if it makes the program simpler and more clear than any alternative (KISS). I kind of brushed on this but I don't think that it is that these instructions should be avoided, but rather they should be properly used. They all have their place, and at the same time are probably the most misused instructions. I personally don't care if you use them properly. The point isn't to ban them entirely. It's a reminder to think twice about this. I put in this rule to overcome a bunch of bad habits. I also explained earlier how and why I would happily use an AFI (for documentation purposes).

10 of 18

8/18/2012 8:08 PM

learing to program great - Forums.MrPLC.com

http://forums.mrplc.com/index.php?showtopic=15680&st=0&p=77274&#...

SQI/SQO can be used properly as well. Some descriptions of using it as a diagnostic/error signal are totally appropriate. The problem is that the manual says "sequencer" and not "drum sequencer". So if you have a state machine that may not have 100% identical sequences of states every time (A, B, C..., and never skip B or go from C back to B), then SQI/SQO can work out. Otherwise, better be thinking about using SFC or integer or bit-based state machines. I had a programmer in this shop in the past that used them for everything and every single usage was actually inappropriate...there were tons of manual adjustments of .POS all over the code. The SQI "map" looked like an identity matrix (a diagonal line of ones) so he wasn't even using the multi-bit state recognition feature either. What it did in effect was to create an integer-based state machine within a goofy storage register (an R file). Same programmer also felt that whenever there was a problem with a state transition, just dump ONS all over everything. This will "usually fix it". And trained others to do the same. The general rule was that an ONS can almost "never hurt" and will "usually help". Most state logic thus became pulse logic which is a particular bear to troubleshoot. Another programmer would put an MCR at the beginning and end of the program. Then tie this to an input. The input was an "E-Stop". Trouble is that this was a hydraulic machine that made extensive use of proportional valves. Since these are set via analog values (not momentary outputs), all kinds of crazy non-emergency stop things would happen, resulting in all kinds of patch code. Most of the patch code couldn't execute anyways due to the presence of the E-Stop (rungs going false), and none of it was deleted, making a bad situation worse. Plant personnel eventually decided to just live with it and installed manual blocking valves to help control the situation when the real problem was a botched E-Stop implementation. All of these programmers came from the corporate office. We needed to erect political barricades on several of them and also retrain our own people. Hence the rule, and hence KISS. Quote Quote Rule #15: Conduit minimum size is 3/4". FMC shall not be used (LFMC only). MC & AC allowed with prior authorization. (No matter how hard we try to enforce it, somebody can and will climb on your conduit). Conduit to be secured as required by NEC rules. Is 1/2" conduit even allowed for current carrying conductors anymore? Even if it wasn't the problem is when you have sensors all over a machine on a 110 VAC system and you run the dinkiest, cheapest conduit you can get. Just about everything about maintaining the machine becomes a problem because the conduit bends and kinks so easy. It's a case of nickels chasing dollars. Quote Quote Rule #16: Starters and drive disconnects to be of the combination disconnect type with pull down (not rotary) handles. Instantaneous trip protection with current limiting (dual element) fuses or circuit breakers (not mag trip). Overload protection to be provided with electronic overloads (not bimetallic). Vaccuum starters to be used on NEMA size 4 or larger starters. Plant drive standard is Rockwell Powerflex (any series). Disconnects shall be made available and convenient for maintenance of all machine functions without necessity of opening panels and with good machine isolation design. How come no rotary disconnects? I have them in a few places and they are trouble in every spot, even brand new ones, even from reputable brands like Allen Bradley. As a group, they have sloppy mechanical mechanisms, especially once they wear. It is always sort of difficult to tell what position the disconnect is at in the first place and they are very sloppy about this (is it off or on?) even when brand new. On top of that mechanics will tend to use wrenches and such to try to "fix" them if they think that the mechanism might not be fully (dis)engaged. And depending on enclosure depth, it is often difficult to get the pin on the end of the rod to go into the disconnect hole. If you try to rack one in or out with the door open (sometimes necessary for troubleshooting), often you need a fairly long set of pliers or an adjustable wrench. After a few years of this treatment, the rod gets rounded off, making the problem worse. By contrast, verticals have a hefty overhung cam mechanism that always gives a clean engage/disengage action. I've never run into one even in the bigger (size 4 or 5) sizes that can't be racked with the door open without too much effort. I've seen the springs get weak over time and need replacement and GE was notorious for a few years for using plastic handles but that's about it. It's simple and reliable. Same can't be said for rotaries.

11 of 18

8/18/2012 8:08 PM

learing to program great - Forums.MrPLC.com

http://forums.mrplc.com/index.php?showtopic=15680&st=0&p=77274&#...

Quote Quote Rule #22: Plant standard for analog signals is 4-20mA current loops. HART digital loops will be given consideration. Analog voltage control is not a preferred option due to calibration and noise issues. Why the consideration for HART? Here's my feeling on things. What I don't want to do unless speed/distance does become an issue is to buy a voltageoutput card and have to deal with EMI and calibration pots to keep the thing operating correctly. Been there, done that, and we already have WAY too much of that going on. Someone was even sticking calibration pots (Action IO) onto the current loops when started here! I'd prefer a direct digital interface such as a 20-COMM-XXX card in a Powerflex drive (XXX=your field bus of choice). There is no calibration issue, and you get some diagnostics and sometimes additional controls that may be useful. HART is very similar in that regard. HART tends to confuse people though because of it's nature (digital signals superimposed onto a current loop carrier) so I mentioned it in particular. If I had said "digital" then I've had a couple vendors push for "digital current loops". That is, an ASCII signal using current pulses instead of RS-485 or RS-232. I've also run into more than one chemical pump vendor that jumps to the conclusion that I like pulse-frequency modulation or pulse-width modulation for pump control. Both have their place but they aren't what we typically use around here. I have a few turbine flow meters around here and some folks can't seem to get it through their heads why just tying the contacts to a PLC input is not a good idea from a calibration point of view (just because it happens to work in one particular application and not so good in others), and why I want to replace these with magnetic or coriolis flow meters. This post has been edited by paulengr: 01 January 2009 - 11:18 AM

#16 TWControls Posted 01 January 2009 - 11:47 AM


Quote Same programmer also felt that whenever there was a problem with a state transition, just dump ONS all over everything. This will "usually fix it". And trained others to do the same. The general rule was that an ONS can almost "never hurt" and will "usually help". Most state logic thus became pulse logic which is a particular bear to troubleshoot. Another programmer would put an MCR at the beginning and end of the program. Then tie this to an input. The input was an "E-Stop". Trouble is that this was a hydraulic machine that made extensive use of proportional valves. Since these are set via analog values (not momentary outputs), all kinds of crazy non-emergency stop things would happen, resulting in all kinds of patch code. Most of the patch code couldn't execute anyways due to the presence of the E-Stop (rungs going false), and none of it was deleted, making a bad situation worse. Plant personnel eventually decided to just live with it and installed manual blocking valves to help control the situation when the real problem was a botched E-Stop implementation. I'll definitely agree with both of these instances. But I think it goes back to using them when they are the proper instruction...which neither situation above does. Kind of goes along with the programmer that uses the OTL/OTU to execute the sequence of operation. (http://forums.mrplc.com/index.php?app=forums&module=forums&section=findpost&pid=77293) paulengr, on Jan 1 2009, 11:17 AM, said: Quote Quote Rule #16: Starters and drive disconnects to be of the combination disconnect type with pull down (not rotary) handles. Instantaneous trip protection with current limiting (dual element) fuses or circuit breakers (not mag trip). Overload protection to be provided with electronic overloads (not bimetallic). Vaccuum starters to be used on NEMA size 4 or larger starters. Plant drive standard is Rockwell Powerflex (any series). Disconnects shall be made available and convenient for maintenance of all machine functions without necessity of opening panels and with good machine isolation design. How come no rotary disconnects?

12 of 18

8/18/2012 8:08 PM

learing to program great - Forums.MrPLC.com

http://forums.mrplc.com/index.php?showtopic=15680&st=0&p=77274&#...

I have them in a few places and they are trouble in every spot, even brand new ones, even from reputable brands like Allen Bradley. As a group, they have sloppy mechanical mechanisms, especially once they wear. It is always sort of difficult to tell what position the disconnect is at in the first place and they are very sloppy about this (is it off or on?) even when brand new. On top of that mechanics will tend to use wrenches and such to try to "fix" them if they think that the mechanism might not be fully (dis)engaged. And depending on enclosure depth, it is often difficult to get the pin on the end of the rod to go into the disconnect hole. If you try to rack one in or out with the door open (sometimes necessary for troubleshooting), often you need a fairly long set of pliers or an adjustable wrench. After a few years of this treatment, the rod gets rounded off, making the problem worse. By contrast, verticals have a hefty overhung cam mechanism that always gives a clean engage/disengage action. I've never run into one even in the bigger (size 4 or 5) sizes that can't be racked with the door open without too much effort. I've seen the springs get weak over time and need replacement and GE was notorious for a few years for using plastic handles but that's about it. It's simple and reliable. Same can't be said for rotaries. How about your local motor disconnects? Do you use pull downs there too? I agree with the problem of using an adjustable wrench on the shaft. I always install the NFPA79 option which allows for turning the disconnect on/off and locking with the door open. As far as rod alignment, I find that is usually more of an issue with the installer not taking the time to double check their measurements. Not that I'm against the pull down...besides the fact that they never seem to be available in SS or Fiberglass in the size I need. It seems I continue to move more into corrosive environment work. Quote HART tends to confuse people though because of it's nature (digital signals superimposed onto a current loop carrier) so I mentioned it in particular. I've never worked with HART, mainly because I'm in the confused group of people. If you had a problem, how would you go about troubleshooting it? Ok...I've just got to ask, how many words do you type a minute?

#17 paulengr Posted 01 January 2009 - 11:54 AM


(http://forums.mrplc.com/index.php?app=forums&module=forums&section=findpost&pid=77277) panic mode, on Dec 31 2008, 05:47 PM, said: the only thing i would add is to definitely do thorough i/o check and calibration as part of comissioning process before any code troubleshooting. I didn't cover startup procedures but I agree that if you do this step first no matter how boring/tedious/slow, you knock off probably 80% of the startup problems.

#18 Ken Moore Posted 01 January 2009 - 09:33 PM


Quote HART tends to confuse people though because of it's nature (digital signals superimposed onto a current loop carrier) so I mentioned it in particular. Quote I've never worked with HART, mainly because I'm in the confused group of people. If you had a problem, how would you go about troubleshooting it? HART (Highway Addressable Remote Transducer Protocol) is well known in the Petro/Chemical industries. I have

13 of 18

8/18/2012 8:08 PM

learing to program great - Forums.MrPLC.com

http://forums.mrplc.com/index.php?showtopic=15680&st=0&p=77274&#...

been using it for many many years. Even in plants that don't use the HART protocol for control, it is still used for calibration and such (it's original intent), our cal. techs use a hand held device from Emerson. You can also buy a HART modem for laptops. The HART protocol "rides" on the 4-20mA signal, kind of like having DSL riding on your analog phone line at home. Wikipedia has a decent write up on it: http://en.wikipedia....i/HART_Protocol (http://en.wikipedia.org /wiki/HART_Protocol) But this one give much more information very detailed on exactly how the digital rides on the analog and is really quite good: http://www.analogser...tm#Introduction (http://www.analogservices.com /about_part1.htm#Introduction)

#19 TWControls Posted 02 January 2009 - 07:05 AM


(http://forums.mrplc.com/index.php?app=forums&module=forums&section=findpost&pid=77301) Ken Moore, on Jan 1 2009, 09:33 PM, said: HART (Highway Addressable Remote Transducer Protocol) is well known in the Petro/Chemical industries. I have been using it for many many years. Even in plants that don't use the HART protocol for control, it is still used for calibration and such (it's original intent), our cal. techs use a hand held device from Emerson. You can also buy a HART modem for laptops. The HART protocol "rides" on the 4-20mA signal, kind of like having DSL riding on your analog phone line at home. Wikipedia has a decent write up on it: http://en.wikipedia....i/HART_Protocol (http://en.wikipedia.org /wiki/HART_Protocol) But this one give much more information very detailed on exactly how the digital rides on the analog and is really quite good: http://www.analogser...tm#Introduction (http://www.analogservices.com /about_part1.htm#Introduction) Hi Ken Thanks for the links. Your second one doesn't seem to be working right now, I'll try later

#20 paulengr Posted 02 January 2009 - 08:15 AM


(http://forums.mrplc.com/index.php?app=forums&module=forums&section=findpost&pid=77294) TWControls, on Jan 1 2009, 11:47 AM, said: How about your local motor disconnects? Do you use pull downs there too? Yes. It's called a safety disconnect. But there may be a difference here...in most of the places I've worked, we treat 5 HP or less almost like a fractional HP motor because usually anything I work with starts at Size 1 and goes up from there. Motor wiring is actually a huge pain in the rear. In general unless there's a compelling reason for doing so, I avoid local motor disconnects because it adds another piece of hardware to fail plus two more potential points of failure in terms of the lugs. You still have to go back to the primary disconnect for lockout purposes anyways. Overall though I've become more and more intrigued by the wiring systems that are being promoted by Hubbell and the like. It would save an immense amount of time to have everything prewired on a cord-and-plug type system with a local disconnect but these systems almost never go above 5 HP so they miss out on 90% of the locations where I have to do regular motor changes. I have considered making my own of sorts and most recently, I sort of did. We bought Meltrics fittings in a particularly bad location which was using 15 HP DC motors. It's still not a pre-engineered solution but we came pretty close. Quote Not that I'm against the pull down...besides the fact that they never seem to be available in SS or Fiberglass in the size I need. It seems I continue to move more into corrosive environment work. Never had that problem. Since this is an AB forum, if you make the mistake of checking out the 1494H, you won't find

14 of 18

8/18/2012 8:08 PM

learing to program great - Forums.MrPLC.com

http://forums.mrplc.com/index.php?showtopic=15680&st=0&p=77274&#...

what you are looking for. Instead, check out 1494F. If you are a cheapskate and labor is not a high cost for you, you could buy a 1494C and an enclosure from Saginaw Controls but my guys are not great fabricators so I wouldn't go in that direction. Best I have done in this direction is to buy a 1494GX or 1494GY (extended length fused safety disconnect) which is effectively a combination starter disconnect minus the starter for use as a mounting enclosure for a drive so that I can achieve the effect of a packaged drive system with short circuit protection and lockable disconnect capability without buying AB's funky rotary disconnect panel or doing a lot of fabrication work. Quote I've never worked with HART, mainly because I'm in the confused group of people. If you had a problem, how would you go about troubleshooting it? One of the big selling points for devices with Modbus/RTU or DeviceNet is that you can get a lot more data (diagnostics), you get digital (no calibration needed) connections to the device, and you can calibrate it (remotely) without needing a tiny screen/keypad that is probably gunked up with dirt anyways. HART does all that but does it with an existing 4-20mA current loop instead of changing out everything. HART is very popular in process industries. It was pretty much designed for and targets their businesses. So when you see HART, you've got to think in terms of the control system for a big refinery, chemical plant, or a paper mill. For a widget plant, HART looks expensive, slow, complicated, and much ado about nothing. It makes no sense at all for them because it wasn't designed for them. That's where Modbus/RTU or DeviceNet or similar things come into play. Process plants probably would like those networks too but especially existing plants have a hard time justifying changing out everything compared to just changing the instrument spec and getting HART every time they replace a sensor. Quite often HART stuff also includes a couple extra digital input or output connections so you could tie in nearby "dumb" sensors through the same interface. HART works by superimposing 1200 baud sine wave pulses over an existing 4-20mA loop. The frequency of those pulses is high enough that the normal 4-20mA loop electronics naturally filter them off (they are invisible to the analog loop). First start by checking if you have any 4-20mA signal at all. If not, then you start troubleshooting the traditional way. Assuming that you are at least getting some signal, and you aren't using the digital part in the PLC (or haven't set up any of the diagnostic info), then troubleshooting is a matter of clamping a HART calibrator (either a cheap $300 HART modem and a laptop running the software, or several thousand dollar standalone calibrator) across your receiver (any receiver will usually do) or even a 250 ohm resistor that you carry in your tool bag. Normally this means doing it at the input card at the PLC, not 500 feet up on the upwind side of a distillation column with a 40 MPH wind and 12 F air temperature with sleet hitting you in the face. After about a minute, you will have full access to the instrument's on board diagnostic information. If it can self-diagnose, it will tell you what's wrong. Quote Ok...I've just got to ask, how many words do you type a minute? 80-85.

#21 BobLfoot Posted 02 January 2009 - 05:00 PM


(http://forums.mrplc.com/index.php?app=forums&module=forums&section=findpost&pid=77316) paulengr, on Jan 2 2009, 08:15 AM, said: In general unless there's a compelling reason for doing so, I avoid local motor disconnects because it adds another piece of hardware to fail plus two more potential points of failure in terms of the lugs. You still have to go back to the primary disconnect for lockout purposes anyways. Just curious but how do you reconcile NEC 2008 Section 430.102 B(1) "A disconnecting means for the motor shall be located in sight from the motor location and the driven machinery location. "

#22 paulengr Posted 02 January 2009 - 07:52 PM

15 of 18

8/18/2012 8:08 PM

learing to program great - Forums.MrPLC.com

http://forums.mrplc.com/index.php?showtopic=15680&st=0&p=77274&#...

(http://forums.mrplc.com/index.php?app=forums&module=forums&section=findpost&pid=77321) BobLfoot, on Jan 2 2009, 05:00 PM, said: (http://forums.mrplc.com/index.php?app=forums&module=forums&section=findpost&pid=77316) paulengr, on Jan 2 2009, 08:15 AM, said: In general unless there's a compelling reason for doing so, I avoid local motor disconnects because it adds another piece of hardware to fail plus two more potential points of failure in terms of the lugs. You still have to go back to the primary disconnect for lockout purposes anyways. Just curious but how do you reconcile NEC 2008 Section 430.102 B(1) "A disconnecting means for the motor shall be located in sight from the motor location and the driven machinery location. " This requirement does not apply in industrial installations. Keep reading down further in your code book. You stopped too early. The exception below 430.102 B is the important part: "Exception to (1) and (2): The disconnecting means for the motor shall not be required under either condition (a) or (b), provided the controller disconnecting means required in accordance with 430.102(A) is individually capable of being locked in the open position. The provision for locking or adding a lock to the controller disconnecting means shall be installed on or at the switch or circuit breaker used as the disconnecting means and shall remain in place with or without the lock installed. (a) Where such a location of the disconnecting means for the motor is impracticable or introduces additional or increased hazards to persons or property (b) In industrial installations, with written safety procedures, where conditions of maintenance and supervision ensure that only qualified persons service the equipment" There are three key requirements in the exception: industrial installations, written safety procedures, and qualified persons. NEC 2008 clarified the definition of qualified persons. It now points out that the safety training that qualifies a worker is training in hazard recognition and avoidance (see the definition of a Qualified Person in Article 100). It does not require that everyone has to be a licensed electrician or working under the supervision of one. This is harmonious with the explanatory material and wording of NFPA 70E and similar provisions in almost all safety codes. OSHA 1910.147 (lockout/tagout) requires hazard recognition and lockout/tagout procedures to be established and it requires training (1910.147(7)(i), 1910.147(7)(ii)) in hazard recognition (1910.147(7)(i)(A)) and procedures to avoid the hazard (1910.147(7)(i)(B)). It requires them to be written (CFR 1910.147(4)(i)). In addition, the NEC Handbook mirrors my own reading of this in a much shorter explanation following 430.102: "Industrial facilities that comply with OSHA, CFR 1910.147 The Control of Hazardous Energy (Lockout/Tagout), are permitted to have the disconnecting means located remotely." You also missed why you have to lock out at the primary disconnect. OSHA and arc flash require you to kill everything for proper lockout. Does control power at the starter count? If you are working on the starter unless you have an exception for troubleshooting/repairs at the starter (you are able to exercise the "live work" exceptions in NFPA 70E), yes. I have seen 3 ways to implement this. Only the first one is fairly expensive: 1. Put a control power transformer in each starter. PLC control is achieved through relays (either IO card relays or separate control relays) which are either external to the starter or have covered contacts. 2. Go with control power <50 Volts (AC or DC). This makes it "safe" at least according to arc flash provisions but sometimes it is hard to find compatible starter coils. 3. Use a small line powered (480 VAC) control relay in series with the auxiliary contacts (for feedback) and the main starter coil. It still allows for common control power but interrupts it providing similar functionality. An additional problem is that many safety disconnect designs are meant as just that...disconnects. They are not full fledged switches. The overhung cam or spring-loaded disconnect mechanism is one-way. Most of them are not designed for closing. So if you close it under load, you risk having the equipment explode on you. This has happened many times at different places I've worked at. Aside from pure laziness, locking out at the primary (controller) disconnect prevents this from happening. Nobody can inadvertently close the disconnect under load (if you use one of the above designs) because you killed power at the starter. If you still insist on being able to kill power at the secondary disconnects, there's still a safe way to do it. You need to add an auxiliary contact at each disconnect. Wire them all in series with the starter coil so that opening a disconnect also opens the starter coil. This post has been edited by paulengr: 02 January 2009 - 08:08 PM

16 of 18

8/18/2012 8:08 PM

learing to program great - Forums.MrPLC.com

http://forums.mrplc.com/index.php?showtopic=15680&st=0&p=77274&#...

#23 TWControls Posted 09 January 2009 - 08:49 AM


(http://forums.mrplc.com/index.php?app=forums&module=forums&section=findpost&pid=77323) paulengr, on Jan 2 2009, 07:52 PM, said: This requirement does not apply in industrial installations. Keep reading down further in your code book. You stopped too early. The exception below 430.102 B is the important part: "Exception to (1) and (2): The disconnecting means for the motor shall not be required under either condition (a) or (b), provided the controller disconnecting means required in accordance with 430.102(A) is individually capable of being locked in the open position. The provision for locking or adding a lock to the controller disconnecting means shall be installed on or at the switch or circuit breaker used as the disconnecting means and shall remain in place with or without the lock installed. (a) Where such a location of the disconnecting means for the motor is impracticable or introduces additional or increased hazards to persons or property (b) In industrial installations, with written safety procedures, where conditions of maintenance and supervision ensure that only qualified persons service the equipment" There are three key requirements in the exception: industrial installations, written safety procedures, and qualified persons. NEC 2008 clarified the definition of qualified persons. It now points out that the safety training that qualifies a worker is training in hazard recognition and avoidance (see the definition of a Qualified Person in Article 100). It does not require that everyone has to be a licensed electrician or working under the supervision of one. This is harmonious with the explanatory material and wording of NFPA 70E and similar provisions in almost all safety codes. OSHA 1910.147 (lockout/tagout) requires hazard recognition and lockout/tagout procedures to be established and it requires training (1910.147(7)(i), 1910.147(7)(ii)) in hazard recognition (1910.147(7)(i)(A)) and procedures to avoid the hazard (1910.147(7)(i)(B)). It requires them to be written (CFR 1910.147(4)(i)). In addition, the NEC Handbook mirrors my own reading of this in a much shorter explanation following 430.102: "Industrial facilities that comply with OSHA, CFR 1910.147 The Control of Hazardous Energy (Lockout/Tagout), are permitted to have the disconnecting means located remotely." By the book, you are correct, but from my past experience I feel this argument should be more of the exception than the rule. Procedures are great, but when they become a major inconvenience, they lead to shortcuts For example I was working at a plant several months ago with strict safety procedures. I was troubleshooting a blower motor on a tower 4 stories up with no local disconnect. To lock/unlock the motor I had to climb down the 4 story tower, walk about 300', then climb 3 flights of stairs to the MCC. About the 10th time doing this with fall protection, I was worn out. Being a contractor, I followed their procedures to a tee, but maintenance guys admitted they normally just radioed someone to take their lock off as long as no safety personnel were around which is definitely a unsafe act. Also, it just gives me a sense of security being able to see that it is disconnected locally even if the primary disconnect is locked out when working on something. Even if procedures call for a waiting period and signatures of the supervisor, safety director, and plant manager before a lock can be cut, I'm always weary of the guy with a set of bolt cutters trying to get something running before his shift is suppose to end. Quote You also missed why you have to lock out at the primary disconnect. OSHA and arc flash require you to kill everything for proper lockout. Does control power at the starter count? If you are working on the starter unless you have an exception for troubleshooting/repairs at the starter (you are able to exercise the "live work" exceptions in NFPA 70E), yes. I have seen 3 ways to implement this. Only the first one is fairly expensive: 1. Put a control power transformer in each starter. PLC control is achieved through relays (either IO card relays or separate control relays) which are either external to the starter or have covered contacts. 2. Go with control power <50 Volts (AC or DC). This makes it "safe" at least according to arc flash provisions but sometimes it is hard to find compatible starter coils. 3. Use a small line powered (480 VAC) control relay in series with the auxiliary contacts (for feedback) and the main starter coil. It still allows for common control power but interrupts it providing similar functionality. Neither says you have to kill everything as far as I know. The NFPA 70E Blue Book actually elaborates on this in 120.1 Process of Achieving an Electrically Safe Work Condition. It says "If an electrically safe work condition does exist, no electrical energy is in the proximity of the work task". There are many situations where I believe changing a motor out would fall into this situation. Quote

17 of 18

8/18/2012 8:08 PM

learing to program great - Forums.MrPLC.com

http://forums.mrplc.com/index.php?showtopic=15680&st=0&p=77274&#...

An additional problem is that many safety disconnect designs are meant as just that...disconnects. They are not full fledged switches. The overhung cam or spring-loaded disconnect mechanism is one-way. Most of them are not designed for closing. So if you close it under load, you risk having the equipment explode on you. This has happened many times at different places I've worked at. Very good point, but let's say you have a dual pump application and one motor goes bad. You need to remove it from service to have it rebuilt. How do you safely put the system back into service without a way to locally lock out that motor? Even if they go to an MCC, I think it would be safer for there to be a local disconnect that you can see locked with the wires laying in the floor. Quote Aside from pure laziness, locking out at the primary (controller) disconnect prevents this from happening. Nobody can inadvertently close the disconnect under load (if you use one of the above designs) because you killed power at the starter. If you still insist on being able to kill power at the secondary disconnects, there's still a safe way to do it. You need to add an auxiliary contact at each disconnect. Wire them all in series with the starter coil so that opening a disconnect also opens the starter coil. I agree that this is very good practice and also lets the controller and any diagnostics you may have know that a local disconnect is off. I think this would probably be a better rule than not having a secondary disconnect at all. Of course every plant is different. If most machines have a small footprint and operate individually then there is probably no need for secondary disconnects. If they are larger, more complex systems sections of it may be shutdown, secondary disconnects are probably a good thing.

Page 1 of 1

Community Forum Software by IP.Board Licensed to: MrPLC.com an Elston Systems, Inc. owned web property

18 of 18

8/18/2012 8:08 PM

Vous aimerez peut-être aussi