Sign in to follow this  
Followers 0
edpuente

Best Practice PLC Programming

13 posts in this topic

I am trying to put together a methodology to develp the PLCs applications we write. I was wondering If there is one already that you can recommend me to look at as a reference? Thanks in advance for your inputs... Edgar

Share this post


Link to post
Share on other sites
Upload how you would approach it at the moment and i will gladly comment on what you have included based on the amount of info that you provide.

Share this post


Link to post
Share on other sites
OK . I will assume for this discussion that a PLC will manage devices, such as a machine or machines, and these machines lets call it system.... Any PLC program should have the following areas: Operation: What and How the system will do Alarms & Warnings (A&W): What should stop the system, or warn the user. Bitacora (Register of events): Alarms, Warnings, a Change of State (Such as a change of Set Points, or On/Off ) HMI: Managing the data to be display and display the data in a HMI. I/O management: Such as Digital inputs & outputs, Analog I/Os, Communications, Fast counters. Note: I suggest that the security should recide the A&W Area. Operation, Basics.- Any device should have the following, a flag to turn it On/Off (make it ready), A flag or value to make it move, such as a speed, or just a flag to make it move or act. The device will be stop by either an alarm or a change of state. I will be adding more ideas later .. I have to attend some issuess, but I value your comments, on these ideas so far.

Share this post


Link to post
Share on other sites
The company I worked for 20 years ago using Omron and Toshiba PLC's had something called SOCBL. Which stood for Standard Operational Controller Basic Layout. As I can recall it had the following pieces. A Boolean File was specified for all Machine Stopping Device Alarms. A Boolean File was specified for all Machine Warning Device Alarms. A Boolean File was specified for all Auto Mode Flags. A Boolean File was specified for all Manual Mode Flags. A Boolean File was specified for all Device Start Request Flags. A Boolean File was specified for all Device Stop Stop Flags. A Boolean File was specified for all Device Starting Flags. A Boolean File was specified for all Device Stopping Flags. A Boolean File was specified for all Device Running Flags. A group of ladder files was specified as containing the control code for one device per ladder file. A Specific ladder file was reserved for processing all HMI Input and Output. A Specific ladder file was reserved for all device ladder file calls to reside in. A Specific ladder file was reserved for machine / system auto - manual - run -stop logic. A Specific group of ladder files was reserved for SCADA Interface. A Specific group of ladder files was reserved for ControlNet and Devicenet configuration and interface. The company I now work for has what is called a CIS Standard for Wonderware and another for Logix Controllers. It is a lot like the old SOCBL unfortunately that I am all at liberty to elaborate on.
1 person likes this

Share this post


Link to post
Share on other sites
I have to be a bit flexible because i am a systems integrator... But saying that there is always an underlying structure... I would generally have the following sections.. System Initialiastion (IE special cards setup config paramters) Clock Data (have added this lately just dupilcate the code every time to extract all relevant time info how i want it for compares later on in the program. Input Mapping Analogue Scaling Section Shutdown Alarms Warning Alarms HMI / SCADA Control System Operation - Broken into many other sub categorys Valve controls - a function block calls for all valves Pumps controls - function block calls for all pumps Other Type Controls - function block calls for all other controls Output Mapping Test I have attached a sample of the section layouts for a number of different clients... Some times the code was ordered to suit a flow diagram, other times you can see it was structutred around functionality of the system...

Share this post


Link to post
Share on other sites
It seems that Bob´s approach handles most of what is needed to be programmed, including what you have shared with us. I will write it in a word document, so we can keep on discusing it. Now we should be discussing how should we do the programming. For example, how to handle alarms, in order to know which alarm is active and also have the historic secuences of alarms? Using the alarms handling of the NS Screen? Just bits. And much more. As I said. I will write a document so we can discuss it. Best regards and than you for your inputs...

Share this post


Link to post
Share on other sites
In an Omron NS screen the alarms as I recall can automaticall be disiplayed as current with date time stamp, history, and frequency... (No further PLC programming required.. just select what type of alarm oage to display.) As to regards for the current ALARMS you have two choices... 1. Automatically switch to the ALARM page upon an error (this does require writing to the control word allocated in the PLC for the screen 2. Flash an indicator on the screen....

Share this post


Link to post
Share on other sites
Thank you for your input...

Share this post


Link to post
Share on other sites
Going on step deeper than program-layout, how do you arrange your memory allocations? Symbols sure is a fine thing, but as a pedant I also prefer the memory adresses to make some sense. Like CIO 0-100 for digital I/O, CIO 500-999 for HMI(and similiar in D-memory for non-bits) and if it's a step-oriented program, CIO 1000.00 for step 1, CIO 1000.01 for step 2, etc. Keeps it easy to sneak in steps between later on without getting an too unlogical structure adress-wise.

Share this post


Link to post
Share on other sites
I think, following your idea, to divide them by themes. For example, alarms or warning bits in a HR area, operation bits in the IO area and there , group the bits by process rather than steps. All bits regarding lets say, opening a valve, should be in area 150.00 to 150.15, and so forth , so that when your are trying to takle down a failure, you can see the whole valve opening process by looking those bits. By the way, what do you think, make the program by steps, or by processes?

Share this post


Link to post
Share on other sites
There are many ways to handle alarm events especially in the NS screens. The older screens (NT) were not so functional. They do have alarm history records but that doesn't help much for active alarms. In our field it is important that an alarm is not missed by the operator. For example, if multiple alarms are present but you are only able to display one alarm at a time, the hidden alarm may be reset without being seen. The attached code shows how we handle this situation. When the alarm happens, the screen is displayed and latched in the PLC. If a second alarm happens, the new alarm will overwrite the old one on the screen. When the reset button is pressed, only the alarm that is currrently being displayed will be reset. Therefore, the priority of the alarms are 'last in, first to be reset'. This is only one example of the many situations that you ask. Depending on how detailed you wish to get, it could be one large document. Good luck. Edited by IO_Rack

Share this post


Link to post
Share on other sites
Everyone insists on all these 'broken up' bits of program these days. I have always used the 'broken up' method even back to the C200H and Syswin days but all in one section. The annoying part of all these sections is that you are forever switching sections when commissioning. It was good when the sections were not available quite frankly as I always found it quicker and easier to run up and down the ladder to numbered rungs which are the start and end of the sections but I had to conform eventually. Planning is done from day one to allocate memory areas for alarms, shutdown, acknowledge channels etc. I normally use the BCNT instruction to count up alarms on, alarms acknowledged and then compare the 2 results to turn on thae alarm siren etc. Works really well. I also program by number and not symbol quite frankly. Goes back to the days when symbol slsection programming was not available.

Share this post


Link to post
Share on other sites
I agree with you Bob. Some of the guys here at our plant have taken advantage of the 'sections' function of the newer software to segregate the machine controls or stations. (As Sleepy has outlined). I began using it when we started using HMI's. I seperated the machine's control from the HMI because we felt the machines control is most important and should not be dependant on the HMI or associated PLC programming for the HMI. The days of this non dependancy of the HMI have long passed but I still like the 'Top -Down' style of programming. It just works better in my brain. I know from your previous posts (Bob), that you didn't like LSS very much but, when dealing with a large 'top - down' program, the LSS print outs were the best IMO. The cross references were very concise and and made it very easy to hash out those large programs. Edited by IO_Rack

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