Log a question, not everything
Choose the smallest tag set that can separate command, controller decision, physical response and process consequence.
A live value shows now. A useful log explains what changed, in what order, under which operating state, and whether the sample can be trusted. Good PLC data logging starts with a diagnostic question, then chooses tags, timestamps, sample behavior, quality and retention to answer it.
Product evidence: HMI trend widgets can plot multiple numeric tags from a rolling in-memory buffer while the simulation runs. Alarm transitions also retain ordered history. The product does not yet claim persistent historian storage, CSV export, timestamp synchronization or production OPC UA Historical Access.
Raw signal, engineered value, command, feedback, state and quality describe the event.
Periodic, cyclic or event-based capture preserves the changes the question needs.
Timestamps, units, retention, metadata and missing-data policy make samples interpretable.
Aligned pens reveal order, delay, correlation and the boundary for the next physical check.
A trend is credible only when the value, time basis, quality and operating context are understood together.
Answer first
PLC data logging is the capture of selected controller or process values over time so they can be reviewed after the moment has passed. A complete logging design defines which values are recorded, when they are sampled, whose clock supplies time, how data quality and units are stored, how long records are retained, and how users retrieve or visualize them. A live trend is a display; a historian adds persistent, queryable storage and operational controls.
Choose the smallest tag set that can separate command, controller decision, physical response and process consequence.
Sampling period, source timestamp, clock synchronization and missing samples determine whether event order and delay are trustworthy.
A rolling browser graph helps learning and live diagnosis. Persistent historical storage needs retention, query, integrity, access and recovery capabilities.
Define the question
Logging every available tag creates cost and noise without guaranteeing an answer. A focused evidence set begins with a fault, performance or compliance question.
Why did the conveyor stop three times during high throughput?
Run request, permissives, final output command and sequence state.
Drive running, speed feedback, overload and relevant sensor transitions.
Line speed, queue, jam alarm and stop event establish operational impact.
The four categories form an evidence chain. Missing one category often leaves the investigation unable to separate software command from field response.
A diagnostic log should distinguish layers. For a motor that stops intermittently, record the operator or sequence request, the final PLC command, every critical permissive, drive or contactor feedback, fault code and a process variable such as speed or current. If only the motor command is trended, you can see that the PLC turned it off but not why. If only feedback is trended, you cannot tell whether the controller requested the stop.
A performance log may emphasize rate, cycle time, queue depth, energy or control error. A quality log may need recipe, batch, measured conditions and product identifier. A compliance record can require validated timestamps, audit trails and controlled configuration. These purposes have different integrity and retention needs; do not let a convenient HMI trend become an undocumented system of record.
Tag naming and metadata make later analysis possible. Store a stable identifier, human-readable description, engineering unit, source, scale and quality meaning. When equipment is duplicated, include asset context without embedding a temporary screen label. A trend called Value1 is almost useless six months later; Reactor2.TemperaturePV with °C and a known source can be interpreted.
Keep the set small enough to review during the event window. Begin with the causal chain, then add supporting variables when a hypothesis needs them. This staged method also reduces controller, network and storage load. In a persistent historian, collect high-value standard tags continuously and enable higher-resolution temporary traces for difficult commissioning or intermittent faults where the platform supports it.
| Question | Minimum useful tags | Context | Likely mistake |
|---|---|---|---|
| Why did an actuator stop? | Request, command, permissives, feedback, fault | Mode and sequence state | Logging only command or only feedback |
| Why did a loop oscillate? | SP, PV, CV, mode and limits | Sample period and tuning revision | Sampling too slowly to show the oscillation |
| Why did a batch fail? | Recipe, phase, key PVs, commands, alarms | Batch/lot and change history | No product or recipe correlation |
| How long is the cycle? | State transitions or cycle start/end events | Product type and downtime reason | Estimating from irregular analog samples |
Capability boundaries
The word “logging” often hides three architectures. Define which one the requirement actually needs before promising retention or analytics.
Short in-memory sample window for current observation and practice.
Sparse records created when alarms, modes or sequence states change.
Persistent, timestamped and queryable time-series storage with retention controls.
Correlate events, compare periods, export evidence and reconstruct incidents.
These surfaces can work together. A trend can visualize historian data, while event records add sparse state changes alongside periodic process samples.
A live trend samples values into a recent buffer and draws them while the screen is open. It is excellent for observing a setpoint change, process response or intermittent input during a session. If the browser closes, the buffer can disappear. It may have no wall-clock timestamps, user identity, query language, backup or long-term retention. Describe it as a trend, not a historian.
An event log records changes rather than every scan. Alarm raised, alarm acknowledged, sequence entered Fill, recipe changed and operator selected Manual are event examples. Events provide exact semantic milestones and usually need timestamps and metadata. They complement periodic samples: the trend shows how temperature moved, while the event log shows when the controller changed phase or the operator acknowledged an alarm.
A production historian stores time-series data persistently and supports retrieval over defined retention periods. It may handle compression, deadband, interpolation, quality, clock behavior, redundancy, access control, backup and reporting. OPC UA Historical Access defines services for accessing historical data; implementing or connecting those services is materially different from drawing an SVG polyline from a browser array.
Be explicit about the system of record. An operator-screen plot can support immediate diagnosis even when the historian is authoritative. A controller trace can capture high-speed detail for a short window while the historian provides months of context. Exported CSV can help offline analysis but needs version, unit, timezone, missing-data and integrity context before it can support a formal decision.
| Surface | Best for | Typical duration | Required caution |
|---|---|---|---|
| Live rolling trend | Current behavior, tuning practice, quick fault observation | Seconds to one session | May not persist or carry reliable wall-clock time |
| Event log | Alarm and sequence order, operator actions, changes | Configured record retention | Needs semantic event definitions and synchronized time |
| Historian | Long-term process analysis, reporting and retrieval | Days to years by policy | Requires storage, access, integrity and lifecycle design |
| Controller trace | High-speed short-window diagnostics | Small pre/post trigger window | High detail but limited duration and target-specific behavior |
Time resolution
Sampling frequency should follow process dynamics and the diagnostic question. Faster is not automatically more truthful if timestamps, buffering or storage cannot keep up.
Define pulse, oscillation, response delay or transition the log must reveal.
Select periodic, task-linked, change-based or triggered capture.
Check controller, network, buffer, database and visualization load.
Generate a known event and confirm samples preserve its order and shape.
Start from the shortest event or response time you need to distinguish, then verify the complete capture path under realistic load.
If a sensor chatters for 100 milliseconds, one sample every minute cannot diagnose it. If tank level changes over hours, millisecond samples waste bandwidth and storage while adding little information. Identify the shortest event, response time or oscillation period relevant to the question, then choose a resolution with enough points to distinguish its shape and order. Use a controller trace or event capture for very fast logic that a supervisory historian cannot economically sample.
Periodic sampling records on a time interval. Task-linked sampling records every task cycle or every nth cycle. Change-based recording stores when the value changes beyond a defined condition or deadband. Triggered capture keeps a pre-event and post-event window around a fault. These methods can be combined. Each creates different gaps and interpolation assumptions, so the trend viewer should not imply continuous measurement where only sparse samples exist.
The sample timestamp can come from the controller, gateway, server or client. Network delay means arrival time is not always measurement time. For event-order analysis across devices, synchronize clocks and record source timestamps plus quality where available. Define timezone and daylight-saving handling for human reports. A plot with unlabeled local time can be ambiguous during clock changes or cross-site review.
Test the capture path under load. Controller tasks, communications, database writes and visualization can compete for resources. Official CODESYS trend documentation, for example, warns that excessive recording or storage work can contribute to task timeouts on constrained targets. Reduce variables, adjust intervals or move the workload rather than risking the control task for a prettier chart.
Trustworthy samples
Zero may mean a real zero, an uninitialized tag, a disconnected device or a failed conversion. The log must preserve enough context to distinguish them.
Raw or engineered numeric state with documented type and scale.
Source time, timezone and ordering behavior are defined.
Good, uncertain, bad, stale or substituted state remains visible.
Unit, asset, mode, batch, recipe and revision make the sample interpretable.
Not every platform stores these fields the same way. The principle is to keep interpretation separate from the raw numeric value.
Keep raw and engineered values when troubleshooting scaling. A transmitter might provide 4–20 mA represented as counts, while the PLC calculates percent or engineering units. If the scaled value is wrong, the raw count separates field signal from conversion logic. Include range and unit. A bare value of 75 can mean percent, degrees Celsius, bar, hertz or an integer status code.
Quality should survive the interface. Communication loss, out-of-range input, stale sample, substituted value and maintenance override are not ordinary measurements. Plotting them as zero creates false process excursions and can trigger misleading analysis. Some systems use status codes or quality flags; others require companion tags. Decide how users will see gaps, bad quality and manual substitution.
Operating mode is often the missing explanatory variable. The same valve command can be expected in Manual and suspicious in Auto. Record sequence state, recipe or batch identifier alongside key process values. Also record configuration revision for analysis spanning a logic or tuning change. Otherwise two periods may appear comparable even though the control strategy differs.
Missing data needs a policy. A line connecting the last good point to the next can imply a smooth process that was not observed. Step, linear interpolation and hold-last-value each answer different display needs and can be wrong for event analysis. Mark gaps visually and retain original samples so presentation choices do not overwrite evidence.
Correlated trends
A multi-pen trend narrows the fault window by showing where the first disagreement appears in the signal chain.
Shows what the controller believed about the initiating condition.
Shows whether PLC logic requested the actuator or changed state.
Shows whether the device or process responded to the command.
Shows speed, flow, pressure, stop event or alarm resulting from the chain.
The first divergence guides the next inspection. Correlation creates a hypothesis; physical verification establishes cause.
If command and feedback fall together, the controller may have intentionally stopped the actuator; inspect permissives and sequence state before replacing hardware. If command remains true while feedback falls, investigate the output path, drive, contactor, wiring or load. If both remain true while the process value collapses, the measurement or mechanical process may be the problem. The aligned pens turn one symptom into a smaller diagnostic branch.
For intermittent faults, add an environmental or operating correlate: vibration, current, temperature, line rate or product size. Repeated alignment can establish a useful hypothesis. It is not proof of causation. Inspect and reproduce the suspected connection, component or process condition where safe. Document the physical proving test that confirms or rejects the trend-based hypothesis.
Use event markers for operator actions, alarms and sequence transitions. A graph alone may not reveal that a mode changed or an acknowledgement occurred. Overlaying or correlating event history helps reconstruct the narrative. Time synchronization is essential if the drive, PLC and SCADA generate events on different clocks.
After a repair, capture the same signals over the same operating condition and compare before and after. Confirm the original mismatch is gone without introducing oscillation, longer cycle time or new alarms. A post-fix trend is stronger evidence than a single successful restart because it tests the repaired boundary over time.
| Command | Feedback | Process value | Next boundary to inspect |
|---|---|---|---|
| Off | Off | Stops | Why PLC removed command: mode, permissive, sequence or fault |
| On | Off | Stops | Output module, wiring, drive/contactor, actuator or load |
| On | On | Wrong response | Mechanical process, sensor, scaling or wrong feedback meaning |
| Changing rapidly | Follows | Oscillates | Input noise, control logic, tuning or threshold hysteresis |
| Stable | Stable | Displayed gap | Logging quality, communication, sampling or timestamp path |
Storage lifecycle
Storage policy is an engineering and governance decision. It balances resolution, duration, retrieval speed, integrity, privacy and cost.
Keep enough detail for current faults, tuning and commissioning windows.
Compress or aggregate while preserving events and required accuracy.
Protect records needed for quality, compliance or long-term analysis.
Remove data according to policy with recoverability and legal needs considered.
Different tag classes can use different policies. A fast diagnostic trace and a daily production total should not inherit one arbitrary retention setting.
Estimate volume from tag count, sample frequency, record size, compression and retention. Then test with realistic changes because compression performance depends on the data. Preserve raw detail around events where possible. Averages can hide a short overshoot, while min/max envelopes or triggered windows retain more diagnostic value. Document which transformations occur before analysts treat an aggregate as raw evidence.
Set retention by use case. Recent high-resolution data supports maintenance and commissioning. Longer-term compressed data supports performance and capacity analysis. Batch, quality or regulated records can have prescribed retention and audit requirements. Separate personal or user-action data where privacy and access policy differ from ordinary process measurements.
Export should include headers and metadata: stable tag name, description, unit, timestamp format and timezone, quality, sample method and data revision. CSV is convenient but does not enforce types or provenance. For formal transfer, consider checksums, signatures, immutable storage or controlled report generation as the risk requires. A downloaded chart image is a communication aid, not the underlying record.
Plan backup, restore and failure behavior. What happens when the database is unavailable, disk fills, network drops or the controller reboots? Buffering can bridge brief outages, but it has finite capacity. Surface data loss rather than drawing a continuous line. Test recovery and confirm that resumed collection does not backfill invented values or duplicate records without identification.
Acceptance evidence
A logging system is not verified because a line appears on screen. Prove value accuracy, sample behavior, time, quality, retention and recovery independently.
Apply endpoints, midpoint and a non-symmetric changing pattern.
Generate a transition and compare source and stored ordering.
Interrupt communication or storage and verify quality and gap behavior.
Query, trend or export the window and reconcile every expected sample or event.
A non-symmetric ramp and deliberate gap expose scaling, ordering and interpolation mistakes that a constant signal cannot reveal.
Generate known raw and engineered values at zero, midpoint and span. Confirm stored types, scale and units. Use a changing pattern rather than a flat line to expose delayed or swapped tags. If two registers form one value, choose a pattern that differs across both words. Reconcile the source tag, stored value and displayed trend separately.
Create a timed pulse or state transition and record it at the source and historian boundary. Measure effective sample spacing and event order under ordinary and high load. Verify timezone and daylight-saving presentation if humans use local time. When multiple devices contribute, compare their clocks and define the acceptable synchronization error for the analysis.
Interrupt the communication or storage path. The display should show bad quality or a gap according to policy, not an ordinary zero or smooth invented line. Restore the path and verify buffering, duplicate handling and chronological order. Fill a test buffer or exceed a small retention limit in a safe environment to prove oldest/newest policy and alerting.
Finally retrieve the data using the same query, trend or export workflow operators and analysts will use. Access controls, tag aliases, aggregation and report timezone can introduce errors after storage succeeds. Keep a small acceptance dataset with known values so the end-to-end path can be rerun after upgrades or mapping changes.
Related technical cluster
These are the closest supporting owners and product surfaces. Each link advances a specific part of the same engineering task instead of sending you to a generic content index.
Verified product surface
The shipped HMI workspace provides a genuine live trend surface and ordered alarm transition history. The public page describes those capabilities precisely and exposes the production gaps instead of blurring them.
Run mode keeps per-tag numeric sample arrays only when a project contains a trend widget, avoiding unnecessary history work on screens that do not use trends.
A trend can plot a primary numeric tag plus additional de-duplicated tags with independent pen colors, scale bounds, units and a visible legend.
HMI exercises expose changing REAL process values such as temperature and setpoints so learners can correlate trends with commands and physics.
Alarm history records transition kind, destination state and monotonically increasing sequence order in a capped in-memory buffer.
The browser history is session-scoped training data, not a persistent historian. It does not currently provide source timestamps, synchronized clocks, data-quality codes, CSV export, database retention, compression, historical queries, audit-grade identity, OPC UA Historical Access, backup or redundancy. Those gaps define valuable product features and additional future SEO/GEO surfaces.
Answer-engine questions
PLC data logging is the time-ordered capture of selected controller and process values for later review. A complete design defines tags, sampling, timestamps, quality, units, retention, access and failure behavior rather than merely drawing a live chart.
Log the causal chain: initiating input or request, critical permissives, final PLC command, physical feedback, fault or alarm, process consequence and operating state. This lets you locate the first disagreement instead of seeing only the final symptom.
Choose the interval from the fastest event or response the analysis must distinguish, then verify controller, network and storage capacity. Slow processes may need seconds or minutes; short pulses or oscillations may need task-linked traces or triggered high-speed capture.
A trend visualizes values, often from a short rolling buffer. A historian persistently stores timestamped data and supports retrieval, retention, quality, access, backup and other lifecycle controls. A trend can display historian data, but the graph itself is not the historian.
A numeric value alone cannot distinguish a real zero from communication loss, stale data, substitution or an invalid sensor. Store or expose quality separately so bad samples do not enter calculations or appear as ordinary process excursions.
For critical diagnostics, keep both when practical. The raw value proves the I/O or communication input; the scaled engineering value proves conversion. Also retain unit, range and quality so a scaling fault can be separated from a field-device fault.
Yes, when the selected tags and sample rate capture the event. Trend raw input, command, feedback and consequence together, then add likely correlates such as vibration, current or temperature. Correlation guides a physical proving test; it is not final proof of cause.
Include stable tag name, description, value, type, engineering unit, timestamp format and timezone, quality, sampling method and data or configuration revision. Identify missing samples and avoid silently interpolating values in the exported record.
Apply known endpoints and a changing pattern, generate a precisely timed event, interrupt communications or storage, restore service, then query or export the window. Verify value, order, spacing, quality, gaps, duplicates, retention and access end to end.
No production historian claim is made. The HMI Builder has live rolling multi-pen trends and ordered in-memory alarm transition history. Persistent timestamped storage, queries, export, quality, retention, backup and OPC UA Historical Access remain future product opportunities.
Primary sources
This guide separates transferable engineering practice from product-specific behavior. Use the primary sources below for exact standard wording, target-controller support, firmware behavior and production design decisions.
Turn the guide into evidence
Build a four-pen HMI trend with request, final command, physical feedback and process value. Run a normal cycle and a controlled fault, then identify which signal diverges first.