Before you Start

I am interested in developing a "list" for Process and Mechanical Engineers to complete and provide to the PLC programmers on the project that gives them the information they need. I am also looking for a "task list" that identifies the PLC programming "process". As an owner and manager of a company that provides mechanical and electrical control systems, I am trying to bridge the gap between PLC programmers and the mechanical engineers and other lay people they need to interface with. I will develop the list from the responses. Even list of "things you hate" will be usefull.

I hate lists!!!!!

I'm just being funny, I do have some ideas that I will post here in a little while...got to finish some wiring first.

David

Sounds like a good idea...BUT

Some details were left out, who will be doing the electrical design? Is your system like an assembly line where a different person does a different part of the machine or system?

Lets assume that the PLC programmer does not do anything but program, in that case he would need to know specifics. Definitely a print, P&ID, and a written description of the function of the machine, even better if he could see the machine as its built to understand the functions.

I have no idea how I would describe the job I have now. I am building panels, setup drives and plc's. It has been strange but now I have gotten prints, a basic layout, but no written description telling what either of the machines do. I find myself in a most awkward position BUT I have lots of time so it will probably work out.

In the position I have now I am semi-isolated from everyone and I think its a bad route to take, anyone participating in a project should be as involved as they can from the beginning. I think my signature says it best.

If/when you develop the list I would appreciate a copy of it.

Prosolid asks a good question. I believe this is a problem we all face each time we start a new project as a member of a team where other designers and we are not the “lead”. Heck, even then we face that problem.

Anyway, lets start with some assumptions. First, lets assume that your PLC programmer is locked away in a little room somewhere and you are going to slide some written directions to him under the door and then expect a working PLC program to be slid back out the same way. Second, lets assume that his programming skills are so advanced that there will be no errors and, thus, he should never be involved again.

Now obviously this is way stringent. And obviously we all know that the more involved each individual is in a project, the better his or her performance will be. But I am trying for worst-case here.

1. All PLC technical information
2. All I/O information – Wiring, type, terminations, etc.
3. Power Up Conditions – What should (and must not) happen when power is applied.
4. Power Down Conditions – What should (and must not) happen when power is lost.
5. E-stop Conditions – What must (and must not) happen when an Emergency Stop is initiated.
6. Movement Limitations – Soft and Hard limits
7. Automatic Cycle (assuming one or more exists):
_ a. Required Starting Conditions
_ b. How “Auto Start” is initiated
_ c. Actions required in a Step-by-step fashion
_ d. Actions required when an Interrupt condition exists (if any)
_ e. Actions required to continue after an Interrupt (if any)
_ f. Definition of Cycle Complete Conditions
_ g. Actions required to Cycle is Done
8. Manual Mode
_ a. Definition of what “Manual” mode means (is each machine movement “jog” only or something else?)
_ b. How a “Manual” Command is issued and actions required
_ c. Actions required when an Interrupt condition exists (if any)
_ d. Actions required to continue after an Interrupt (if any)
9. Recipes (if any):
_ a. List of all recipe information
_ b. Description of how it is to be accessed
_ c. Detail of who can (or cannot) accesses it
_ d. State if it to be stored or not
_ e. Description of where each field of recipe information is to be used

I know I left out a lot of things but I think this is a good start.

In the end, I think it comes down to this: The programmer has to know the expectations of the machine. The more he knows about it the better. If he is not going to be involved in the machine’s mechanical design from the ground-up and have a hand in the decision making process (mechanical guys really have problems with this), you will have to go into great detail when describing your expectations of his program. You need to describe the program, step-by-step, before you ask him to write it.

Steve

Steve's list is pretty complete. I think the I/O list (I call it a Point List) he refers to is the most important single item. If you have that right, it naturally leads to consideration of a lot of functions that might be included. If you don't have the Point List right, nothing else can be.

Three additional items I include in my documentation:

1) A list of all alarms, and what action will be taken when they occur. For example, will the alarm be displayed, logged, will the horn sound, will a specific machine stop, will the whole process stop?

2) A list of all operator accessible adjustments and tuning parameters. This is not only usefull, but will also direct the programmer into some of the control logic.

3) A brief description of each operator interface screen, including tuning parameters, any trends, and the data to be displayed.

RSDoran, It is exactly your lament that I wish to avoid. The types of systems we handle has all types of machinery and equipment and is located from one end of the plant to the other. Automated Ingredient and Bulk Material Handling. Most times the PLC Coder becomes the defacto Process Engineering by default. Now if he\she has the necessary skills and experience that's great, but sometimes it is asking too much. What I will eventually complete is a standard way to describe and deliniate system functionality that has to be completed before the coding begins. I guess this is sometimes referred to as the Systems Design Functionality. Please someone correct me if I am wrong. Also as we are now a small company I will be outsourcing the PLC Coding and I want to be able to present a complete package which will give us better cost control and allow the project to stay on schedule. The PLC Coder is typically the last guy in line and of course gets a lot of pressure to complete.

Steve & Tom, Thanks for your contribution.