Sign in to follow this  
Followers 0
dcalderonv

PLC Programming standard

10 posts in this topic

Hi, I've been programming PLCs for a while many types of Machines and processes and I've dealed with a lot of different types of field devices (e.g. Motors, Valves, Drives, PIDs..) as well. Now, I'd like to start developing some kind of programming standard in order to be more efficient and program faster the PLCs. What I mean is to attain some level of standarization that describes how to name Routines, Devices, Programs (nomenclature).. and code segments for each device type I have, so I could simply copy, paste, replace, tag-based names. As I've worked with a lot of companies I know there are a lot of corporate standards out there. But I want to develop something generic so it can be customized according with the project I have. Since here we have a lot of PLC-Monsters, it would be great if you helped me with suggestions, docs or examples you simply have got around your career as PLC Programmers. Well thanks in advance and I' looking forward to hear from you. Daniel.

Share this post


Link to post
Share on other sites
Can't go into a lot of detail as most programming standards I've dealt with were considered corporate property for the companies I was working for, but I'll talk generalities in a few areas. 1. If using Ladder Logic structure your rungs with contact instructions {XIC, XIO, ETC} on the left most portion of the rung, then your word level instructions {EQU, NEQ, GRT, ETC} this makes a faster scanning program. 2. If using Ladder Logic structure your rungs with higher priority contacts leftmost. The sooner the PLC can encounter a false piece of logic and move to the nect rung the faster it will scan. Placing flags like AUTOMODE or ESTOPOK in a leftmost position may look nice and structured, but scans slower then having them later in the rung. 3. You mention copy and replace, have you considered using Excel or VB to generate code, The SLC, PLC5 and CLGX families all support this functionality. I actually wrote 66% of a warehouse control program using an excel macro. Excel churned out the Motor Control, Flow Control and Flow Merge sections in 2 days, versus 2 weeks to craft them longhand.

Share this post


Link to post
Share on other sites
Thanks Bob, I understand the confidential stuff and that's what I meant when I wrote about "generic standard". Thanks for the scan-time related tips. There's some topic I would like to know your opinion about: What do you think about the use of Permissives and Interlocks? I've seen that some companies use Permissives as conditions to start some device, and interlocks as required conditions for the device to be ON state. Do you think the use of both type of condition is always necessary? Regarding the devices/PIDs operating modes. Generally there are Operator and Program mode, but then you have Auto, Manual and Cascade. What do you think is the optimal use for those combinations? thanks again for you opinion and suggestions.

Share this post


Link to post
Share on other sites
Cascaded control is specifically for when you run PID loops in series (output of one feeds the setpoint input of another). If you look at the flow sheets most drives, they often have cascades of 3 or sometimes more control loops. There is no "program mode" at the PID level. This is a programmer decision. I don't usually add this extra mode, except that some screens are made inaccessible during normal operation. There are actually 3 different "operating modes" in terms of auto/manual in an AB PID instruction, and something like a half dozen or more in a PIDE instruction (available in FB only on CLX processors). Generally these are for "normal" (auto control to a set point), and "software manual" (setting the output via PLC control), and "hardware manual" which is where you have an external controller running the loop and the PLC is merely following it to achieve bumpless transfer of control. A fourth "mode" is the local vs. remote set point decision which is very common in chemical plants. Conceptually, a "local" set point means that you manually key in a set point value to a PID loop. A "remote" one means that it is fed from some place else. This is common for instance with ratio controllers for chemical metering. Suppose that you have a PID loop metering in a chemical into a stream. A "local" set point would be for instance "1 gram per minute"...no matter what the product stream flow rate is, you get one gram per hour. A "remote" set point would be "1 gram per liter". So the set point becomes the flow rate of the product stream multiplied by 1 gram for a set point. Normally, the "remote" setting is used. But if for some reason the flow meter breaks, then operators may still be able to manually control the system at least for a period of time by ignoring the "remote" control and locally setting the metering rate. None of this is directly supported in the PID loop instruction itself. You have external code to implement this function. Generally I implement things like this (for a process or batch plant...discrete is different): The overall system (plant) has a "start/stop" button. Normally this is all the operators use. Every "device" has a separate auto/manual button to allow for local control/troubleshooting as needed. It is NOT interlocked to the master start/stop sequence BUT there may be other interlocks. For instance, interlocking a pump to not run if the tank is empty (auto only...under manual control, the operator takes responsibility for destroying the pump. Every PID loop also has remote/local set point control (if appropriate), making 3 modes (manual, auto/local, and auto/remote). Under manual control, the only interlocks are generally those which are needed as a bare minimum for safety reasons. Under auto, interlock the world. Generally I have each device locally have a "ready" permissive/interlock which feeds back to the master start/stop cycle. So you can run everything with some functions in manual which will bypass certain interlocks that would normally shut the system down if running in full auto. Finally, all these things should be generating "events" (alarms) for sequence-of-events type troubleshooting in the event that something does go wrong.

Share this post


Link to post
Share on other sites
Paul, very useful your opinion about the operating modes. I have always wondered about the use of separated intks and prmsvs for either auto/manual modes. Now I have a better idea about their use. Regarding the code generators, absolutely that's one of my targets in this campaign, but I think if any of you could send some kind of template or a simple piece of code (i.e. excel file with an example) that simply I could read and understand so I don't have to start from scratch I would be great. Thanks again for your time.

Share this post


Link to post
Share on other sites
Check the Ab downloads section of this website. There is a sample motor control code genertor spreadsheet. There are a few posts about it. It should get you jump started into the world of code generation by macro.

Share this post


Link to post
Share on other sites
Greetings Daniel, New member here and was reading some posts and this one caught my eye. Just wanted to throw a few suggestions at you. Not sure how relevant they are to your field but here ya go. I like to have one routine specifically for on and off delay of photoeyes turning one single bit on. I usually start with say PE100 as my photoeye tag/alias and name my timers (TON) T100A and T100B. Why over complicate things with long tags. Then all that is needed for each program is to change your TAG aliases and uplaod. Same goes for VFD/motor control. Keep it all in one routine with only the necessary things in there, start, stop, speed changes, etc. Plus for later debug when a motor isn't going when it should be, it's an easy place to start from. Do all of the detailed control somewhere else that leads back to this routine. A lot of what I do is based on my experience figuring out other peoples logic, I try to make it as uncomplicated as possible without compromising, as Bob correctly stated, scan times. Perfect example is when I am looking at a program that has a rung like: XIC XIO XIC XIO TON XIC XIC OTL OTL OTU all on the same line, that is not logical to me. Yes it works but it visually looks cluttered. TON's and their done bits on the same line seems sloppy to me. Writing ladder logic to look similar to what electrical schematics look like has always made sense to me, besides, it will make sense for that 3rd shift maintenance guy with just enough PLC knowledge to be dangerous but understands electrical controls very well. I hate 2am phone calls that end in him cleaning off a reflector. As far as using Excel, read up on the Concatenate feature. Can't indulge any further but if you figure it our you will love it. Cheers!!

Share this post


Link to post
Share on other sites
Hi Daniel: There's another reason to have a programming standard in writing. It seems the latest fad among the MBA's is to require that equipment be purchased with the PLC program supplied by the equipment vendor as part of a lump sum price. I've seen customers of mine who have received PLC programs (not from me) that were totally unmaintainable, very poorly documented, and often not even safe! The problem is that if they try to require the vendor to clean it up, his reply is "That's what our price included. If you want any more, it's going to cost extra". Of course, the MBA's didn't allow any money in the budget to cover program cleanup. If there was a written program standard which could be included in the purchase documents, the owner's people would have some way to enforce at least minimum programming and documentation requirements. A forum like this would be a great vehicle to produce a document that people writing the programs could agree to, and wouldn't be hesitant to agree to adhere to.

Share this post


Link to post
Share on other sites
My favorite was one I saw when working as a System Integrator. I'll paraphrase the gist. "The requirements set forth herein by the purchaser do not relieve the supplier in any way from providing a system which meets all current relevant legal requirements and the agreed to production rate for the end product."

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