An HMI screen icon only fires an event; it saves nothing until the project has an event manager capture action and a storage device the panel recognizes. Aim the capture at CompactFlash or USB storage, then prove the chain with a count test: one deliberate tap must add exactly one image file you can open on a PC.
An icon on an HMI screen can save the displayed screen to a memory card, and one deliberate tap is enough, but only after the project has two pieces in place: an event manager action that captures the screen, and a storage device the panel recognizes. The icon is only the trigger. Leave either piece out and the tap produces nothing you can retrieve later. This page sets both pieces up, then proves the whole chain with a count test: one tap must add exactly one image file you can open on a PC. If your event manager offers no capture action, two other documented routes exist, and the same test applies to both.
What the icon does and what the project needs
The event manager is the part of the project editor that runs actions when a condition is met. Panel makers' documentation lists a typical event manager action set: setting a tag value, copying tag data between tags, changing the screen, capturing a screen, playing a sound file, even sending e-mail. The capture action is the piece that reads the screen and writes the image; a screen icon writes nothing by itself.
The capture has two documented storage destinations: a CompactFlash card or a USB storage device. Which of the two your panel accepts is in the panel's own documentation, and the capture event must be aimed at the device type you actually fit. Icon, event, destination and retrieval path are four separate pieces, and all four have to work before one tap leaves a saved file behind.
What you need
- A project editor whose event manager offers a capture action. Read the action list first; if capture is not on it, plan on one of the two alternative routes below.
- Removable storage the panel supports, CompactFlash or USB, per the panel documentation.
- A touch object for the operator control, with a label that says what it does, such as 'Save screen'.
- A PC with an image viewer for the retrieval check.
- The panel's own status or diagnostic screens, to confirm the storage device is recognized. If the panel has ever failed to see a drive, work through the checks for a USB drive an HMI panel does not recognize before blaming the project.
Set up the capture in the project editor
- Open the event manager and create a new event. Name it for the job, for example 'capture to USB on tap', so it is still findable a year from now.
- Set the event's action to the screen capture. If the action list shows tag writes, screen changes, sounds and e-mail but no capture, stop here: this editor has no capture to configure, and one of the two documented routes below is the path.
- Aim the capture at the storage device the panel actually has, CompactFlash or USB.
- Add a touch object that triggers this event only. Label it 'Save screen' and park it away from process controls, where normal operation cannot fire it by accident. Keep the event off alarm or screen-change triggers unless you want captures at moments nobody chose.
- Download the project to the panel by your site's normal download procedure.
- Confirm recognition on the panel's status or diagnostic display before the first tap. A card seated in the slot is not proof the panel can write to it, and this is the check most often skipped.
Two other documented capture routes
Not every panel family puts the capture in the event manager. Two other routes are documented by their makers. On some panels the screen capture travels through the printer output: you set the output destination of the printer to the memory card, and the capture then lands on the card as image data. On other panels the maker supplies a screenshot utility that runs inside the runtime: you copy it to the USB or SD card, start it from the runtime's startup application list, and it saves the screen as a PNG. Which route exists is decided by the panel family, so read the panel's own help before building anything.
Example: how to check it worked, one tap on a filling-line panel
Case: a filling-line panel, project downloaded, USB storage fitted, capture event configured as in the steps above with its destination set to USB.
Inputs:
- Image files on the USB device before the test: 0. The card was emptied before the download, so the count starts clean.
- Operator control: exactly 1 tap on the 'Save screen' object.
- Retrieval: move the card to a PC, or use the panel's documented retrieval path, and count the image files that actually open.
Rule: the chain is accepted only when one activation changes the number of retrievable images by exactly 1 and the new file opens showing the screen that was displayed at the tap. A fault at any of the four pieces leaves the count standing or the file unreadable, so the count exercises the whole chain in one pass.
Arithmetic: count before, 0 files. 1 tap requests 1 capture. Expected count after: 0 + 1 = 1 file. Tap once more: a panel that keeps every capture gives 1 + 1 = 2 files, which also shows each capture writes its own file. If the second tap leaves the count at 1 with a newer time stamp on that file, the panel overwrites one file, and your standing check becomes the time stamp.
Result: the count moved from 0 to 1 after the first tap, and the file opened showing the batch totals the operator could see on the panel.
Decision and threshold: accept the chain and put the icon in service only at count +1 with a viewable image. Any other outcome fails the test, and the next section gives the order of checks. Repeat the full test after every project change; a repaired icon does not repair a storage problem.
If one tap does not add one file
Let the count result point to the first check:
- Count does not move: the tap happened and nothing reached the card. Check device recognition in the panel diagnostics, then the destination selection inside the capture event, then the event's trigger link to the touch object. The icon's picture and placement are not the cause while the count stands still.
- Count moves but the file will not open: the destination or the image format is wrong. The panel documentation names the format and file naming for your model; confirm them against the viewer on the retrieval PC.
- Files appear somewhere unexpected: panels place and name captures by their own documented scheme. Find that retrieval path before tapping again, or repeated taps will pile up files under names you have not found yet.
If production needs a screen record during the shift and the chain fails, keep the button out of service and use an approved alternate record method for that shift. For a paper record, printing an HMI screen capture from the USB drive covers the print side.
Keep the card from filling
Each capture writes a file, and the two-tap check in the example shows whether the panel keeps every file or overwrites one. Decide retention before hand-over: who archives captures, who clears the card, and how often. The routine for clearing HMI USB log storage from the panel, with the archive step first fits capture files the same way it fits log files. How much card space one capture takes depends on the image size and format your model writes; the panel documentation lists both, so size the retention to the card you fitted.
Hand it over on a passing test
Recommendation: put the capture icon in service only after the count test passes on the real panel, meaning one tap raises the retrievable-file count by exactly 1 and the image opens on the retrieval PC showing the captured screen. If the event manager has no capture action, build one of the two documented routes and apply the same test before hand-over. Repeat the full test after every project edit, and pair the button with a written retention rule so the card cannot fill unnoticed.
Questions
Can the capture run on an alarm instead of a button?
Usually yes. Event managers exist to run actions on conditions such as alarms, so a capture action tied to an alarm event records the screen without any tap. Prove it the same way before relying on it: force or wait for the condition once, and confirm the retrievable-file count rises by exactly 1 with a viewable image. The capture lands when the condition fires, which can be a different screen than the one people look at afterwards, so test on the screen that matters.
Where should the Save screen icon go?
On each screen an operator would genuinely want to record, placed away from process controls so a normal reach cannot fire it. Many projects repeat the same touch object on several screens and point every copy at the one capture event, so the event is maintained once and only the object is copied. Keep the label explicit, such as 'Save screen', so nobody treats it as a page-change button.
What file format and name does the capture get?
That depends on the panel model and editor version, and the panel documentation is the source for both; one documented route writes PNG, another writes image data through the printer destination, so check your own help before promising anyone a file type. The count test is independent of the format: it only asks that the file count rises by exactly 1 and that the image opens on the PC you will actually use for retrieval.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.