Three faults can hide a CODESYS instance that moves with a variable x-offset: a wrong tag value, travel that leaves the parent's 3,000 px, and missing scrollbars past one screen. Test them one factor at a time. The offset where the object vanishes, compared with the window and parent widths, names the branch and the fix.
An instance that vanishes as its x-offset grows on a 3,000 px CoDeSys 2.3.5.1 parent, while the same line drawn directly stays put, has three possible faults: the tag driving the offset, the instance's travel across the parent, and the scrollbars that should carry the window past one screen. A standalone line using the same variable clears the first fault, because both objects then read a value that works. This page gives the checks in order, each changing one factor, and the arithmetic that names the branch. The boards themselves are drawn in the visualization editor that ships with the CODESYS environment.
Symptoms and what each points to
Read the four observations before you change anything. Each one points at a different layer, and an object that vanishes only at certain offsets is a different fault from layout content that stays blank from load.
- The instance draws at a small offset and disappears as the offset grows, while a standalone line with the same variable stays visible. Both objects read the same tag, so the tag holds a usable value. The fault sits where the instance lands: its occupied area against the parent's width and against the window.
- The live tag value tracks what you set and the instance still disappears. Placement or navigation. Run the travel check and the scrollbar check.
- The scrollbars are missing once content sits past one screen width. Navigation at the target. The object can be drawn correctly and unreachable, which reads as vanished.
- The standalone line disappears at the same offset as the instance. The travel leaves the parent's area for every object. Fix the geometry once and both come back.
Check the tag while the program runs
Put the offset's value on screen in a text element, the way you would display any PLC value in a visualization, so you read the number the runtime reads. Ramp the offset from 0 px to your maximum in 100 px steps and watch the number at each step. A value that freezes, jumps or stops following your input is a tag fault; fix the code that writes it before touching geometry. To hold it still, write it with a force in the PLC cycle and confirm the object responds to two fixed values, 0 px and your maximum. A tag that never moves at all can also mean the runtime is stopped.
Run this in simulation or with the machine in a safe state, because a variable chosen for a display can be mapped to something that moves.
Add up the travel against the parent
The rule: the instance's base x, plus its maximum offset, plus its own width, must stay at or under the parent's width, 3,000 px in this project. A total past the parent's width puts the instance outside the area the parent can show. Then compare the same total with the window: a panel or simulation window displays one screen width, and anything past it needs the scrollbars to be reachable.
Read three numbers from the running project: the instance's configured x, the width of the one-line visualization it holds, and the largest offset the program writes. Write them down before the next two checks.
Test the scrollbars on their own
Scrollbars in 2.3 belong to the target, in the visualization section of the target settings. Switch them on, set the offset to 0 px, and scroll the bare parent in a 1,024 px window from the left edge to the right edge. The bar should span the full width and the far edge should come into view.
A missing bar makes the rightmost 1,976 px unreachable, the parent width minus 1,024, and any object parked there reads as vanished. Fix the bar first, then retest the instance.
Scenario: a wide parent in a 1,024 px window
A one-line instance visualization 400 px wide sits at base x = 0 px on the parent. The program ramps its x-offset from 0 px to 2,600 px in 100 px steps, and the panel window is 1,024 px wide.
The line disappears at offset 1,100 px. The tag reads 1,100 px, so the value is right. The drawing area runs from 0 + 1,100 = 1,100 px to 1,100 + 400 = 1,500 px, inside the parent. But 1,100 px is past the 1,024 px window, so the line sits off screen with the scrollbar missing. That is the navigation branch. Switch scrollbars on at the target and the line is back, reachable by scrolling to 1,100 px. The closing ramp runs the full 0 to 2,600 px with the line visible or reachable at every step, and 0 + 2,600 + 400 = 3,000 px, exactly the parent's edge.
Now change one number: the ramp goes to 2,800 px and the line vanishes at 2,800 px with a correct tag. Now 0 + 2,800 + 400 = 3,200 px, past the parent. That is the placement branch: cap the offset at 2,600 px, or widen the parent to 3,200 px and extend the scroll range with it.
The fix for each branch
- Tag branch: the displayed value is wrong or frozen. Fix the code that writes the offset and rerun the ramp. The geometry was never at fault.
- Placement branch: the value is right and the total passes the parent width. Cap the offset, widen the parent, or put the travel into the instance's base x so the far end lands inside the parent.
- Navigation branch: the value is right, the total is inside the parent, and the object sits past the window. Switch scrollbars on at the target and confirm the scroll range spans the whole parent.
How to check it worked
Rerun the full ramp with the tag value still displayed on screen. At every 100 px step the line is visible in the window or reachable with the scroll bar, and the number shown matches the step. Scroll end to end, from the left edge to the right.
Then download to the panel and repeat three points on the device: 0 px, the midpoint, the maximum. The panel's window width can differ from the simulation window, and the navigation branch then reappears at a different offset.
The decision for each case
Wrong value, fix the writer. Value right and the total past the parent width, cap the offset or widen the parent. Value right and the total inside the parent, switch the scrollbars on. If the instance still vanishes inside those bounds while a standalone line with the same base x and width survives, record the version, 2.3.5.1, the offset and the coordinates, and hand the project to the vendor's support: the tag, the geometry and the navigation are then all cleared.
Recommendation: Design the travel to fit: base x plus maximum offset plus instance width at or under the parent's width, and scrollbars on at the target whenever the parent is wider than the window. Verify with a 100 px step ramp in simulation before you download to the panel.
Questions
Why does the same line work outside the instance?
Both objects read the same offset variable, so the tag is feeding a usable value. The difference is where each object lands. The instance occupies its base x plus the offset plus its own width, and if your standalone test placed the line nearer the left edge it stays inside the window longer. Give both objects the same base x and the same width, rerun the ramp, and only then blame the instance.
How wide should the parent visualization be?
Set it to the full travel: base x plus maximum offset plus instance width, rounded up to a round number. In the reported project that is 3,000 px. Anything wider only adds empty space the operator must scroll across, and anything narrower puts the far end of the travel outside the area the parent can show. If the travel grows well past one screen, split the board into two visualizations so the scrolling stays short.
Do the scrollbars belong to the visualization or the target?
To the target. In 2.3 you switch them on in the visualization section of the target settings, and one setting covers every visualization in the project, so a project with several wide boards needs it set once. A missing bar makes everything past the window width unreachable, which reads as vanished.
Does the same problem apply to CODESYS 3.x?
The report is specific to 2.3.5.1, and 3.x gives elements their own position properties, so the dialogs differ. The arithmetic carries over to any version: the drawing position, the parent width and the window width decide whether an object can be seen. Run the same three checks and only the setting names change.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.