Post by thomas-k on SysTimeRtcHighResGet --> Millisekunden mit Zeitzone verrechnet ^{CODESYS Forge talk (Post)}
SysTimeRtc.SysTimeRtcHighResGet(pTimestamp := lstActualIPCUnixTime_ms); SysTimeRtc. SysTimeRtcConvertHighResToLocal(lstActualIPCUnixTime_ms,lstActualIPCUnixTimeLocal_ms); SysTimeRtc.SysTimeRtcConvertLocalToHighRes(lstActualIPCUnixTimeLocal_ms,lstActualTime_ms); F30_SysTimeRtcHighResGetLocal:= TO_ULINT(lstActualTime_ms); Dies hat immer die selbe Zeit in UTC. Wie bekomme ich eine HIGHRes Zeit in Millisekunden. Und diese Zeit nicht in UTC sondern mit der Zeitzone verrechnet..... Und reicht es die Zeitzone mit "SysTimeRtcSetTimezone" zu setzen oder muss die Zeitzone im Linux (PC) gesetzt werden ?
Last updated: 2026-07-31

SysTimeRtcHighResGet --> Millisekunden mit Zeitzone verrechnet ^{CODESYS Forge talk (Thread)}
SysTimeRtcHighResGet --> Millisekunden mit Zeitzone verrechnet
Last updated: 2026-07-31

OPC UA PubSub SL 1.3 — UADP WriterGroup with assigned PSS.SecurityGroup still publishes plaintext ^{CODESYS Forge talk (Thread)}
OPC UA PubSub SL 1.3 — UADP WriterGroup with assigned PSS.SecurityGroup still publishes plaintext
Last updated: 6 days ago

Post by lzml on HTML5 visualization controls disabled on CODESYS Control for Linux SL - overlay not supported? ^{CODESYS Forge talk (Post)}
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 - 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.
Last updated: 6 days ago

Post by timvh on HTML5 visualization controls disabled on CODESYS Control for Linux SL - overlay not supported? ^{CODESYS Forge talk (Post)}
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).
Last updated: 6 days ago

Post by timvh on HTML5 visualization controls disabled on CODESYS Control for Linux SL - overlay not supported? ^{CODESYS Forge talk (Post)}
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.
Last updated: 5 days ago

Post by dmb-fan on Hilscher cards CoDeSys Control RTE ^{CODESYS Forge talk (Post)}
Sounds good. Thx
Last updated: 5 days ago

HTML5 visualization controls disabled on CODESYS Control for Linux SL - overlay not supported? ^{CODESYS Forge talk (Thread)}
HTML5 visualization controls disabled on CODESYS Control for Linux SL - overlay not supported?
Last updated: 5 days ago

Post by timvh on Hilscher cards CoDeSys Control RTE ^{CODESYS Forge talk (Post)}
Completely managed by CODESYS, including licenses. You specifically have to set the parameters correctly in the CODESYSControl.cfg to let the RTE have access to the cards. See: https://content.helpme-codesys.com/en/CODESYS%20Control/_rtsl_windows_rte_v3_startup_cifx_hil.html
Last updated: 5 days ago

Post by thejesh on WebVisu: switch-frame destroys and rebuilds referenced visualization - is retention configurable? ^{CODESYS Forge talk (Post)}
Hi, HTML5 Conrtrol elements 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!
Last updated: 3 days ago

Visualization 🇬🇧 ^{CODESYS Forge talk (Discussion)}
Realizing operator screens with CODESYS HMI, Targetvisu, Webvisu
Last updated: 3 days ago

WebVisu: switch-frame destroys and rebuilds referenced visualization - is retention configurable? ^{CODESYS Forge talk (Thread)}
WebVisu: switch-frame destroys and rebuilds referenced visualization - is retention configurable?
Last updated: 3 days ago

Engineering 🇬🇧 ^{CODESYS Forge talk (Discussion)}
Discussions about the CODESYS Development System, IEC programming, CODESYS Professional Developer Edition
Last updated: 10 hours ago

Post by eschwellinger on CODESYS Control for Raspberry Pi 5 - "Hardware version or firmware version not supported" on Rev 1.1, persists across multiple runtime versions and OS images ^{CODESYS Forge talk (Post)}
you need to wait for the 4.22.0.0 release which will fix this problem
Last updated: 3 hours ago

Hilscher cards CoDeSys Control RTE ^{CODESYS Forge talk (Thread)}
Hilscher cards CoDeSys Control RTE
Last updated: 3 hours ago

CODESYS Control for Raspberry Pi 5 - "Hardware version or firmware version not supported" on Rev 1.1, persists across multiple runtime versions and OS images ^{CODESYS Forge talk (Thread)}
CODESYS Control for Raspberry Pi 5 - "Hardware version or firmware version not supported" on Rev 1.1, persists across multiple runtime versions and OS images
Last updated: 3 hours ago

Runtime 🇬🇧 ^{CODESYS Forge talk (Discussion)}
Related questions to SoftPLCs e.g. Raspberry Pi, Beaglebone, IoT2000 and other platforms
Last updated: 3 hours ago

Post by axberry on CODESYS Control for Raspberry Pi 5 - "Hardware version or firmware version not supported" on Rev 1.1, persists across multiple runtime versions and OS images ^{CODESYS Forge talk (Post)}
when is the releaseof the 4.2.0.0
Last updated: 3 hours ago

Sort by relevance or date