How document existing PLC system?

[[email protected]]

Suppose you took a job as a controls engineer in a
plant

And the plant automation system was NOT documented in
the least

How would you begin to document the system.... how it
works... etc?

What soft wares and tools would you use?

 

[Jörg Offner]

Suppose you took a job as a controls engineer in a
plant

And the plant automation system was NOT documented in
the least

How would you begin to document the system.... how it
works... etc?

What soft wares and tools would you use?

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

Greets Joerg

 

[SQLit]

Suppose you took a job as a controls engineer in a
plant

And the plant automation system was NOT documented in
the least

How would you begin to document the system.... how it
works... etc?

What soft wares and tools would you use?

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.

 

[John Gilmer]

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.

 

[Paul Hovnanian P.E.]

Suppose you took a job as a controls engineer in a
plant

And the plant automation system was NOT documented in
the least

How would you begin to document the system.... how it
works... etc?

What soft wares and tools would you use?

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.

 

[[email protected]]

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.

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

 

[Keen Feltcher]

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.

 

[[email protected]]

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

 

[keith]

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.

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.

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.

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

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.

^^^^^^^^^

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!

 

[Ben Miller]

Suppose you took a job as a controls engineer in a
plant

And the plant automation system was NOT documented in
the least

How would you begin to document the system.... how it
works... etc?

What soft wares and tools would you use?

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

 

[[email protected]]

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.

That's the situation we seem to be in.

John