HMI data logging: 10-minute interval for switch states

What does a 10-minute data log record on an HMI panel?

One row of time-stamped values lands in the file every 10 minutes: 144 rows a day, each a snapshot of every selected bit at its sample instant, with nothing recorded about what changed between rows.

Data logging on an HMI panel is a software object with a trigger. Set the trigger to a fixed period, called cyclic logging in most manuals, and the logger reads every selected tag and appends one row to a file on the card. Each row carries one timestamp for all of its points. The help files for these logging objects list temperatures, flows, levels, pressures and alarm bits among typical contents, and a switch-state log is the same job with bits: values in, one file, rows in time order. The file answers a narrow question well, what was each selected bit at 10:20:00, and the time between rows is unrecorded.

How do you set up periodic logging on the panel?

Build the tag list in the PLC project, not in the panel software: use the data-logging object, give it a fixed 10-minute period trigger, select the switch bits, the output bits and the register values, and point the file at the memory card.

Build the list from the PLC project, not from memory: for every point write down the address, the data type and what it means, and verify each one online against a known machine state before the first row lands. A log full of misaddressed bits is worse than no log. A logged output bit is the value the panel read at the sample instant; it is not proof that the relay pulled in or the load ran, so add the feedback contact as its own point when the machine provides one. Keep the list tight, because every point widens every row and slows the fault review you built this for.

Two project settings decide the behavior after the trigger: the storage target and the card-full policy. Name the card in the project, and pick the documented option for a full card, stop or overwrite the oldest rows; the manual for the panel model carries the exact choice. If the software also has an event manager or event table, its condition rows can start and stop logging under rules, but a fixed-period sample needs none of that machinery, so use the logging object's own period trigger. Download the project through your plant's normal change process, enable the logger, and watch the first rows land.

Will the log catch a switch that turns on and off between samples?

Often no: a pulse that starts and ends inside one 10-minute window leaves no ON row behind. A pulse always gets a row only when it stays on for at least one full interval of 600 seconds.

The samples land every 600 seconds, so a pulse shorter than that sits entirely between two of them unless a sample instant happens to fall inside it. With the pulse timing effectively random against the sample clock, the chance of capture is pulse length divided by interval, and the worked example below runs a real case through it. Reading durations out of the periodic file has its own ceiling: one ON row puts a single closure anywhere from a moment to 2P, which at 600 seconds is 20 minutes, and two neighboring ON rows mean one unbroken closure between 10 and nearly 30 minutes. Let the snapshot rows carry state at instants, and take durations from event rows, which the section below covers.

Scenario: the gate switch pulses for 45 seconds an hour, so will the log catch it?

Only by luck: the chance that any single sample lands inside the 45-second ON window is 45 divided by 600, or 7.5%, so expect to catch roughly 1 of every 13 occurrences.

Here is the arithmetic. Capture chance per pulse = pulse length ÷ interval = 45 ÷ 600 = 0.075 = 7.5%. Eight pulses in an 8-hour shift give an expected 8 × 0.075 = 0.6 ON rows for the whole shift. The chance of zero rows all shift is (1 - 0.075)^8 = 0.925^8: 0.925^2 = 0.8556, 0.8556^2 = 0.7321, 0.7321^2 = 0.5360, so about 54%. More than half of shifts close with nothing in the file even though the gate pulsed eight times.

Decision for this case: keep the periodic file for the rest of the machine, and give the gate switch its own log at a 45-second interval, 86,400 ÷ 45 = 1,920 rows a day, which the storage section below shows is still a small file, or better, an event row on the gate bit.

How short must the sampling interval be to catch every pulse?

Make the interval no longer than the shortest ON time you must catch: a 45-second pulse needs an interval of 45 seconds or less so every pulse lands on a row, and every step shorter multiplies rows and card writes in direct proportion.

The catch is geometry: samples land every P seconds, so an ON window at least P long must contain a sample instant whatever the phase. Duration needs a tighter bound, and the capture section showed that a single ON row puts one closure anywhere from a moment to 2P, so pick a P whose 2P is a statement the report can make. For the 45-second gate, a 45-second interval puts every pulse on a row, and one ON row then reads: the closure lasted somewhere inside 0 to 90 seconds.

Rows per day is 86,400 divided by the interval in seconds, so every step shorter multiplies both the file and the flash writes in the same proportion. Past the bottom row the shape stops working: a 10-second snapshot file holds 8,640 rows of states with no edges in them, and event rows or the PLC's own event history say more per byte.

How much memory card space does 10-minute logging need?

At 144 rows a day, a row of about 36 bytes comes to about 5.2 KB a day and 1.9 MB a year, so even a small 32 MB card holds about 17 years of records.

The 36-byte row is an illustration of a small CSV line: a 19-character timestamp, eight one-character points and eight commas, 19 + 8 + 8 + 1 newline = 36 bytes. Day: 144 × 36 = 5,184 bytes. Year: 5,184 × 365 = 1,892,160 bytes. Widen the file to 20 points and 100-byte rows and the year is still about 5 MB, so capacity gives no reason to choose the interval; the pulse math in the section above chooses it.

Write pace, not capacity, is the card's real limit. Sampling every second would put 86,400 rows and 86,400 × 36 = 3,110,400 bytes, about 3.1 MB, on the card each day, 600 times the row count and 600 times the flash writes of this pace. Flash cells on common consumer cards survive a few thousand write cycles, industrial-grade cards tens of thousands, so a 10-minute pace is easy on any card, and the card grade matters more for cabinet temperature.

Pull the files on a schedule you will keep, weekly or monthly, and archive each one with the project version that wrote it; getting rows off a card and keeping them readable is the same job as storing PLC data on an HMI panel for later retrieval. If rows stop for no visible reason, reseat the card and confirm the logger is still enabled before touching anything else.

Should short-pulse switches use event-triggered records instead?

Yes, when a switch's shortest pulse is shorter than the interval: an event trigger writes a row when the bit changes state, so the record follows the transitions, and the periodic file keeps giving you the cheap shift-level picture.

Two checks decide whether the event works. Refresh first: the trigger acts on the value as the panel last read it, so a tag refreshed every 2 seconds meets a 45-second pulse about 22 times and cannot miss it, while a tag refreshed every 60 seconds turns the same pulse back into a 45 ÷ 60 = 75% chance per occurrence. Check the tag's update rate in the project before trusting the event; it is the same refresh arithmetic that keeps an HMI trend graph from updating every half second.

Ownership second: the panel only knows what its link delivers, and the PLC saw every pulse all along. A small PLC scans its inputs every 1 to 10 milliseconds, which is thousands of looks at one pulse, so its own event or alarm history is the stronger record for transitions; building that history with stable pointers is its own job, covered in logging PLC alarms to a circular event buffer with separate pointers.

Where the panel software has an event manager or event table, a condition row that watches the bit can fire the log write directly. Run both files side by side: snapshot rows on the period for the shift picture, edge rows for the switches that decide the fault.

Recommendation: Keep the periodic log at 10 minutes for shift-level review, and move any switch whose shortest pulse is shorter than the logging interval onto an event-triggered record, or into the PLC's own event history where the panel cannot trigger on change. Force one transition and confirm each of those rows once before the next incident, because a logger you have never seen produce a row is a plan with a gap in it.

How do you prove the log works before you need it?

Toggle a safe test input, wait one full interval of 10 minutes, and pull the file: a healthy logger shows a new row for the elapsed period, an even spacing of timestamps, and, when the toggle happened to fall inside a sample, your test bit set in that row.

Then run the rest of the checks in order. Spacing: leave the logger through a full day and confirm the timestamps step evenly at the set period. Values: during a known machine state, read a value live on the screen and compare it with its row; a stored row that disagrees with the live value separates a logging fault from a communications fault. Retrieval: open the pulled file in a spreadsheet and archive it with the project version that wrote it. Set the panel's clock before the first test, because every later correlation rests on it, and follow the panel's documented removal step when pulling the card so the final rows are not cut mid-write.

Screen captures fill the gap until the next project download: a capture shows what one screen displayed at one moment, and the next capture overwrites the file unless it is retrieved first. Use that path to bridge a shift, and let the card log take over at the next download.

Questions