The short answer
Controller Memory and Addressing
Controller data lives in a data table, addressed either by file and word on older platforms or by name on tag-based ones. Every value has a type that fixes its size and range: a BOOL is one bit, an INT sixteen bits, a DINT thirty-two, a REAL a thirty-two bit floating point number. The input and output images are the part of the table that mirrors the modules. Whether the address is N7:12 or Wetwell_Level_ft, the program is only maintainable if the names say what the data is and the types match what it holds.
Key points
- Older platforms address data by file type and element; tag-based platforms address it by name, and the name is the documentation.
- The type sets the range: an INT stops at 32,767, a DINT at about 2.1 billion, and a REAL holds about seven significant digits.
- The input image is a copy of the modules taken at the start of the scan; the program never reads a module directly.
- Structures and arrays let one tag hold everything about a pump, and a user-defined type makes every pump the same.
- A naming convention agreed before programming starts is worth more than any amount of commenting afterward.
Two ways to name a memory location
- File-based addressing
- The older scheme: memory is divided into files by type, and an address names the file and the element, such as an integer file element or a bit within a binary file word. The address is fixed by where the data physically sits, and a symbol or comment attached to it is the only clue to its meaning. Many controllers still in service use it, and their programs are read with the symbol table open in one hand.
- Tag-based addressing
- The current scheme: every value has a name chosen by the programmer, a type, and a description, and the controller manages where it sits. The program refers to the name, SCADA refers to the name, and the name carries the meaning. The discipline moves from remembering addresses to choosing names well.
- Absolute addressing with symbols
- Some platforms address memory areas directly, inputs, outputs, flags, and data blocks, and layer a symbolic name on top. In practice the symbol is used everywhere and the absolute address appears only in the hardware configuration.
Data types
| Type | Size | Range | Used for |
|---|---|---|---|
| BOOL | 1 bit | On or off | Contacts, coils, states, and alarms |
| SINT | 8 bits | -128 to 127 | Rarely; some device data |
| INT | 16 bits | -32,768 to 32,767 | Raw analog counts, older platforms, Modbus registers |
| DINT | 32 bits | About plus or minus 2.1 billion | Counters, totals, timers, the default integer on modern platforms |
| REAL | 32 bits | About seven significant digits, huge range | Engineering values, setpoints, calculated values |
| LREAL | 64 bits | About fifteen significant digits | Accumulated totals where seven digits is not enough |
| STRING | Varies | Text of a set maximum length | Messages, identifiers, and recipe names |
| TIME, DATE | Varies | Durations and calendar values | Scheduling and event timestamps |
The type is not a formality. A flow total accumulated in an INT rolls over at 32,767 and reads negative. A total accumulated in a REAL stops incrementing once it reaches about sixteen million, because adding a small flow increment to a large float changes nothing in seven digits. The data type ranges table and the IEEE 754 calculator on this site cover both effects. Choose the type for the largest value and the finest increment the tag will ever see, not for the value on the day it is created.
The images
The input image is a region of the data table that holds a copy of every input module, refreshed at the start of the scan. The output image holds what the program has decided every output should be, written to the modules at the end of the scan. The program reads and writes the images, never the modules, which is why an input cannot change halfway through a scan and why an output set and then cleared in the same scan never energizes. The scan cycle page covers the consequences.
Structures, arrays, and user-defined types
A pump has a run command, a run feedback, a fault, an hours total, a start count, a hand-off-auto state, and half a dozen setpoints. As separate tags that is a dozen names per pump and a program that reads like a phone book. As a structure, a user-defined type named Pump with those members, each pump is one tag, every pump has the same members in the same order, and the logic that handles a pump can be written once and applied to each. Arrays do the same for a list of things of one kind, a hundred alarm bits or twelve level setpoints.
Naming
A tag name is read by the programmer, the SCADA developer, the operator who sees it in an alarm, and the technician who finds it in a fault ten years on. It should say what the thing is, using the instrument tag from the P&ID where one exists, with a consistent structure and no abbreviations that only the author understands. Wetwell_Level_ft says more than LT101_PV, and LT101_Level_ft says the most, because it ties the tag to the drawing and states the unit.
- Use the P&ID tag as the root wherever the tag corresponds to an instrument or a piece of equipment.
- State the unit in the name of every engineering value, so that nobody has to guess whether Level is feet or percent.
- Keep one convention for the whole site, written down, and give it to every contractor.
- Fill the description field. It is what SCADA and the alarm summary display, and it is the only place a sentence fits.
- Never reuse a tag for a second purpose because it happened to be free.
Memory that runs out
Program memory and data memory are finite, and both fill. A program that grows by copy and paste, a data table full of unused tags from an earlier version, and arrays sized for a plant twice this size all consume it. The controller reports the memory in use, and a project that is above about three quarters of the capacity is one that will fail to download after the next change. The remedy is housekeeping, or a larger processor, and the time to find out is before the change order, not during it.
Frequently asked questions
- What is the difference between an INT and a DINT?
- Size and range. An INT is sixteen bits and holds about plus or minus 32,000; a DINT is thirty-two bits and holds about plus or minus 2.1 billion. Modern platforms use DINT by default because the INT range is exceeded by an ordinary counter within weeks.
- Why did my flow total stop increasing?
- It is a REAL, and it has grown to the point where adding one increment does not change the number within its seven significant digits. Accumulate totals in a DINT with a fixed scale, or in an LREAL, and roll the total into a daily or monthly register.
- What is a user-defined type?
- A structure the programmer defines, with named members of various types, that then becomes a type like any other. A UDT for a pump, with its commands, statuses, and setpoints, makes every pump tag identical in shape and lets the pump logic be written once.
- Does the program read inputs directly from the modules?
- No. It reads the input image, a copy taken at the start of the scan, and writes the output image, which is sent to the modules at the end. That is what makes the scan deterministic, and it is why an input cannot change in the middle of a scan.
Related topics
- The PLC Scan CycleRead inputs, solve logic, write outputs, housekeeping. Understanding scan order explains most PLC behavior that looks wrong at first glance.
- Retentive MemoryWhat survives a power cycle in a controller and what does not, how retention is backed up by battery, capacitor, or nonvolatile storage, what should be retentive, and how retained data gets lost.
- Program OrganizationStructuring a controller program so that someone else can maintain it: a layout that follows the plant, one routine per job, standard device blocks, I/O mapped in one place, a fixed execution order, naming that means something, and comments that say why.
- What Is a PLC?A programmable logic controller is a ruggedized industrial computer that reads field inputs, solves a control program, and drives outputs on a repeating, deterministic cycle.
- PLC ArchitectureHow a programmable logic controller is physically organized: the chassis, backplane, processor, I/O modules, remote racks, and what those choices mean for wiring, expansion, and failure.
- The PLC ProcessorWhat the processor module does on every scan, how its memory is organized, what the mode switch and status lights mean, and how it faults and recovers.
Direct contact
Have a controls question?
Reach Eric Sullivan directly about anything on this site, a controls or automation topic, or one of his personal projects.