Sign in to follow this  
Followers 0
JeffKiper

learing to program great

23 posts in this topic

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.

Share this post


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

Share this post


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

Share this post


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

Share this post


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

Share this post


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

Share this post


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

Share this post


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

Share this post


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

Share this post


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

Share this post


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

Share this post


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

Share this post


Link to post
Share on other sites
Why the consideration for HART?

Share this post


Link to post
Share on other sites
TW - excellent advice on all responses. I agree. Paul - you're officially not allowed to complain about long winded posts

Share this post


Link to post
Share on other sites
Here's my feeling on things. What I don't want to do unless speed/distance does become an issue is to buy a voltage-output 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. Edited by paulengr

Share this post


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

Share this post


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

Share this post


Link to post
Share on other sites
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.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.analogservices.com/about_part1.htm#Introduction

Share this post


Link to post
Share on other sites
Hi Ken Thanks for the links. Your second one doesn't seem to be working right now, I'll try later

Share this post


Link to post
Share on other sites
80-85.

Share this post


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

Share this post


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

Share this post


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

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
Sign in to follow this  
Followers 0