An operator panel that only displays and enters values records nothing; a panel logs history when its own manual documents a logging function with a sample interval, capacity, power-loss retention and an export path. Where the manual names no logger, put the history in PLC retained registers for sparse records, a dedicated logger for days of trend, or a PC application that polls the PLC. The article sizes a 7-day, 5-second log at about 121,000 records.
An operator panel is a window onto the PLC: it reads words and bits across its driver link, draws them on screen, and sends your entries back to the controller. That live view is the whole job of a display-only panel. History you can retrieve later needs a component whose manual documents a logging function, with four facts printed in it: a sample interval, a storage capacity, retention across power loss, and an export path to a PC. This article gives the decision rule, the sampling arithmetic, and one worked example: eight channels logged every 5 seconds for 7 days come to 120,960 records, about 3.9 MB, which any documented flash logger holds and a fixed 300-record block does not. The same four documented facts settle whether one panel can travel between PLCs and upload later.
Can an operator panel log PLC data, or only display it?
A display-only operator panel does neither: it reads live words and bits from the PLC across its driver link and redraws them at each update, and a panel that keeps history keeps it only because its manual documents a logging function with capacity and retention numbers.
So the real question is what your panel's own manual documents, and there are two families on the market. HMI configuration software sold with current panel hardware carries a data-logging chapter that runs from collection to processing to a stored file, and operator-terminal manuals describe the same flow from collection to a logging file. Panels sold as a graphical operator interface list parameter entry and display of word and bit information as their functions and say nothing about storage. Check the function list or the manual index: where logging appears only in a live-trend chapter, the panel draws a moving graph and keeps no archive. Where the panel will sit matters too, because a factory status display and an operator HMI answer different questions.
What is the difference between showing a value and keeping a record?
A shown value lives in the panel's display buffer and is overwritten at the next update, while a record is a value with a timestamp written once to storage the logger owns, so it survives a disconnect, a power cycle and a week on the shelf.
A trend line on screen is rebuilt at every update from the current value; nothing is written to storage you can read back. A record differs in three ways: it carries a timestamp, it is written once to non-volatile storage, and it stays readable after the panel disconnects or the power drops. That third property is what later retrieval means, and it is a storage question. The timestamp deserves early attention: when PLC records and PC records have to line up in one report, both clocks need one time source and one unit convention, which is the job covered in converting PLC timestamp units for factory displays.
What must the logger's documentation say before you trust it?
Four documented facts decide it: the sample interval, the storage capacity in records or bytes, whether records survive a power loss, and the export path to a PC; a logger whose manual prints all four does the job, and one whose manual prints none stores nothing.
Take the four in order.
- Sample interval. The manual states the fastest interval the logger accepts and whether it fires on time, on value change or on an event. Size the log from the printed interval.
- Capacity. Stated in records, or in a storage medium with a stated size. Compare record counts between candidates, because that is the limit that bites first at trend rates.
- Power-loss retention. Retained registers hold a fixed block of rows; file-based loggers write to flash or a memory card. The manual names which one you get.
- Export path. A file format and a transfer the office PC can read: file download over the network, an upload service, or moving the card.
Alarm history is a cousin, not a substitute: a historic alarm table stores event rows with time, text and state, which is exactly right for what happened and wrong for a value trend. Historic mode in an alarm table is a documented feature in its own right, covered in historic alarm table records and formatting.
How fast can a PLC-side logger sample?
At the scan rate: a typical PLC scans its logic in 10 to 100 ms, which gives an effective sample rate of 10 to 100 samples per second per channel, so any log interval of 100 ms or slower is honest, and faster capture needs hardware made for it.
The scan time is the ceiling. Between 10 ms and 100 ms of scan, a 1-second log interval sees every scan the controller ran, while a 10 ms interval sits at the limit and leaves nothing spare for the rest of the program. Keep the logging write short and put it at a fixed point in the scan; a heavy transfer sitting inside the loop is a separate problem, and moving cycle-end data transfers out of the PLC program is the standard fix. If the log pointers and rows live in retained registers, also check what writes those registers at startup, because an HMI that pushes startup values into retained variables can erase the log you just built, the failure documented in an HMI overwriting PLC retained variables at startup.
Worked example: what does 8 channels every 5 seconds for 7 days cost in storage?
About 121,000 records and 3.9 MB: 86,400 seconds divided by 5 seconds is 17,280 records per day, times 7 days is 120,960 records, and at 32 bytes per record the week fills 3,870,720 bytes, which any documented flash logger holds.
The requirement. Eight analog values from one machine, one record every 5 seconds, 7 days of retention, review on the office PC.
The arithmetic.
- Records per day: a day holds 86,400 s, so 86,400 s ÷ 5 s = 17,280 records.
- Retention: 17,280 records/day × 7 days = 120,960 records.
- Record size: 8 channels × 2 bytes per 16-bit value = 16 bytes of values, plus an 8-byte timestamp = 24 bytes, padded to 32 bytes per record for headers and separators. The padding is a working assumption; the logger's own row format decides the exact figure.
- Storage: 120,960 records × 32 bytes = 3,870,720 bytes, about 3.9 MB.
The decision. At trend intervals the bytes are never the constraint; the documented record count is. For this requirement, any logger whose documentation states at least 121,000 records of capacity, or states a flash medium sized in megabytes, does the job. A PLC with a built-in logger of 300 records covers 300 × 5 s = 1,500 s, which is 25 minutes of this trend, so it serves one row per batch and not a week of history; one PLC family documents exactly that figure in 300 logging records stored without a host PC. Raise the rate to 30 channels at 1 sample per second and the same 7 days is 30 × 604,800 s = 18,144,000 records, about 581 MB at 32 bytes each. That scale belongs on a PC with a disk and query tools.
Where should the records live: PLC, dedicated logger, or PC?
Sparse records live in the PLC, trend history for one machine lives in a logging-capable HMI or a dedicated logger, and many PLCs or rates near 1 sample per second live on a PC application that polls each controller and writes timestamped rows to disk.
| Storage point | What the documentation states | Holds in the worked case | Pick it when |
|---|---|---|---|
| PLC retained registers | a fixed record count, for example 300 | 25 minutes of 5-second trend, or 300 batch rows | one record per batch, lot or shift |
| Logging-capable HMI or dedicated logger | interval, capacity, power-loss retention, export | 120,960 records, about 3.9 MB | days of trend at one machine |
| PC application polling the PLC | disk-limited rows with query and export tools | 18.1 million records for 30 channels at 1 sample per second | several PLCs, months of data |
The table's numbers come from the worked example above, so they move with your interval and channel count: halve the interval and both record counts double. The PC route also owns the retrieval end, which is where the documented export path earns its place.
Can you carry one panel around the shop and upload later?
Only where the panel's manual documents offline collection and a transfer path, because the portable plan needs three documented pieces: a driver for each PLC, storage on the panel, and an export the office PC can read, and a display-only panel stops at the first piece.
That workflow asks the panel to do three jobs per PLC, and each has a check.
- List every PLC model, its protocol, and the addresses you need to read.
- Check the panel application documents a driver and an address format for each one; a link that works on one controller says nothing about the next.
- Connect to one PLC, force a known value, and compare the panel display against the controller's own online value.
- Repeat the known-value test on each PLC before you trust the round.
- Storage is a separate test from the live read: record a known value at the set interval, power-cycle the panel, and read the rows back with their timestamps.
- Watch the row count for duplicates, because a trigger that fires on every scan instead of on the interval writes the same value again; one vendor documents a data-logger repeated-records fix for exactly that behaviour.
Connect and disconnect cables with the machine in a safe state, never mid-cycle. If the manual names no logging function, the panel remains a viewer on wheels: the collection requirement goes to a portable documented logger, and the panel can keep the live display job.
Does a separate shop-floor status screen change any of this?
Nothing about the records changes: a status or notice screen shows what it is given, so the logger writes the history, the screen carries current shift messages beside the machine, and retrieval happens in the logger or on the PC.
A notice or status board answers a different need: shift targets, safety messages, andon states, the things a whole crew reads from a distance. It draws from what it is given, so pair it with the logger instead of asking it to keep records. The choice between a live value board and a message board is its own comparison, set out in live factory data display: signage or dashboard?. If the job is the notice board, our shop-floor display category is where those screens live, with offline playback or your own Android app; the history still lives in the logger or on the PC.
Which option should you pick?
Pick by record rate and retention: one row per batch or shift goes in PLC retained registers, days of 5-second trend at one machine goes in a logging-capable HMI or a dedicated logger, and several PLCs at 1 sample per second go on a PC application.
Recommendation: put the history where the documentation supports it. Use PLC retained registers only for sparse records such as one row per batch, lot or shift; use a logging-capable HMI or a dedicated logger for one machine logging at 1 second or slower with days of retention; use a PC application polling each PLC once you have several controllers or rates near 1 sample per second. Before any order, have the vendor print the four numbers in writing: sample interval, capacity in records, power-loss retention, and export path. Then run the known-value, power-cycle and read-back test from the portable section before the logger sees real data.
Questions
Whose clock stamps a logged record?
The component that writes the row stamps it from its own real-time clock. If the PLC writes the record, the PLC clock decides the time; if a PC application polls and writes, the PC clock does. When two sources must merge into one report, set both clocks from one time source and keep note of the offset, because minutes of drift reorder events in the merged history.
What happens to stored records when the power fails?
Whatever the documentation states. Retained registers keep their fixed block of rows across a power cycle; file-based loggers write to non-volatile flash as the manual describes. A buffer whose retention the manual leaves unstated should be treated as empty after an outage, which is why the retention check belongs in the buying step and not after the first power cut.
How do I test a logger before it holds real data?
Push one known value through the whole chain. Force a value in the PLC, let the logger record at its set interval for a few minutes, power-cycle the storage device, then read the rows back on the PC and compare values and timestamps against the controller. Scan the rows for duplicates too, since a trigger that fires twice per interval inflates the record count.
Does a bigger or newer panel solve the storage problem?
Screen size and resolution are display facts and change nothing about storage. Logging exists where the function list documents it, on small panels and large ones alike, and is absent where the list omits it. Size the logger to the record rate and retention from the worked example, and size the panel to what the operator needs to see at their distance.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.