PLC Training Org.

PLC Programming Training : PLC Training Best Practices

plc programming  

This is section 6 PLC Programming Training of the PLC Training Best practices. Remember Industry standards are your starting point to developing best practices. Industry standards like

NFPA 79 2015; IEC 60204-1; IEC 61131-3:2013; ICS 21.020: 29 CFR 1910.212.

When you are ready to move on above and beyond Industry standards as a constant improvement program,  learn and implement industry PLC programming conventions and industry naming conventions so your PLC programs are more familiar and understood by your customer. That is what the PLC training tip and best practices contained in these 10 sections address. This page is for Section 6 of these 10

PLC Training Tips:

Section 6: PLC Programming Training:

The tips and best practices on this page will be helpful for ...

The maintenance manager, commercial electrician, industrial electrician, instrumentation tech, mechatronics tech, industrial engineer, industrial IT person industrial software programmer and others.

Bookmark this page or site; as new best ways for PLC technician, industrial electrician, instrumentation technician and others to perform basics task are verified, they will be added here.

PLC Training Best Practices:

6.1 PLC Programming Training Process:

The PLC programming training follows the best practice PLC programming process. IE: PLC program design, writing, testing/debug and final documentation.

6.1.1 PLC Program Design

The PLC programming design phase will adhere to Module, Mode, Tasks, Steps.
Each module will be in its own subroutine jump to by main subroutine.
Section off each module/subroutine by relevant mode when possible.
All PLC programs, regardless of size should have an XREF and Start-up subroutine.
Typical modes might be start-up*, normal*, auto, manual, shut-down, set-up, diagnostics, etc.
Each task will be broken down into sequential steps, often conditional. A task may conditional and be a one off, or a continuous loop.
Use a flow chart and use a timing diagram if task are time dependant.
Write detailed word description of sequence of events in order they should occur for specific subroutine they are being wrote for, using Boolean logic.
As you are writing Boolean word descriptions, make note on sidebar of any real world I/O needed. Estimate 20% extra I/O than what was indentified during PLC program writing.
Do not design with input card in slot 1. More of an automation control design consideration, but with a training and downtime reduction reason for doing so. In training design, always best practice to avoid the letter I next to the number 1, likewise the letter O next to the number zero. (IE: I1.0 can lead to downtime via mistakes and typos.)

6.1.2 PLC Programming Core

PLC programming training should start with core principles and best practices.
When teaching beginning PLC programming, do not assume student is electronic engineer and understands Boolean logic circuits, or assume they are computer programmers and understand structured text/Pascal. If they are either, they will quickly pick up on electrical schematic, so electrical schematics is the best comparison to be making.
Increasing PLC programming knowledge and skill can be accomplished one of two way, by doing or by studying existing commissioned PLC programs.
Studying existing programs already out of the start-up phase is a quicker to learn PLC programming than writing as many programs yourself.
#2 rule while writing PLC program .."Make it as easy for the layperson to understand."
Every rung should have a detailed rung description.
At minimum, memory areas relevant to I/O XREF, faults, troubleshooting or used frequently in PLC program, shall have associated symbol/tag.

6.1.3 PLC Communication Protocols

Familiarize one self with these common PLC communication protocols: Ethernet, Modubus, DeviceNet, Profibus, Fieldbus
Learn at least one PLC vendor specific protocol, preferably relevant to the current industry you are in.

6.1.4 PLC Programming Languages

Although PLC Ladder Logic should be first and primary language to make machine more user friendly to end-user, the other 4 IEC 61131-3 Programming Languages should be studied too. (Structured text, function blocks, sequential function charts and instruction list, in order of priority after ladder logic.)
You can acquire safety and reliability with any of the languages, so the next priority should be making it End User friendly. Followed by making it programmer friendly and other considerations.
Advanced programming language recommended to be learned is Python as it is commonly used with HMI.
More coming soon ...


6.2 Writing PLC Programs

Using your flow chart and/or timing diagrams and estimated, detailed Boolean descriptions of each task and estimated I/O, chose an arbitrary hardware configuration to start writing PLC program with.

PLC programming objectives in order of priority; perform expected functions safely and reliability, make it user friendly and organized for the layperson to understand, make it easily expandable and portable (re-usable) to future projects.

Create main, start-up and XREF subroutines. (Include 20% extra in XREF subroutine.)

Using flow chart and/or timing diagram, and detailed word description of sequence of events, convert Boolean description into ladder logic. Start with first subroutine in your flow chart, or manual mode related rungs for pre-testing of basic functions.

Each detailed word description is also the related rung's starting description.

Use industry naming conventions, and group your memory locations/names by related subroutine and/or other logical naming conventions.

6.2.1 PLC Programming Rules

There are exceptions to every rule, below are instructions as a general rule.
Always use a mouse, not the touch pad when PLC programming.
The main subroutine/module is for program control only (like JSRs) and critical safety, do not place other logic in that subroutine.
Never duplicate outputs.
Place all real world I/O in it's own subroutine (XREF)
Symbols/Tags should be meaningful and short as possible, descriptions should be as detailed as possible.
Do not use acronyms in descriptions.
Do not use the word "not" in descriptions.
Every latching (L) bit shall have an unlatch (U). (and every Set should have Reset) Only use latching bits where necessary, otherwise use seal in circuit.
Every counter shall has a counter reset (RES)
Every timer should have a time base of less than 1 second.
Never use 2 or more output coils in series, even if the PLC programming software allows it.
Do not use constants, use variables.(Example: instead of ADD instruction with offset of 5, use N7:3 or tag like DwnPosOffsett to store offset of 5 in.
Most math and move instructions require a one shot in series with the rung output. (One-shot example: [ONS],-|P|-,-(P)-,-(↑)-. )
Processor status bits such as faults, time base, EEPROM/Flash, Real date/time and other commonly used status memory should be made easily accessible in it's own subroutine if PLC software does not have easy access (list) processor status data files.
Never use a memory location as condition to jump to a subroutine, that is also being used in the same subroutine being jumped to.
Test each subroutine before moving on to the next. (PLC simulator/emulator can be used to test, actual PLC is best.)
With structured text programming, use all caps for instructions and commands. ("IF LimitSwitch1 THEN"...)
With structured text programming break tag names up with first letter of each word capitalized. ("ScadaAlarm7")
With structured text programming break large numbers up underscore "_". ("AllBitsOn := 32_767")
With structured text programming don't forget to escape the backslash when you store a namespace name in a string and fully qualify a namespace "\Line7\Line7Array\Input();"

6.2.2 PLC Programming Tips

Tap into processor status time base bits to make warnings pulse, instead of using timers.
Always verify each rung as written, avoid using 'verify file' or 'verify project'
If an AFI function is not available, create a user defined function for AFI.
Use plugging timers with forward/reversing motor controls.
Use processor first scan bit to jump to start-up subroutine.
Try to keep the latch/set and unlatch/unset rungs next to each other (more user friendly)
Place all your alarm data in one data file. Use dummy output rungs to display all alarms in a single rung for ease of troubleshooting by end user.
In writing large programs, entering output instruction first on rung via hot key and then dragging & dropping rung input conditions to left of output instruction can be quicker.
For increased programming reliability, use "=" only if exact number needed, by default always use ">=" or just ">" (greater than) Especially if comparing a real number (floating point like 32.657 Deg).
Consider reliability and predictive maintenance (PdM) when PLC programming. (Example: Use validation timers on photo eyes to distinguish between actual product being detected, or false bug flying by signal or lose wire. For PdM use false signal counters.)
Use an Add On Instruction instead of Indirect addressing so each instance can quickly be selected for viewing there by making troubleshooting easier. 
More coming soon ...

6.3 PLC commissioning best practices

Never use default node and IP address

Never leave a PLC force in place longer than 24 hours, follow safety protocol.

Once in start up phase, revision note shall be entered for every revision.

Do not assume wiring is correct when logic does not work as expected, verify correct wiring to schematic first.

More coming soon ...

Note: Click "Learn PLC Programming" to learn PLC programming using the above best practices.

 Next ...  Section 7: PLC Communications Training Best Practices.

 Have a constructive comment, want to discuss this page? See PLC Training Forum programming