A small PLC's ladder and data memory usually fill before an HMI panel's project memory. Read the project memory report in the panel's programming software and the ladder and data totals in the PLC software, time the heaviest screen on the real link, and size both memories to 25% free.
A panel that feels too big for a small PLC is usually telling on the PLC. Fix the PLC side first: keep the ladder and data report at 25% free before you look at panels at all. Ladder and data memory in a small PLC runs to a few kilobytes. An HMI project store runs to megabytes, so the PLC ceiling arrives first on most small pairings. A screen that polls 40 scattered tags at 9600 baud takes about 1.0 s to refresh until you regroup the tags.
Before you buy hardware or delete screens, put numbers on it. Read the project memory report in the panel's programming software. Read ladder and data words used in the PLC software. Time the heaviest screen on the real link. This checklist takes those three readings in order, works the arithmetic on a 40-tag screen, and lists the fix for each limit.
Which memory runs out first, the panel's or the PLC's?
On a small PLC the ladder and data memory usually fill before the panel's project memory, because the PLC carries a few kilobytes of user memory while the panel stores its project in megabytes.
The reason is what each side stores. Every screen-change bit, alarm bit, setpoint register and handshake tag lives in PLC data memory, and the ladder logic that serves them consumes ladder words. The panel holds screens, objects and bitmaps, and even the smallest models publish project capacity in megabytes on their datasheets. With a small PLC attached, the PLC report is the one that goes red first.
Check the panel report second, because the order reverses when the PLC is mid-size: a graphics-heavy project can fill a panel long before the PLC notices. The two reports, not a screen count, decide which hardware, if any, you need to buy.
What counts as a large HMI project?
"Large" is a count, not a feeling: write down the screens, the objects per screen, the distinct PLC addresses the panel reads or writes, the bitmaps and imported graphics, and every alarm, trend and log.
Group the counts by where they land:
Project content
- Screens: the total, and which ones are duplicates with one object changed.
- Objects per screen: buttons, lamps, numeric displays, bar graphs, keypads.
- Bitmaps and imported graphics: usually the largest single consumer of panel project memory.
- Alarms, trends and logging: these also take project memory, and they grow while the project runs; how a panel can store PLC data for later retrieval is its own subject.
PLC side
- Distinct addresses the panel reads or writes: these sit in data memory.
- Ladder routines that serve the screens: screen-change logic, alarm handling, setpoint limits.
Each count fills one of three places, and the table below maps them so you know which report to read first.
| Count | What it fills |
|---|---|
| Screens, objects, bitmaps | Panel project memory |
| Alarm bits, setpoints, handshake tags | PLC data memory |
| Ladder routines serving the screens | PLC ladder memory |
| Distinct addresses per screen | Link load on the port, and refresh time |
How do you read the panel's project memory before you buy?
Compile the project in the panel's programming software and read the memory report it prints, then compare that figure with the project capacity in the datasheet for your exact panel part number.
The report converts your actual screens into bytes. The datasheet states the capacity for that part number, and the figures differ between models, so read both from the same hardware. When the report reads high, sort by consumer before you cut screens: bitmaps and duplicated screens go first, and a project built from text objects rarely reaches the ceiling.
| Reading | Meaning | Next check |
|---|---|---|
| Report well inside datasheet capacity | Panel is not the limit | Read the PLC report |
| Report near datasheet capacity | Panel is the limit, graphics usually dominate | Repair table below |
Keep a copy of the report with the project file, so the next engineer starts from bytes instead of from a screen count.
How do you read the PLC's ladder and data memory?
Compile the PLC program and read the ladder words used against available and the data words used against available, then watch cycle time and memory use on the online monitor after download.
Online monitoring of cycle time and memory usage on a live CPU is a standard feature of PLC programming software, and the device limits for your CPU come from its user manual. Screens cost the PLC twice: the tags they touch sit in data memory, and the logic that serves them sits in ladder. A project that looks light in the panel software can be heavy here, which is why this reading decides the buy on most small pairings.
| Reading | Meaning | Next check |
|---|---|---|
| Ladder or data near its limit | PLC is the limit; a bigger panel changes nothing | Repair table below |
| Both with headroom | Project fits on paper | Time the heaviest screen |
Worked example: how long does a 40-tag screen take to refresh on a serial link?
At 9600 baud with 8 data bits, no parity and 1 stop bit, 40 tags polled one at a time take about 24 bytes each per refresh, so a full screen refresh takes about 1.0 s, and one block read cuts it to about 0.15 s.
A project can fit in both memories and still run badly, so time the traffic. Take a screen with 40 tags in registers scattered across the data area, on a serial port at 9600 baud, 8 data bits, no parity, 1 stop bit:
- 10 bits per byte on that port: 1 start bit + 8 data bits + 1 stop bit.
- A scattered poll uses about 12 bytes out and about 12 bytes back per tag, frame sizes typical for a small register read: 40 tags x 24 bytes = 960 bytes per refresh.
- 960 bytes x 10 bits per byte = 9600 bits, so one full screen refresh takes 9600 / 9600 bps = 1.0 s, with nothing else on the port and the PLC scan time on top.
Regroup the same 40 values into 60 contiguous registers and read them as one block:
- One request and one response carry roughly 140 bytes: about 20 bytes of framing plus 2 bytes per register x 60 registers.
- 140 bytes x 10 bits per byte = 1400 bits, and 1400 / 9600 bps = about 0.15 s, roughly 7 times faster.
The frame sizes are estimates; your protocol's frames differ, so settle it on the bench. Page to the heaviest screen with the real PLC attached and watch how long values take to update. A practical target is 0.5 s or better for setpoints and alarm lamps. Slow on one screen means regroup that screen's tags or trim its objects. Slow on every screen points at the link itself, the port settings, or another device sharing the port, and if the project replaces an older panel, check the PLC serial protocol before replacing a legacy HMI before you blame the wire.
What do you change when a report is nearly full?
Match the repair to the report that hit the limit, because a bigger panel fixes a full PLC no better than a bigger PLC fixes a full panel.
| Limit reached | Tonight, from a saved copy | Permanent fix |
|---|---|---|
| Panel project memory | Remove unused bitmaps and duplicate screens | Cut bitmap count and size, merge screens, or choose a panel whose datasheet capacity fits the report with margin |
| PLC ladder or data | Comment out unused routines | Consolidate logic, share screens behind one tag, or move to a CPU with more user memory per its manual |
| Link refresh time | Trim the heaviest screen's objects | Regroup tags into contiguous blocks, check port settings, move the poll to a faster port |
One PLC-side fix earns its space twice: run PLC logic only while its screen is active, which trims both ladder words and cycle time. On most small PLCs, expansion modules add inputs and outputs but no user memory, so the ladder and data row ends in a CPU model change when the report stays near the ceiling.
How do you prove the project before it goes to the floor?
Rebuild, download, and walk every screen with the real PLC attached, because a project that compiles clean can still read the wrong address on the floor.
- Rebuild the panel project and record the memory report it prints.
- Compile the PLC program and record ladder and data words used against available.
- Download both, and check the panel's firmware revision before the transfer, because a revision mismatch can fail a clean project.
- Step through every screen and confirm each object reads and writes the correct address.
- Trigger each alarm and each screen-change bit from the panel and confirm the PLC responds.
- Save dated copies of both project files before the machine returns to production.
Leave the margin you sized for. If either report came back close to its ceiling, finish the repair list before the download, because a project filled to the last word leaves no room for the first change request.
What do you send with a quote?
Send the panel part number, both memory reports, the PLC model with its user memory totals, and the tag list for the heaviest screen with the link type and baud rate.
Group the package so each item decides something:
From the panel side
- Panel part number and its datasheet project capacity.
- The programming software's memory report and the bitmap count.
From the PLC side
- CPU model, ladder and data words used and available.
- Cycle time from the online monitor after download.
From the link
- Port type, baud, and any other device sharing the port.
- Settle time measured on the heaviest screen.
If the project sits at a limit, or a download fails while the report still reads inside the datasheet capacity, take this package to the panel supplier's technical support. It turns a conversation about "too many screens" into a decision about bytes.
Recommendation: Read the two memory reports and time the heaviest screen before you buy a panel or a PLC, and size both memories to 25% free so one round of change requests is an edit instead of a rework. On a small PLC, treat the ladder and data report as the limit that fills first: spend your first effort on the PLC side, and your first money only after both reports and one timed screen agree.
Questions
Can you read the panel's memory use while the project is running?
Many panel runtimes publish diagnostic registers that report free project memory and related resource figures. Ordinary numeric and lamp objects placed on a maintenance screen can read those registers live, so you can watch memory from the panel itself. Whether your model exposes them, and at which addresses, comes from the programming software's manual for that panel.
Why is there no fixed number of screens per panel?
Memory is consumed by objects, graphics and logging, and two screens can differ by orders of magnitude: a screen of text objects takes a small fraction of one full-screen bitmap. The software's report converts your actual screens into bytes, and the datasheet states the capacity for that part number. That pair of figures is the honest screen count.
Can a small PLC's user memory be expanded?
On most small fixed-configuration PLCs the user memory is built into the CPU and cannot be expanded; expansion modules add inputs, outputs or communications, not program words. When the ladder or data report is nearly full, the permanent fix is a CPU model with more user memory, and that CPU's manual publishes the figure to check against your report.
Is 25% free the right margin for every project?
25% free is a sizing margin for one round of change requests, not a datasheet value. Leave more when the project expects steady growth in screens or logging, and less only when the hardware is fixed and the screens are final. The margin that matters most sits on the memory your project hits first, which the two reports identify.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.