Documentation

sebastien

Guest
S
I need to propose a way to properly document our PLC ladder logic and HMI screens. We usually use GE Fanuc and WonderWare. Sometimes SLC500 and PLC5. Is there a 'method'?
We have a documentation department that saves the HMI screens and adds comments like "Press this button to start the pump". We would like something more advance that would combine the screens, the scripts and the ladder logic. The big question is how detailed do we need to be and how much time do we want to spend on this.

Thanks for any suggestions.
 
It all depends on the End-users. Will they be Operators.... (for the HMI) or will they be tecnicians (for the ladder part).

The more you add to these files, like comments... the better they become. It all boils down the the level of pain you can witstand...

How painfull it is to get those guys at speed when they use this stuff, compare to the pain of doing all the commenting and formating of there applications.

At the end its a bisinees decision. Are you the one to take this decision?

We use Photoshop (printscreen and paste) and pdf-writer.
 
I have to agree with Pierre. From a technicians point of view then the more annotaion the better, but operators will only need, maybe, the HMI screens with the instructions, like 'push here to start machine'. Personally, I have no set procedures for this (neither has my company), but I will give as much informations as is needed, dependant on the end user.
 
At the last place I worked (a company I felt tried pretty hard to make employee training and involvement a priority), they formed short-term teams to create work instructions and troubleshooting guides.

What they favored was starting by having a small group of experienced operators write the operating instructions themselves and then another group edit them.

Similarly, they had groups of tech's do the troubleshooting guide.

There was a guy whose primary job was training and he did a lot of graphics and was directed by these groups in what graphics to make and what should be listed.

This technique seemed to work quite well.

As others have said, the more heavily documented the PLC code, the better for everyone. :cool:
 
But

What if you are trying to show your client how his system will operate. For critical systems some clients want to know exactly what we are doing behind the HMI. We sometimes create flowcharts but they are time consuming so we don't put everything in them and then we get complaints that our documentation is complete.
 
No matter what you do or how you do it, someone will *****. Since you can't please everyone, you have to please yourself (with due credit to Ricky Nelson).

I don't think it is a good idea to put ladder logic on the same page as Operator Interface screen shots. The screen shots are for the operators - they need to know what is there, and what each adjustment does. Most of them cannot use the ladder logic, nor do they want it.

Keep the ladder logic printout separate for the technicians or engineers only. Make it scrupulously commented. Include a printout of the operator interface configuration and registers. Include a cross reference list, and in your nicknames or other documentation identify setpoints and items adjustable by the operators. Keep adjustments grouped in a block, and keep time delays grouped within the groups, alarm trip points grouped within the group, etc. The technicians will have an easy time of troubleshooting, and they will have access to your screen shots and the O/I references.

If you try to put too much on one page, you end up confusing more than you clarify. Separate documentation with increasing levels of detail for those with a need to know is, I think, the best bet in the long run.
 
I try to address both the OPS guy and the Maintenance guy with a HMI Screen Diagram, coupled with a database. Like Pierre, I dump my screens to Paint, and import that into a pdf on the top half of the page. In Excel, I build a database for each active element on the screen, and then import that onto the bottom half of the pdf. Frequently it bleeds over onto subsequent pages. Then I go back onto the graphics part of the pdf and bubble off the items that appear in the database.

The Excel sheet for each screen has info like Item#, Description, Action Tagname, Animation Tagname, etc. If the HMI tag is linked to the PLC, I try to build my PLC address and node into the HMI tagname. So if you have that, you have the PLC link. An item might have tagnames listed in both the ACTION and ANIMATION fields if, say, it is a pushbutton that lights up. Otherwise, I put "NA" in the ACTION field if it's just an indicator... and so on.

Doing this is really good for the techy since he can quickly find the link into the PLC. The operator say's "it does this when I do that". The techy then can go look at the Screen Diagram, and go straight to the spot in the PLC logic. It's also good for the operator since he can look at the description, which can tell him quite a bit. Both groups like this since it looks just like what they're looking at.

When all that is done, I dump all my Excel files into Access as tables. Then I dump my PLC database into Access, also as a table. Then I build queries to fetch stuff as I need it, and build reports. It also lets the techy do keyword searches, and I can put in any associated wiring diagrams. Then I write the O&M manual and imbed this stuff in it, along with any logic diagrams or narratives that might be helpful.

Good luck!
 
Naughty, naughty dog

🤷 <<I'm new to this, so bear with me.. >>-maddog

:cool: Is it my reading or are you not a pro to this stuff???:eek:
 

Similar Topics

Does anyone have information or documentation regarding the protocol used in Rockwell's Remote IO, and how the physical layer of the network...
Replies
5
Views
877
Hi all, I was wondering if anyone had any good methods for developing functional spec / test sheets for equipment interlocks. I find the best...
Replies
3
Views
1,279
Hello all, I recently got a new job working as a controls technician. I have been doing it for 3 months, coming up on 4 now, and the company was...
Replies
2
Views
1,194
Hello All, This is not a PLC question per-say, but I'm looking to see what you've found to effectively document a design system that is to be...
Replies
1
Views
1,276
Hi Guys, a few years ago I started to write a little test program for PC to communicate with OMRON PLCs by FINS commands. Well, I would swear...
Replies
2
Views
2,751
Back
Top Bottom