A second capture replaces the first when both events save under one filename. Create one scheduled event per capture time and reserve a filename for each, then verify every file on the stick after a test shift. The event count equals the number of capture times.
Trend screens earn their keep twice: on the panel for the operator, and as a saved image you can show after the fact. The second job fails quietly. You configure one capture that saves the trend to a USB stick under the name typed in the project. The next hour's capture writes over it, because the name never changed. The fix costs nothing: one scheduled event per capture time, each reserving its own filename. This article shows how to build that schedule, works an eight-capture shift as an example, and lists the checks that prove the files are on the stick. Event and storage field names differ between project software packages, so keep your software's manual beside you; the pattern is common to them.
How do I save a trend capture an hour later without losing the first image?
Give each capture its own scheduled event and its own filename. An event at 1:00 saves under Screen Capture 1:00; an event at 2:00 saves under Screen Capture 2:00. A save to a reused name can replace the earlier image on the stick. A capture saves under the filename configured for its event, and the panel does not invent a new name at runtime.
Editing an event's time leaves its filename where it was. Both events then still write to one file, and the earlier image is gone. The documented pattern is one time-of-day event per capture time, and one event covers exactly one capture. Adding a capture means adding an event. Assume no auto-increment of the filename unless your software's manual documents it.
One practical adjustment: the documented example names carry a colon, and Windows rejects a colon in a filename. Type your own names colon-free and carry the time as Capture 0600, Capture 1300, and so on.
What do you need before you configure scheduled captures?
You need four things: the project software for your panel, a USB stick formatted to a file system the panel can write, an event feature that fires at a set time of day, and a written list pairing every capture time with its own filename. The trigger lives in the project software's event or alarm manager.
One documented event logger selects its storage under Storage Medium and switches on with Enable Event logger. Scheduled capture events sit in the same family of settings, and your manual names the exact fields for yours. FAT32 is the usual file system for the stick because panels, Windows and PC tools all read it, and its per-file size limit sits far above any trend capture's size; the manual lists the file systems your panel accepts. Choose a stick you can leave in the panel and pull from after each shift.
How do you create one capture event per time slot?
Build the schedule as a set of events, one per capture time. Each event runs the screen capture action and saves under the filename reserved for that time. The event count equals the number of capture times: eight events for eight captures.
- Write the pair list before opening the project: every capture time on the left, its reserved filename on the right, for example 06:00 with
Capture 0600. - In the event manager, create the first event at the first capture time. Set its action to capture the screen, its destination to the USB stick, and its filename from the pair list.
- Create the next event at the next capture time with the next filename, and repeat until every line of the pair list has an event.
- Audit the event list against the pair list: one event per time, no duplicate filenames, no missing hour.
- Transfer the revised project during planned downtime with the machine in a safe state, following your site's change procedure; this is the one step that touches a running line.
- Run one controlled test: wait for or trigger the first event, then check the stick for the file.
Example: what does a full-shift capture schedule look like?
A shift that needs the trend at the top of every hour from 06:00 through 13:00 inclusive needs eight events. 13 minus 06 is 7 hours between first and last capture, and counting both ends adds one, so 7 plus 1 equals 8 events.
| Capture time | Event | Filename |
|---|---|---|
| 06:00 | 1 | Capture 0600 |
| 07:00 | 2 | Capture 0700 |
| 08:00 | 3 | Capture 0800 |
| 09:00 | 4 | Capture 0900 |
| 10:00 | 5 | Capture 1000 |
| 11:00 | 6 | Capture 1100 |
| 12:00 | 7 | Capture 1200 |
| 13:00 | 8 | Capture 1300 |
Storage is not the constraint. Take 2 MB per capture as a working figure; trend screenshots land between a few hundred kilobytes and a couple of megabytes. Eight captures at 2 MB is 16 MB per shift, and a 2 GB stick holds 2048 / 16 = 128 shifts of captures. Pull the files weekly and the stick never fills. The thing to manage is the event list: one line per capture time, no duplicate names, no missing hour.
How do you check that each capture actually reached the USB stick?
Check the files on the stick in a file browser. A capture that displayed correctly on the panel can still fail to write, and an event configured in the project is not proof that the write happened. Test each event once across a full shift: when its time arrives, open the stick on a PC and confirm the file exists under the reserved name, the image shows the expected trend, and the timestamp matches the event time.
Eight events should leave eight distinct files; seven files with eight events means two events shared a name. Where the files land depends on the software: one documented panel family writes screenshot PNGs into a folder called HMIScreenshot, other software writes to the destination path set in the project, and one test capture tells you the path on yours.
Once the files verify, the same stick workflow serves a notice or status screen on the shop floor, so the images you capture can also feed a display the whole crew sees. Keep the pair list with the project so the next editor spots a duplicate name or a missing hour before the next run.
Why is a capture missing from the USB stick?
Work down four causes in order: the event time, the event's capture action and filename, whether that event is in the project actually running on the panel, and whether the stick was present and writable at that minute. Change one thing, retest, and look at the stick again. Each cause leaves a signature.
No event for that time means no capture by construction, so count the events against the pair list. Two events sharing a name means the later save replaced the earlier file, and eight events with seven files is the tell.
A project that transferred but did not stay on the panel leaves the old event list running; check the panel's project or application screen against the version you transferred, and re-transfer if the running list is older. A stick that was absent or unplugged at the event minute costs that hour, because later events carry their own names and cannot save the missed image afterwards.
When the record needs the values behind the trend and not only the picture, a data logger writes them alongside; your panel's manual documents what a logger can keep and where it writes.
If the captures or logs end up feeding a separate shop-floor display, see how factory screens are mounted and powered, including the power options for a screen run from a low-voltage feed.
Recommendation: Give every capture time its own event and its own filename, count one event per capture time, keep the time-to-filename pair list with the project, and pull the files to a PC after every shift. Reuse one name only when a single capture under that name is all you will ever need.
Questions
Does the panel create a new filename automatically for each capture?
Treat the filename as fixed at design time unless your manual says otherwise. Some project software can build a filename from date or time placeholders; the manual lists the placeholders its name field accepts. A placeholder-based name removes the collision risk without extra events. With no documented placeholders, reserve one name per event.
Do I still need one event per capture at 30-minute intervals?
Yes. The event count equals the number of capture times at any interval. The 8-hour window from 06:00 to 13:00 sampled every 30 minutes contains 16 capture times. It needs 16 events and 16 reserved names, twice the 8 events hourly sampling needs over the same window.
Can the capture files and the data log share one USB stick?
Yes. Put captures and logs in different folders, or on separate sticks if your panel offers more than one storage target. That way clearing one record never deletes the other. Name each folder for the record it holds, and check both folders after a test shift before you rely on the arrangement.
What happens to the missed hour if the stick was unplugged?
That capture is lost. The event fired with nowhere to write, and later events carry their own reserved names, so none can save the missed image afterwards. Seat the stick before the shift starts and treat a missing file as a permanent gap in the record.
Can I log the trend numbers as well as the picture?
Yes, if your panel documents a data logger. It writes tag values to a file such as a CSV log on the storage medium, separate from screen captures. It is the better record when you need to plot or re-check the numbers later. Keep both running and the picture explains the data.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.