Committing an image pool from its own context menu sends the pool entries to SVN but leaves the hidden object that holds the embedded image data behind, so other users update to blank frames. Open the commit dialog from the project root node, select the pool and its hidden image objects, and verify with a clean checkout. The behavior was seen on CODESYS V3.5.7.2 with SVN 4.0.3.0 and is tracked as CDS-46729.
Commit the hidden object, not just the pool. When you insert images into a CODESYS image pool as embedded, the pixel data is stored in a hidden object under the pool, separate from the visible pool object. The commit dialog that opens from the pool's own context menu does not list that hidden object, so the repository receives a pool whose entries carry no data. Other users update and get blank frames while your workstation still renders every picture. The fix is one habit: open the commit dialog from the project root node, where the hidden image objects appear, and commit them together with the pool. The behavior was seen on CODESYS V3.5.7.2 with SVN 4.0.3.0, and CODESYS tracks the gap as CDS-46729.
What is stored where
An image pool is a table of image files, and CODESYS references each image uniquely by its ID and name; the vendor's image pool documentation describes this reference model. Embedding an image imports its pixel data into the project, into a hidden object under the pool. The visible pool object carries the entries: the names, the IDs and the reference to each picture. Two kinds of object, two items the repository needs, and a commit has to carry both.
If you are still deciding where images should live at all, the trade-offs between a file path, an ImagePool and a database are laid out in CODESYS dynamic image display: file, ImagePool or database.
Why the commit dialog leaves the data behind
The SVN commit dialog lists the objects under the node you opened it from. Opened from the pool's context menu, especially when the pool is defined inside the application, the dialog omits the hidden image object. Opened from the project root node, the dialog lists it. A pool-context commit therefore sends a structurally valid but empty pool to the repository, and the next update on another machine reproduces exactly that. Until your build's release notes document a change, the root-node commit is the required path.
Symptoms and what each points to
| What you see | What it points to |
|---|---|
| Blank or missing pictures after an update on another workstation | The hidden image objects never reached the repository |
| Your own workstation shows every picture correctly | The imported data sits in its local working copy, so the fault hides until someone else updates |
| The commit dialog, opened from the pool, lists only the pool object | The dialog's scope at that node stops above the hidden objects |
A path such as C:\...\imagename.png in the image properties |
The import source recorded with the entry; for an embedded image the data still lives in the project |
The path property sends people down the wrong road. The pool does watch the source file: the vendor's image pool object documentation records that CODESYS updates changes to an image file in the pool automatically, and that you must keep the file's path unchanged. That is why the path is stored and shown. For an embedded image it is a record of where the data came from, and rewriting it does nothing to the picture.
Example: two embedded 256 x 256 pixel icons on CODESYS V3.5.7.2
The inputs, and where each comes from:
- One image pool defined inside the application, with 2 embedded images, say a pump icon and a stop icon, each 256 x 256 pixels. The count and pixel size are this scenario's own illustrative inputs; the embedded pool inside an application is the documented setup where the dialog hides the data.
- Each embedded image sits in its own hidden object under the pool, so the pool and its icons make 3 objects in total, and the pool's committed size grows by roughly 200 KB (2 icons x 256 x 256 pixels x 4 bytes per pixel is about 0.5 MB uncompressed; the project stores the imported format).
- CODESYS V3.5.7.2 and SVN 4.0.3.0, the versions this behavior was seen on.
The rule, in words: the commit dialog lists the objects under the node you opened it from, and the hidden image objects appear only when that node is the project root.
The arithmetic. From the pool's context menu the dialog lists 1 object, the pool itself. Pending were 3, so 3 - 1 = 2 objects stay behind, and those 2 hold both icons' pixel data. The commit goes through, the repository now holds a pool with 2 entries and no data, and the first update elsewhere shows 2 blank frames. From the project root node the dialog lists 3 objects; select 3 of 3, commit, and a clean checkout into an empty directory renders 2 of 2 icons, in under 5 minutes on a typical project.
The decision, with its threshold: count the pending objects. A pool change that should carry pictures and lists 1 object where 3 are pending is missing data. Close the dialog and reopen it from the project root. Any commit finished inside the pool's context menu stays incomplete until a clean checkout says otherwise.
The fix: commit from the project root node
- On the workstation that holds the images, save the project and open the image pool. Confirm every entry shows its picture.
- Right-click the project root node, the top entry in the project tree, and open the SVN commit dialog there.
- Find the hidden image objects belonging to the pool in the list. They show as added or modified. Select every one, together with the image pool object itself.
- Write a commit message that names the pool and the images, then commit.
- Reopen the commit dialog from the root node. It should report nothing pending for the pool and its image objects.
Do this even when the pool was committed earlier. The repository already holds the pool shell, so the hidden objects appear as new items on the first root-level commit and fill the empty entries.
Recommendation: commit every image pool from the project root node, on every build, and make a clean checkout the acceptance test for each change to the pictures. Keep images embedded when they belong with the project; link a file only when every workstation already sees it at the same path. Until your CODESYS release notes list a fix for this behavior, treat the root-node commit as the required path.
How to check it worked
Check the project out into an empty working directory on a second machine, or a clean user profile, that has no copy of the source folder at the original C:\... path. Open the project, open the image pool, and confirm every entry shows its picture. Then open each visualization that references pool images and confirm they render. A machine without the original folder removes any chance that a stale file path is masking a missing embed. Run the same test after every later image change, because replacing or re-importing an image modifies the hidden objects again.
Mistakes that bring the problem back
- Committing from the pool's context menu. The dialog hides the hidden objects at that node, so it repeats the fault every time.
- Treating the path property as a link to repair. For an embedded image the path is the recorded import source, so hunting a path problem wastes an afternoon.
- Trusting your own workstation. It holds the images locally and renders correctly whatever the repository contains.
- Partial selection in the root dialog. Taking the pool and skipping its hidden objects reproduces the symptom.
- Mixing linked images in without a plan. A linked image keeps its data outside the project, so every user needs the file at the referenced location; keep such entries embedded unless the file lives on a path the whole team shares.
When to stop and escalate
If the hidden objects do not appear even in the root dialog, or the pictures are still blank after a verified commit and a clean checkout, take the project to CODESYS support. Send your CODESYS build, the SVN integration version, and the reference CDS-46729, so the report lands on the tracked behavior. For the wider setup, choosing between SVN and XML export for a multi-engineer project is covered in CODESYS SVN or XML export for multi-engineer version control, and keeping every project file in one controlled store is covered in control CoDeSys project files in Vault without ENI.
Questions
Is this fixed in newer CODESYS versions?
The gap is tracked as CDS-46729, and device objects already have a mechanism that pulls their hidden counterparts into a commit, which is why device-level data never needs this workaround. Image pools had no such pull-in at the versions where this was seen. Check the release notes of your build for a fix, and until your build documents one, commit image pools from the project root node.
What if the images are linked instead of embedded?
A linked image keeps its pixel data outside the project at the recorded path, so SVN carries none of it and every workstation needs the file. Put linked files where all machines see the same path, such as a network share, and leave that path alone, because the pool picks up changes from the file at that path. Embedded entries avoid all of this.
Does a project with missing pool images still open and run?
Yes. The pool arrives with its entries, IDs and names intact, so the project compiles and the visualization runs with blank frames where the pictures belong. That structural validity is what lets an empty pool pass a commit unnoticed, which is why the check that counts is a checkout into an empty directory on a machine without the source folder.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.