How document existing PLC system?

snipped-for-privacy@privacy.net schrieb:

No Problem...........Take me on your payroll and I'll do.

Greets Joerg

Management must agree to what ever is done. Are the PLC's passworded? That complicates matters.

I usually print out 2 copies of the ladder and 2 copies of the program. One copy is public the other is under lock and key.

Proper "documentation" goes far beyond just "program" lists or the equivalent.

The goal of documentation is to: 1) make it easy for a "new guy" to truly understand what is going on; and 2) make it easier to detect "coding" errors whereby the system might not do what is expected. Thus, the documentation should describe the "philosophy" of the control system and offer justification of why things were done a certain way. With proper documentation, it's easier to both find errors in the existing "code" and change the "code" to meet new requirements or improve operation.

That said, the reality is that "proper documentation" just doesn't take place very often. If management will not go along with someone taking the time the truly understand things then just print out what's necessary to duplicate the system.

That depends on the particular brand of PLC. Some use proprietary tools and that will limit your options.

Some systems (not necessarily PLCs) run compiled object code. So, if the source has disappeared, you are really up the creek sans paddle.

The above is exactly what I'm needing..... not just program lists

I was wondering if a person could setup and use a wiki as a documentation and explanation tool of the system?

This system is a mess!! No idea what does what and where. The former engineer got fired. he bought and setup the PLCs and wrote the logic. But didn't document one bit of it!

hence the questions

John

Maybe u just aint up to the job my man.

I'm actually posting this question of my boss who is doing the PLC stuff

I'm just a lowly CAD tech

3) Determine what it really is that you're trying to do *before* you do it. 4) Make sure the system is recoverable in a mishap->disaster. 5) System expansion/enhancements.

Not to mention, end up with a design that actually meets the (some?) requirement.

^^^^^^^^^

Exactly! In a mess like this, I'd first make sure that there was enough documentation (source code, even) to recreate all the existing functions. Document how each function/PLC is built from scratch. Once it is shown that the system is recoverable, then go on to document how each piece works.

Good luck to the OP!

Good advice. I'd also offer that, if you are truly starting from scratch, it important to understand the process being program before you worry about what is going on within the PLC. An awful hign percentage of a PLC program is "housekeeping," mapping data so the network understands it, scaling input modules, etc. If you understand the process, you will be able to identify how the PLC performs the various functions. If you don't understand the process, the job is pretty much impossible for anything more than a tiny program.

The PLC is just a tool to get a job done. If you understand the job, it is possible to reverse-engineer the program. If you don't understand the job, forget it..........

This can be a huge job. I have done it more than once. Every case is different, but it could involve drawing complete wiring diagrams so you know where everything connects, developing a thorough knowledge of how the process operates, then reverse engineering the PLC ladder and operator interface panel programs, and finally putting all of this information into a complete document package as you would if you were designing the system initially.

This can be a big sticker shock for a company. It can cost as much as the original job. They pay for the same job twice because it wasn't done properly the first time.

Ben Miller

That's the situation we seem to be in.

John