PLC Documentation Package

[minibarrow]

Afternoon All,

I am currently doing a section on my course and have been asked to produce a documentation package for a program I have developed.

Was wondering if there are any good templates out there I could use.

I have attached a snippet of what was in my notes but would like to know if there are any better versions

Thanks in advance

 

[the_msp]

I think you would get more marks by creating your own rather than using a template.

KISS.

Use word.

Embed objects (other documents, PLC program, in the .DOCX).

 

[James Mcquade]

there is truly no one size fits all template.
here are my thoughts


introduction to the machine and what it does, # of stations.
plc type and I/o


load the part.
what does the operator do?
what buttons does he push?


step 1. detail what the machine does in a step by step fashion.
clamp part and make prox switch(es) xxx,yyy,zzz
time delays? and what timers.


detail every step in the machine.
include I/o if you want.
detail timers , counters.
the more you ad here, the easier it is for maintenance to troubleshoot if necessary.


picture of the control panel.
panel layout with numbers
bill of materials.
spare parts.


how detailed do you want?
one customer required the catalog of every vendor we used. it was a 4 ft stack of books.


I included the sections of what we bought, machine prints, pneumatic prints with I/o on the print, part numbers, hydraulic prints, bom, electrical prints & bom.
I detailed everything.


the first manual or two will be time consuming, then you get used to it. I could do a complete manual in less than a week.


james

 

[minibarrow]

there is truly no one size fits all template.
here are my thoughts


introduction to the machine and what it does, # of stations.
plc type and I/o


load the part.
what does the operator do?
what buttons does he push?


step 1. detail what the machine does in a step by step fashion.
clamp part and make prox switch(es) xxx,yyy,zzz
time delays? and what timers.


detail every step in the machine.
include I/o if you want.
detail timers , counters.
the more you ad here, the easier it is for maintenance to troubleshoot if necessary.


picture of the control panel.
panel layout with numbers
bill of materials.
spare parts.


how detailed do you want?
one customer required the catalog of every vendor we used. it was a 4 ft stack of books.


I included the sections of what we bought, machine prints, pneumatic prints with I/o on the print, part numbers, hydraulic prints, bom, electrical prints & bom.
I detailed everything.


the first manual or two will be time consuming, then you get used to it. I could do a complete manual in less than a week.


james

Its just for a program I did for a section of my course.

Please see attched

 

[James Mcquade]

Great !
you have a program diagram. I'm not familiar with this method of programming. So what does it do?
you have written a plc program to do something and I am the new mechanic on the plant floor at 2 am trying to figure out why the machine will not run !!!
I have some knowledge of programming and I am looking at YOUR instructions to see what the machine does.


as I said earlier.
what is the operator supposed to do?
when he does that task, what is the next step?
step 3 is? step 4 is? step 5 is?


REMEMBER, you wrote the program and understand it. That does not mean that the next person to look at the program has a clue what is going on. It is up to you to write a manual in such a way that the mechanic at 2 am (that's me with little experience) can follow the machine operation and see that a sensor is not made / broke and fix the issue without having to call you at 2:30 am and come to the plant to fix the issue.


Not meaning to slam you in any way, but this is the cold hard facts. When writing any machine plc program / manual, document everything. write the manual so that the plant mechanic who has no idea of what the machine does can read the manual, understand it, operate the machine, and then trouble shoot the machine when it stops, and get it going.


yes, it is hard at first, but you learn what to write as you gain experience.
james

 

[Ravioli]

I do struggle through manuals that seem to be designed by the people that designed the equipment, for people that designed the equipment. I'm talking manuals from Rockwell, etc, not panel builders!


Depending on what the machine is, when preparing documentation, I like to try and condense / digest OEM manuals to include step by step walk through of basic maintenance tasks, especially if they aren't done frequently (so someone that never did it before can follow it). This is more and more important as smarter devices need more setup before they can be used compared to just setting a couple dip switches, rotary switches, or jumpers. It is also good to include, or include reference to the OEM manuals so after your introduction the troubleshooter knows where to go for more information if troubleshooting components. I've even made my own quick reference guides for VFDs including excepts of the manuals (menu map, faults, wiring guide)



I like to include tasks such as:



-Is there any way to test all devices are talking / functioning, or access diagnostics?


-If I replace a device, how do I reconfigure it (set an IP address and download configuration)? Do you have a copy of this configuration? Even if it's as a file, if there's printouts of key parameters it could be useful. Is it a temperature controller that must be programmed on the front? Include a copy of menus with all the values entered.



-Is there any quirky problems you ran into during commissioning? Something that may show up again if the machine runs out of spec?

 

[AustralIan]

Haikus seem popular.

List what inputs do
List Outputs and what they do.
State or time di'gram.

 

[James Mcquade]

Follow up.


I worked for OEM's for almost 20 years. the first manual I wrote had to be re written because it could not be followed by the maintenance technicians. So I rewrote it. it was better and had to rewrite it again. this time, I explained it in detail as to what the machine operation was, timers used, sensors that were to be made, and outputs to turn on/off. the customer loved it, no more 2 am phone calls and getting yelled at by the boss.


I have used that method for the last 15 years, and don't get phone calls at 2 am for trivial things. when maintenance calls, they really have a problem and I am happy to help.
james