Reload an HMI image from disk without rebooting

Why does the HMI keep showing the old image after I replace the file?

Because the image pool reads its bitmaps once at visualization startup and caches them, so overwriting a file such as c:\test.jpg on the engineering PC changes nothing on screen until the runtime is told to fetch the bitmap again.

An image pool is a table of image files. Every element references an entry by its ID and name, and the runtime materializes those bitmaps when the visualization opens. From that moment the file on disk and the picture on screen are decoupled. A power cycle re-reads the pool, which is why, with no reload trigger in place, your change shows up after a reboot and at no other time.

The element carries a property built for this case. Bitmap Version is the reload trigger: the runtime fetches the bitmap fresh when that value changes. The rule is short: change the version every time you change the image. An increment of 1 is the convention, and it is the only arithmetic in the job.

Which folder does the runtime read the image from?

From the visu folder under PlcLogic on the controller, because that is where the runtime serves visualization files from; the path your project references, such as c:\test.jpg, is a design-time location the running system never visits.

This is the most common miss in the whole job. The engineering tool resolved that path when you built the pool entry; the running system serves its images from /PlcLogic/visu on the target, and that is the only copy the screen can reload.

Open the runtime's file browser and look inside /PlcLogic/visu. If the image is missing there, the element draws a red X where the picture belongs, which is a separate fault. Overwrite the file in that folder under the same file name and extension, and leave the pool entry itself untouched. When references break in other ways after a project move, the repair sequence in HMI image path troubleshooting after migration covers them.

How do I wire the Bitmap Version property as a reload trigger?

Bind one INT variable to the image element's Bitmap Version property and add 1 to it after every file replacement; the runtime fetches the bitmap fresh when that value changes, and that is the entire mechanism.

You need four things: an image element already showing a pool entry, one INT variable, write access to /PlcLogic/visu on the controller, and a way to move a file there. Declare the variable, for example change_img, where your swap logic can write it. An INT in this environment is a 16-bit signed type with an upper limit of 32767, a number that only matters if the counter is never reset.

1. Select the image element. Keep Static ID pointed at the pool entry, for example Imagepool.image1. The ID never changes during a swap.
2. In the same property group, connect Bitmap Version to change_img.
3. Replace the target file in /PlcLogic/visu, same name and extension, using the file browser, FTP, or a USB stick.
4. Write change_img := change_img + 1; from logic or from a button on the screen.
5. The element picks up the new bitmap on its next refresh. A visualization download is for changes to the element itself, so skip it for image swaps.

Why does incrementing the version change nothing on screen?

Because the replacement file never reached /PlcLogic/visu, or the picture you are looking at comes from a browser cache; check the folder first, then the variable write, then the client, in that order.

Work the chain from disk to screen:

• File: in the runtime file browser, the timestamp on the file in /PlcLogic/visu must show your swap time. An older timestamp means the copy landed on the engineering path or failed outright.
• Variable: watch change_img online. A value that sits still means the +1 never executed; the copy and the increment must both run.
• Client: when the file is new and the counter moved, the controller side is done. A web visualization can keep serving a cached copy after a correct swap; force a full page reload, and if that clears it, how a browser cache holds a stale bitmap in a web visualization covers the lasting fix.

Can the PLC copy the file into the visu folder itself?

Yes: call File.Copy from the CAA File library to move the new image into /PlcLogic/visu, then run the same +1 on the version variable, so one routine performs the whole swap with no manual file handling.

Hand-copying is fine for a few swaps a week. When the swap must run unattended, do it in logic:

1. Bring the new image to a place the controller can read, such as a drop folder on a USB stick or a mounted network share.
2. Call File.Copy with the destination string /PlcLogic/visu/sku7.jpg, matching the name the pool entry references.
3. Wait for the copy's done status before touching the counter, so the element always reloads a complete file.
4. Run change_img := change_img + 1; in the same routine, after the copy finishes.

One routine now owns the file and the trigger together, which removes the mismatch described above.

When is a browser element better than the image pool?

When the picture changes every few seconds, for example a camera still or artwork that another system regenerates on its own schedule, point a browser element at the file and let it render straight from disk with no pool and no counter.

A browser element fetches the file, or a URL, on its own refresh interval, so there is no pool entry to manage and no version to bump. The trade: you give up the pool's single table of images referenced by ID, and a browser element brings its own frame and scrollbars unless you size it exactly to the picture.

Use the pool route for pictures that change a few times per shift. Use the browser element when the refresh is measured in seconds or the file is owned by another system. For the timing side of a still frame, the setup in refreshing a camera still image on an operator display applies. Images drawn from a database skip the pool too; check the stored bytes first, as checking database image BLOB integrity before decoding shows. And if the real job is a board for the whole floor instead of an operator screen for one machine, read factory status display or operator HMI before you build further.

What does an example swap look like with real numbers?

Here is one line, three artwork swaps per day, carried from Monday to Friday: 15 file replacements, 15 increments of the version variable, and no reboot at any point.

Scenario: a packing line runs a new label artwork at 08:00, 12:00, and 16:00. The HMI shows the artwork full screen, a 1920 x 1080 JPEG named sku7.jpg served from /PlcLogic/visu. Bitmap Version is bound to change_img, which starts the week at 0.

• 08:00 Monday: the new sku7.jpg overwrites the old one in /PlcLogic/visu. Logic runs change_img := change_img + 1;, the value moves 0 to 1, and the element shows the new artwork on its next refresh.
• 12:00 and 16:00: the same two steps repeat, and the counter ends Monday at 3.
• Friday: 3 swaps per day across 5 days is 15 increments. change_img reads 15, and the screen has shown 15 artworks with no reboot and no visualization download.
• Headroom: the counter wraps at 32767. At 3 swaps per day that is 32767 / 3 = 10922 days of swaps, about 30 years, so no reset logic is needed at this rate.
• A power cycle midweek costs nothing: the pool loads fresh at startup, and the first swap after the restart moves the counter from its init value as usual.

How do I confirm the reload worked?

Watch three points, each one link in the chain: the file timestamp in /PlcLogic/visu, the online value of the version variable, and the picture the client draws, in that order.

1. Timestamp: the file browser shows the swap time on sku7.jpg, for example 16:00 on Friday.
2. Counter: change_img, watched online, holds the value you expect, 15 after the example week.
3. Screen: the element draws the new artwork on its next refresh. A red X points to a missing file in visu. A stale picture with a good timestamp and a moved counter points to a cached copy on the web client.

Recommendation: keep the image pool and the version trigger when the picture changes a few times per shift, and put the copy and the +1 into one PLC routine so the file and the trigger can never drift apart. Move to a browser element pointed at the file when the refresh is measured in seconds or another system owns the file. Save the reboot for downloads and maintenance windows; it has no place in an image swap.

Questions