How We Write Programs
Structured for the facility. Consistent for the operator. Serviceable for the next technician.
Most automation providers describe their programming approach. Below is a short excerpt of real ControlLogix work, along with what we are actually trying to accomplish when we structure a program.
Look at the Work, Not the Claim
A short excerpt from a live ControlLogix project — the controller organizer, device fault handling on a bulk separator, the PIDE level control behind it, and the routine that maps values out to SCADA. This is one corner of one program, not a tour of the whole thing. It is enough to see how the work is put together.
We Do Not Impose a House Standard
Most of our work happens inside control systems that already exist. The facility has conventions, the operator has a way of running it, and your team has expectations about what a program should look like. Arriving with a rigid standard and applying it over the top of all that produces a program that is clean by our measure and foreign by yours.
So we work to the facility's standards where they exist, and bring our own where they do not. What stays constant is the intent: the structure should reflect how the plant is actually laid out, the operator should be able to understand what the control system is doing, and the next technician to open the program — whether that is one of us or one of yours — should not need a translator.
The sections below describe what that looks like in practice.
Six Things We Pay Attention To
Program Organization
Routines follow the equipment, not the I/O card. Each vessel, meter, and control valve owns its own routine, so when an operator reports a problem on the bulk separator you open the bulk separator routine — not a general input-mapping rung buried three programs away. It also means equipment can be added or taken out without unpicking shared logic.
Treater_Separator_Lease01
Bulk_Separator01_Devices
Bulk_Separator01_PIDE_CVs
Bulk_Treater01_Devices
FreeWaterKO01_Devices
FreeWaterKO02_Devices
Naming
Tags carry the instrument number from the drawing rather than an internal abbreviation. Someone holding the P&ID can find the logic, and someone reading the logic can find the instrument in the field. Where a facility already has a naming convention, we use theirs — consistency with the rest of your site is worth more than consistency with our other projects.
LCV_2160_PIDE
level control valve, loop 2160
PDT_2160_PV
differential pressure, loop 2160
FT_7311_Totals
flow transmitter totals, loop 7311
XA_2210
comms alarm, RIO-2210
Alarm and Shutdown Philosophy
Device faults are handled at the instrument and degrade only what depends on them. Device and communications faults are handled according to what depends on them. A remote I/O failure clearly identifies the affected equipment and drives the appropriate response without unnecessarily taking unrelated equipment out of service.. Fault handling sits in an add-on instruction so every device behaves the same way, and alarm and shutdown logic is grouped rather than scattered through equipment rungs, so the full philosophy for a site can be reviewed in one place.
Control Strategies
Level and pressure loops run on PIDE with the tuning constants, override values, and manual request logic surfaced to the operator interface. Whoever has to retune a loop at 2 a.m. can see what it is doing and why, without going online with the controller. Where a simpler strategy will hold the process, we use the simpler strategy.
SCADA Integration
Every value going to the host is assigned in one place, in order, in a single routine. Nothing is scraped from scattered controller tags and nothing is implicit. When a number on the SCADA screen is wrong, there is exactly one file to open to find out why — and the register map you get at turnover matches what is actually in the controller.
SCADA_Value[163]
:= FT_7320_Totals.VOLUME_IN;
SCADA_Value[164]
:= FT_7320_Totals.TTL_CD;
SCADA_Value[172]
:= Lact_1_Call_Tank_LVL;
Documentation
Rung comments explain intent, not syntax. A comment that says what the rung is protecting against is worth more than one restating the instruction. Revisions are noted, programs are archived before and after changes, and what we hand back is enough for someone else to pick the system up.
Structure Is a Maintenance Decision
Thinking about organization up front costs a little more time during development. It pays back every time somebody has to open the program again.
Your Team Can Work On It
A program organized around the plant and named off the drawings can be picked up by your own technicians. You are not locked into calling us because we are the only ones who can read it.
Troubleshooting Gets Shorter
Most call-out time goes to finding the relevant logic, not fixing it. Predictable structure turns that search into a lookup.
Changes Stay Contained
Adding a vessel or swapping an instrument touches one routine. Shared logic does not get modified for a single piece of equipment, so nothing unrelated breaks.
Management of Change Has Something to Work With
Grouped alarm and shutdown logic, explicit SCADA mapping, and written revision notes give your MOC process something concrete to verify — rather than a signature on a change nobody can actually inspect.
What You Get at Closeout
Documentation is part of the work rather than an add-on. This is turned over whether or not we are the ones supporting the system afterward.
- Commented program archive (ACD and L5X)
- Revision notes describing what changed and why
- Tag list with descriptions
- Add-on instruction documentation
- Documented Instrumentation configurations
- SCADA tag list in the host's format
- Network addressing and device list
- Gateway and flow computer configurations
- I/O checkout and loop verification records
- Functional test results against the narrative
- Punch list and closeout status
- As-built markups of what was found in the field
Want us to look at your program?
Send us an export of what you are running now. We will tell you what we see — structure, fault handling, documentation gaps — before you commit to anything.