Alarm Manager - Disk IO Error and Memory Double Free Exception

2026-10-12T09:51:06.285000Z

I have encountered an issue with Alarm management.
A simple Alarm table to display active alarms. Historical alarms can be hidden and can also be cleared. Overall a history of 10000 alarms before it cycles.

On one instance this error displayed:
"Some kind of disk I/O error ocurred. Check disk space". Picture attached.

I have seen this with an online change, but it was resolved by a full download. But this case was running for weeks and displaying alarms fine. The logged errors though were unusual.

Associated log entries (multiples of these were logged):

2026-10-07T12:17:17.603Z, 0x0000001f, 8, 1, 0, #### Exception: Memory double free detected: <cmp>AlarmConfig</cmp> <addr>0x80330d0</addr>

And later in the same day, the entire application encountered an exception:

2026-10-07T19:33:48.583Z, 0x00000011, 8, 81, 3, #### Exception: *EXCEPTION* [<excpt>AccessViolation</excpt>] occurred: App=[<app>Application</app>], T>
2026-10-07T19:33:48.583Z, 0x00000011, 8, 81, 3, #### Exception: *SOURCEPOSITION* App=[<app>Application</app>] area=<area>0</area>, offset=<off>9548256>

I haven't found any explanation for a "Memory double free detected" and I'm unsure how to prevent it occurring. I suspect it might be the cause of the "Access Violation" exception, but how can I be sure of this?

Would defining VISU_NO_EXCEPTION_HANDLING be advisable or not in a production environment?

Any advice is welcome.

How to display only legend description and not variable name

2026-09-24T11:56:04.392000Z

I seem to have missed the "Display variable name" option in the trend recording. This fixed the issue.

How to display only legend description and not variable name

2026-09-24T11:55:07.937000Z

I seem to have missed the "Display variable name" option in the trend recording. This fixed the issue.

How to display only legend description and not variable name

2026-09-23T08:25:23.633000Z

Hello, I have a question regarding the Trend and LegendDisplayer visualization elements. As the provided image suggests, I am trending two variables which show the torque of two motors in terms of % of max load. Below the trend element, is the LegendDisplayer element which correctly displays the name of both trends. But also, it displays the actual variable name in parenthesis, which I do not want. Currently, the name is set by entering a description for each variable in the trend recording settings. But I can't seem to find any option to display only this description. Is it possible to only remove the variable name used in the software?

I'm using CODESYS 3.5.21.50.

Thanks in advance!

How to display only legend description and not variable name

2026-09-23T08:25:21.849000Z

Hello,

I have a question regarding the Trend and LegendDisplayer visualization elements. As the provided image suggests, I am trending two variables which show the torque of two motors in terms of % of max load. Below the trend element, is the LegendDisplayer element which correctly displays the name of both trends. But also, it displays the actual variable name in parenthesis, which I do not want. Currently, the name is set by entering a description for each variable in the trend recording settings. But I can't seem to find any option to display only this description. Is it possible to only remove the variable name used in the software?

I'm using CODESYS 3.5.21.50.

Thanks in advance!

Cartesian XY Chart — 2-D array binding: "Element to use" enumerates the wrong dimension

2026-08-14T07:11:49.685000Z

Title: Cartesian XY Chart — 2-D array binding: "Element to use" enumerates the wrong dimension; documented example (Dialog: XY Chart Configuration, "Two-dimensional array of base type REAL") appears transposed

Product / version: CODESYS Development System V3.5 SP21 Patch 40 (3.5.21.40). Cartesian XY Chart visualization element (System_VisuElemXYChart / VisuElemXYChart).

Summary:
When a curve's Data X/Data Y is bound to a two-dimensional array, the element treats the last array dimension as the per-point record (the one selected by "Element to use") and iterates the first dimension as the sequence of curve points. The online documentation's worked example has the dimensions in the opposite order, so following it produces a non-functional curve and a nonsensical "Element to use" list.

Steps to reproduce (fails — matches the documented layout):
1. Declare aData : ARRAY[0..1, 0..4095] OF LREAL; (2 data sets × 4096 points, i.e. first dimension = set, second = point).
2. In XY Chart Configuration, bind a curve's Data X (and Y) Variable to this array.
3. Observe the "Element to use" combobox.

Actual result: The "Element to use" combobox lists 4096 entries (the indices of the second dimension) instead of 2 (the data sets in the first dimension). Selecting a row does not produce the expected curve; at most a single/degenerate point is plotted.

Steps to reproduce (works — transposed):
1. Declare aData : ARRAY[0..4095, 0..1] OF LREAL; (points first, set second).
2. Bind Data X/Y to this array; "Element to use" now correctly lists [0] and [1].
3. Populate aData[point, set] and the curve plots as expected.

Expected result: Either the documented example should select the data set from the first dimension (as its [1]/[2] "Element to use" implies), or the documentation should state that the last dimension is the record dimension (stride) and the first dimension is the point sequence — consistent with how the element actually behaves.

Analysis:
The behavior is self-consistent if the element always walks a single array by a fixed byte stride, reading one element per point — the same mechanism as the documented "one-dimensional array of a DUT" case, where it strides by SIZEOF(DUT) and "Element to use" picks the member offset. For a 2-D array the record is the last dimension: to plot column/set c it starts at [0, c] and strides by the last-dimension length to reach [1, c], [2, c], … (row-major layout makes this a contiguous column walk). Under that rule, ARRAY[0..N, 0..1] is correct (record length 2 → "Element to use" [0]/[1]), and the documented ARRAY[1..2, 1..50] with "Element to use" [1]/[2] is transposed.

Documentation reference:
Dialog: XY Chart Configuration → Data X / Data Y → "Example: Two-dimensional array of the base type REAL" (ARRAY[1..2, 1..50], Element to use [1]/[2], "100 array values are displayed"). This example does not plot as described in 3.5.21.40; transposing to ARRAY[1..50, 1..2] does.

Request: Please confirm whether this is (a) a documentation error (example dimensions reversed) or (b) an element defect (combobox enumerates the wrong dimension). Either way, a corrected example plus an explicit statement of which dimension is the point sequence vs. the record/stride dimension would prevent others from hitting this. Two separate 1-D arrays for Data X and Data Y work correctly and are unaffected.

WebVisu: switch-frame destroys and rebuilds referenced visualization - is retention configurable?

2026-08-07T17:49:53.701000Z

Hi,

I urgently need some help from you to reach Codesys Support on priority

On CODESYS V3.5 SP22 Patch 2, WebVisu only (no TargetVisu). The client is Chromium 147 in kiosk mode on a Raspberry Pi CM5 panel; the runtime is CODESYS Control Win V3 x64/CODESYS Control RTE V3 x64 on a separate IPC.

I have measured that changing a Frame element's switch-frame variable destroys the currently referenced visualization and fully rebuilds it on return, including all embedded HTML5 controls. We would like to know whether this lifecycle is configurable.

Measurement 1:

Curently, our production page contains a good number of custom HTML5 controls and will only increase , each of which the WebVisu client instantiates as a separate about:srcdoc iframe. I counted live targets via the Chromium remote debugging endpoint (curl http://localhost:9222/json/list) before and after switching.

Production displayed (index 0) 108 iframes
Switched to a light page (index 1) 46 iframes
Switched back to Production 108 iframes

62 controls are destroyed on leaving the page and re-instantiated on return. Observed latency was approximately 2.5 -5s away from the heavy page and approximately 4.0 -5 s back to it.

This was measured with the panel otherwise idle: 2.8% system CPU, 97.1% idle, 2 h 56 min uptime, no remote-desktop session running, hardware acceleration confirmed active in chrome://gpu.

I had previously measured the same behaviour under a much higher CPU load and have since resolved that load separately (VISU_TASK cycle period), so I am confident the rebuild is the frame lifecycle itself and not CPU starvation.

Measurement 2 — frame offset instead of switch index

I then displayed the same overlay page by a different mechanism. Instead of using a switch-frame index, I placed the page in a fixed Frame parked off-screen below the visible canvas, and drive its Y offset from an INT in Structured Text to move it into view.

With this approach the overlay appears immediately, the production page underneath is never torn down and keeps updating, and no visualization is destroyed or rebuilt in either direction. The iframe count does not change at any point. This is the same visualization, containing the same HTML5 controls, as in Measurement 1 — the only difference is how it is brought on screen.

So the rebuild appears to be a property of the switch-frame mechanism specifically, not of the page or its control count.

Questions:

Is the destroy-and-rebuild behavior on switch-frame the intended and documented lifecycle for WebVisu?
Is there any setting, property or client option that causes a referenced visualization to remain instantiated when it is not the active index — the equivalent of keeping it mounted but not displayed?
Does the runtime or client offer any form of caching or pre-instantiation for referenced visualizations, so that a return switch does not pay the full construction cost?
Is the cost specific to HTML5 controls, or would the same rebuild occur with an equivalent number of native visualization elements? We ask because it would inform whether reducing our HTML5 control count is a viable solution.
Is there a recommended pattern for showing a full-screen page over a live production screen without tearing the production screen down?

My current workaround is to keep every page permanently instantiated and move it on and off screen by driving a frame offset variable, which avoids the rebuild entirely but means every page stays live and consumes client resources for the life of the session. This works, but I would prefer to use the supported mechanism if one exists.

Any help on this is greatly appreciated.

Thank you!

HTML5 visualization controls disabled on CODESYS Control for Linux SL - overlay not supported?

2026-08-06T10:54:06.802000Z

I was able to reproduce this by doing something wrong.
I guess what you did is first create an application for the Control Win, or some other device and then switched this to the Linux SL.
But then the Visualization Manager still has the "TargetVisu" component, besides the WebVisu component.
The Linux SL doesn't support this TargetVisu as part of the runtime. You should run a separate process for this.

So remove the TargetVisu from the Visualization Manager and then you will be able to load the application.

HTML5 visualization controls disabled on CODESYS Control for Linux SL - overlay not supported?

2026-08-05T09:41:06.794000Z

Thanks for the suggestion - I updated everything via the CODESYS Installer and restarted, but I'm still hitting the same error.

What I did
- Updated via Tools > CODESYS Installer (had to trigger the update-list refresh manually, it doesn't do this automatically on open)
- Visualization system libraries (VisuElems, VisuElemsAlarm, VisuInputs, VisuNativeControl, etc.): 4.7.0.0 -> 4.10.0.0
- CODESYS Control for Linux SL: 4.15.0.0 -> 4.21.0.0 (based on CODESYS SDK 3.5.22.20)
- Restarted CODESYS Development System

Checked project environment (Project > Project Environment) after restart
- Compiler version: 3.5.22.0
- Library versions: all up to date
- Visualization Profile: CODESYS Visualization 4.10.0.0
- SoftMotion version: 4.20.2.0

Result: compiling with Device = CODESYS Control for Linux SL still fails with the same error:

"Overlay is not supported for your target visualization device."

The custom HTML5 control is still disabled/missing from the Toolbox with this Device selected (same as before), and still appears normally when I switch the Device to a Windows target.

Is there anything else specific I should check (e.g. a setting on the Device description itself, a different SL package/edition, or is WebVisu overlay for custom HTML5 controls simply not implemented yet for CODESYS Control for Linux SL regardless of package version)? Any pointer appreciated.

HTML5 visualization controls disabled on CODESYS Control for Linux SL - overlay not supported?

2026-08-05T08:11:29.033000Z

I would suggest to install the latest visualization and visualization add-ons. Go to Tools - CODESYS installer to updates these add-ons (or just start the CODESYS installer through the Windows start menu).

After installation, restart CODESYS SP22 and update the project to use this new visualization profile (you can update this through the menu Project - Project Environment - Visualization Profile).

Recent posts to Visualization 🇬🇧

Alarm Manager - Disk IO Error and Memory Double Free Exception

How to display only legend description and not variable name

How to display only legend description and not variable name

How to display only legend description and not variable name

How to display only legend description and not variable name

Cartesian XY Chart — 2-D array binding: "Element to use" enumerates the wrong dimension

WebVisu: switch-frame destroys and rebuilds referenced visualization - is retention configurable?

HTML5 visualization controls disabled on CODESYS Control for Linux SL - overlay not supported?

HTML5 visualization controls disabled on CODESYS Control for Linux SL - overlay not supported?

HTML5 visualization controls disabled on CODESYS Control for Linux SL - overlay not supported?