Post by paro on Modbus Client Request Not Processed ^{CODESYS Forge talk (Post)}
Hi, works in my case if I increase the timeout! to_udint(t#100ms) -> 100 -> 100us.. FUNCTION_BLOCK MODBUS_master_example_ST VAR initDone : BOOL := FALSE; aIPAddress : ARRAY [0..3] OF BYTE := [127,0,0,1]; clientTcp: ModbusFB.ClientTcp; // buffer to read input registers aDataInputRegisters : ARRAY[0..9] OF UINT; // some client requests clientRequestReadInputRegisters: ModbusFB.ClientRequestReadInputRegisters; xExecute: BOOL; uistart: UINT := 100; udiTimeout1: UDINT; END_VAR IF NOT initDone THEN initDone := TRUE; // configure clientTcp clientTcp(aIPaddr:=aIPAddress, uiPort:=502, udiLogOptions := ModbusFB.LoggingOptions.All); // configure clientRequestReadInputRegisters clientRequestReadInputRegisters(rClient:=clientTcp, uiUnitId:=1, udiTimeout:=1000000); // 1sec END_IF // call the client FB's clientTcp(); clientRequestReadInputRegisters(rClient:=clientTcp,xExecute := xExecute AND NOT clientRequestReadInputRegisters.xBusy ,uiStartItem:=uistart, uiQuantity:=3, pData:=ADR(aDataInputRegisters[0]));
Last updated: 2024-05-30

Post by zer0g on Modbus Client Request Not Processed ^{CODESYS Forge talk (Post)}
I'm using the code bellow which is based on the Codesys example: FUNCTION_BLOCK MODBUS_master_example_ST VAR initDone : BOOL := FALSE; aIPAddress : ARRAY [0..3] OF BYTE := [127,0,0,1]; clientTcp: ModbusFB.ClientTcp; // buffer to read input registers aDataInputRegisters : ARRAY[0..9] OF UINT; // some client requests clientRequestReadInputRegisters: ModbusFB.ClientRequestReadInputRegisters; xExecute: BOOL; END_VAR IF NOT initDone THEN initDone := TRUE; // configure clientTcp clientTcp(aIPaddr:=aIPAddress, uiPort:=502, udiLogOptions := ModbusFB.LoggingOptions.All); // configure clientRequestReadInputRegisters clientRequestReadInputRegisters(rClient:=clientTcp, uiUnitId:=1, udiTimeout:=TO_UDINT(T#1000MS)); END_IF // call the client FB's clientTcp(); clientRequestReadInputRegisters(rClient:=clientTcp,xExecute := xExecute AND NOT clientRequestReadInputRegisters.xBusy ,uiStartItem:=2, uiQuantity:=3, pData:=ADR(aDataInputRegisters[0])); As you can see the clientTCP is called cyclically with the same result.
Last updated: 2024-05-30

Post by gatto on Modbus tcp - channel ^{CODESYS Forge talk (Post)}
Hi can you give more details? Are you talking about a danfoss? wich model? Can post the configuration of channel' I used, on the past, serial modbus with danfoss fc280 I remember ((id x 10)-1) I remember that you couldn't use continuous reading/writing of the directors but you had to use them one at a time. it seemed that reading empty registers (caused by x10) was not accepted by danfoss. So I had created a scan that used just one register, then the next etc etc with a timed interval. But this was for the serial, I don't know if it's the same thing with ethernet. I currently use Ethernet TCP/IP interface with FC280.
Last updated: 2024-06-13

Post by timothyzalusky on Strange Behavior on Raspberry Pi ^{CODESYS Forge talk (Post)}
Hello, I am seeing some weird runtime behavior related to the EQ function on a rapsberry pi based system. I have attached a screenshot showing the strange latching I am seeing on the EQ function, and I have not seen this behavior before. I tried freshly restarting the runtime and it has this same behavior. Anyone seen this? I am on 3.5.20 with the latest runtime installed. Basically, as soon as it hits one of those EQ's in the program, it latches effectively locking the output on. Any input from the Codesys team would be appreciated as well as anyone that might know what I am seeing.
Last updated: 2024-06-18

Post by jasperclauwaert on Persistent Retain Variables Not Visible in Online View (WAGO PFC100 + CODESYS) ^{CODESYS Forge talk (Post)}
Hi everyone, I’m working on a WAGO PFC100 with CODESYS. During development everything worked fine, but in the final stage I set several variables to PERSISTENT RETAIN. When I go online, most of these persistent variables cannot be monitored. Instead, I see: <Value of the expression cannot be retrieved> Interestingly, a few variables do show their values correctly, but the majority do not. The variables are not used as pointers or in any unusual way. The application compiles and runs without errors. Has anyone experienced this before? Is this a known issue with PFC100 or CODESYS? Any ideas on what could cause this behavior? Thanks in advance! Jasper
Last updated: 2025-10-23

Post by jasperclauwaert on Persistent Retain Variables Not Visible in Online View (WAGO PFC100 + CODESYS) ^{CODESYS Forge talk (Post)}
Hi everyone, I’m working on a WAGO PFC100 with CODESYS. During development everything worked fine, but in the final stage I set several variables to PERSISTENT RETAIN. When I go online, most of these persistent variables cannot be monitored. Instead, I see: <Value of the expression cannot be retrieved> Interestingly, a few variables do show their values correctly, but the majority do not. The variables are not used as pointers or in any unusual way. The application compiles and runs without errors. Has anyone experienced this before? Is this a known issue with PFC100 or CODESYS? Any ideas on what could cause this behavior? Thanks in advance! Jasper
Last updated: 2025-10-23

Post by davidbo on RETAIN PERSISTENT only stored at gracefully shutdown? ^{CODESYS Forge talk (Post)}
I have {attribute 'checksumnoinit_override' := '2629838988'} {attribute 'init_related_code' := '5c6efcf8-e0f4-4166-a9fa-17eadd8908df'} VAR_GLOBAL RETAIN PERSISTENT {attribute 'order_in_persistent_editor' := '0'} segmentValue: ARRAY[0..49] OF REAL; {attribute 'order_in_persistent_editor' := '1'} segmentTime: ARRAY[0..49] OF REAL; // Generated instance path of persistent variable PRG.test: INT; // Generated instance path of persistent variable PRG.nw_storage: SysSocket_Implementation.SysSocket_Interfaces.SOCK_ADAPTER_INFORMATION2; END_VAR When I have changed PRG.nw_storage it will not be stored at a power off, but if I do a: sudo systemctl restart codesycontrol and then a power off it will be stored. Is there a way to store persistent variables without a restart of codesyscontrol? Can anyone explain how and when CODESYS store persistent variables?
Last updated: 2025-11-17

Post by imdatatas on Error: C0138: No matching 'FB_Init' method found for instantiation of VisuClientObjectMgr ^{CODESYS Forge talk (Post)}
Unfortunately, the "C0138: No matching 'FB_Init" method found" error is a nightmare for CODESYS V3.5 SP21. I'm not sure if anything has been done about this or if anything will be fixed. I've encountered the same issue many times, and it was only resolved by completely uninstalling SP21, deleting all related files and folders from my computer, and then installing SP19. So, I've given up on using SP21 and switched back to SP19patch7. Here are some previous posts regarding the "C0138: No matching 'FB_Init" on SP21 of Codesys. https://forge.codesys.com/forge/talk/Visualization/thread/0763d6ca8e/ https://forge.codesys.com/forge/talk/Motion/thread/9074005bf4/
Last updated: 2025-11-28

Post by jbcregen on Accessing parameters from a structure or function block with the web interface ^{CODESYS Forge talk (Post)}
I have a project with hundreds of OPC-UA variables available on the network. A lot of these variables are used actively in various scripts that run in background in the OS (Linux). I'm experimenting with Automation Server and I have a hard time understanding how the web interface populates its parameters list for a given PLC (<plc details="" parameters="" for="" plc="" 'xyz'="">).</plc> In this page, it looks like the only variables available are the ones that are of a "base" type : bool, TIME, String, INT, etc. All the variables that are nested into function blocks or structures are not available in the web interface, even if they are available to any OPC-UA client. Is this a limitation of the Automation Server or is there something that can be done in Codesys?
Last updated: 2025-12-01

Post by remlab on WebClient result empty ^{CODESYS Forge talk (Post)}
Hello, I try to read into a IPX800v4 (this is a PLC for domotic application) with a WebClient fonction I use as url http://192.168.0.250:50543/api/xdevices.json?key=XXX&Get=C XXX is replace by the correct key for sure The status code is 200, it should works correctly But the result is '{' that's my problem When I try the same url with a web browser the result is correct like { "product": "IPX800_V4", "status": "Success", "C1": 16, "C2": 2, "C3": 0, "C4": 0, "C5": 0, "C6": 0, "C7": 0, "C8": 0, "C9": 0, "C10": 0, "C11": 0, "C12": 0, "C13": 0, "C14": 0, "C15": 0, "C16": 0 } When i replace the url by a web site like google for exemple it works Can you help me please ?
Last updated: 2026-03-04

Post by arwie on Frustration-Fueled Feedback on Project File Management and Git Integration ^{CODESYS Forge talk (Post)}
An other approach is to split the application into a hard real-time part running in CODESYS and the business logic running in Python asyncio. The business logic part is usually bigger and changes more often. As Python code is pure text, vscode and git are your friends. A performance example on YouTube (CODESYS SoftMotion + Python): https://www.youtube.com/watch?v=BT-L0H_4Aic Docs and code on GitHub: https://github.com/arwie/controlOS_demo/blob/main/docs/codesys_python_link.md Real-time variable exchange between a CODESYS application and a Python application running in parallel, using POSIX shared memory.
Last updated: 2026-06-21

Post by winki on Error in licence activation ^{CODESYS Forge talk (Post)}
Hello, I think I understand: On my debian gateway I have done: sudo cmu --list cmu - CodeMeter Universal Support Tool. Version 8.30a of 2025-May-06 (Build 6885) for Linux/ARMHF 64-Bit Copyright (C) 2007-2025 by WIBU-SYSTEMS AG. All rights reserved. List all locally connected CmContainers: - CmContainer with Serial Number 130-XXXXXXXX and version 3.00 (empty) - CmContainer with Serial Number 130-XXXXXXXX and version 3.00 (locked) Result: 2 CmContainer(s) listed. The licence has been activated with a computer Name, but the guy who did it make a mistake in the name, so he changed it after to have activate the licence. I think this has created a second container. The licence is actived on the other container.
Last updated: 2026-02-06

Post by thierry-b on CODESYS device discovery performance in large networks (/16) ^{CODESYS Forge talk (Post)}
Hello, We are using CODESYS 3.5 SP19.70 in an educational environment with several WAGO PFC200 controllers (CODESYS Runtime). Our campus network is currently configured as a /16, which creates a very large broadcast domain. We observe slow device discovery and long scan times when opening the network view. Before restructuring our architecture, we would like to know the recommended network practices for CODESYS: Recommended broadcast domain size for device discovery Possible impact of large networks (/16) on scan performance Usual recommendations (VLANs, /24 segmentation, etc.) Known limitations or points of attention in extended networks Any guidance or official recommendations would be very helpful. Thank you.
Last updated: 2026-03-29

Post by husarz17 on How change Unity-ID in TCP Modbus Slave ^{CODESYS Forge talk (Post)}
My codesys is 3.5.21.30. I am using function ModbusServer from library ModbusTCP_Slave. The reason is that I need share 9000 Holding registers. By standard configuration it is only 4096. fbMbTcpDevice: ModbusTCP_Slave.ModbusServer; fbMbTcpDevice( wPort := 502, pInputData := ADR(awInputReg), pOutputData := ADR(awHoldingReg), uiInputDataSize := 10, uiOutputDataSize := 9000, xEnable := TRUE, tTimeout := 10000, InterfaceName := "eth0", xBusy => xBusy, xError => xError, byClientConnections => byConnections ); Ethernet port is cofigured: Network interface: eth0 IP address: 10.10.22.55 Subnet maskL 255.255.255.0 Default gateway: 0.0.0.0 And it only works when I am reading registers with ID 255 by Modbus Poll. Any other IDs don't work. The actual TCP client device try to read registers with ID 1 and I can't change it... Thanks in advance for your help!
Last updated: 2026-04-01

Post by jebu on OPC UA method calls ^{CODESYS Forge talk (Post)}
I'm setting up an OPC UA server in CODESYS. My understanding so far: Calling methods over OPC UA requires an Information Model — the plain Symbol Set / Symbol Configuration alone doesn't support method calls. Is that correct, or is there a way around it? With an Information Model, the Node IDs are auto-generated and I can't set them manually. Assuming that's right: -Are these generated Node IDs stable across builds/downloads, or can they change? -If they can change, what triggers it — renaming a variable/method, reordering objects in the model, a rebuild, a re-download to the PLC?
Last updated: 2026-09-23

Post by dmb-fan on Hilscher cards CoDeSys Control RTE ^{CODESYS Forge talk (Post)}
Now it sounds not so good anymore... I don't get it. The help-site is a joke. Is there anywhere manuals or docs? Or maybe somebody show me a working CODESYSControl.cfg with CIFX50E-DP and CIFX50E-CO ? Are there 1 or 2 entry for componentnes in the gui? Is slot no. this no. in the gui or any other number? What is the Device-No. ? When I tried Win hang, or PLC hang. Log not writing or not telling me the problem. Is 2026 and for this basic things I have to do trial and error?
Last updated: 2026-10-20

Post by jeindhoven on Deploying to raspberry pi 5 hangs ^{CODESYS Forge talk (Post)}
Yep sure, though now that i think of it, its a pi 4. My bad. The whole ordeal was necessary to use the VGA666 adapter. That needs the old graphical system and GPIO directly on the CPU. Edit: Putty on the virtual development machine connects fine. But i did change the login/pw. The account is still a sudo'er so that should be all right. Edit2: Sorry i get a "Comment rate limit exceeded" from the forum. Then i'll add it as edit here. So i have tried the stock raspberry pi image on a different pi5 (truly 5 this time). Packages updated. Standard password. Same symptoms, no runtime deployed and long hang time. Versions of this pi: pi@raspberrypi:~ $ uname -a Linux raspberrypi 6.12.25+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.12.25-1+rpt1 (2025-04-30) aarch64 GNU/Linux pi@raspberrypi:~ $ lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 12 (bookworm) Release: 12 Codename: bookworm pi@raspberrypi:~ $ apt list --installed | grep openssh-server openssh-server/stable,now 1:9.2p1-2+deb12u6 arm64 [installed,automatic] Attached is the Device information and error text that Codesys comes up with. Edit 3 (Comment rate limit, otherwise it would be a new post) Now i have tried booting an older native Windows 10 machine (no virtualization), and it just works as expected. I have now a raspberry pi 4 and raspberry pi 5 with version 4.16.0.0 of the control application. Windows 10 native: build 19045 (same as virtualised Win 10), same .NET version, same CODESYS version. It seems that running CODESYS virtualized somehow messes with the deployment?
Last updated: 2025-06-23

Post by rajatdas2005 on Codesys Virtual control SL ^{CODESYS Forge talk (Post)}
Dear All, This is regarding Codesys Virtual control SL demo version. I am facing one issue. First I will describe the steps what I have followed till now. 1. In a PC I have Windows OS. Here Codesys IDE is installed, and also using the installer option of IDE I have also installed Codesys Virtual control SL. 2. A edge-gateway is also running in the same windows PC as local host. 3. Next I have a seperate PC with Ubuntu OS with docker installed. This machine is in the same network. 4. Now I have created a project in Windows machine using device "Codesys Virtual control SL". 5. In the Ubuntu machine I am running the Codesys Virtual control SL as docker and it is using the ubuntu machine network only. 6. Next using the localhost edge-gateway when I am searching the virtual control SL docker it is able to detect it. (screenshot attached) 7. But after creating the creadentials it is telling No Device is responding. 8. I have also checked the wireshark logs and able to see that in destination port 11740 data is coming. 9. From windows PC telnet ip 11740 is also working. 10. Ping is also working ===========================================LOGS ========================= sudo ss -tlnp | grep -E "(443|1217|4840|8080|11740)" LISTEN 0 10 10.135.114.142:4840 0.0.0.0: users:(("codesyscontrol.",pid=41864,fd=21)) LISTEN 0 10 172.18.0.1:4840 0.0.0.0: users:(("codesyscontrol.",pid=41864,fd=24)) LISTEN 0 10 172.17.0.1:4840 0.0.0.0: users:(("codesyscontrol.",pid=41864,fd=23)) LISTEN 0 10 127.0.0.1:4840 0.0.0.0: users:(("codesyscontrol.",pid=41864,fd=26)) LISTEN 0 10 192.168.122.1:4840 0.0.0.0: users:(("codesyscontrol.",pid=41864,fd=22)) LISTEN 0 5 0.0.0.0:11740 0.0.0.0: users:(("codesyscontrol.",pid=41864,fd=20)) LISTEN 0 128 0.0.0.0:8080 0.0.0.0: users:(("python3",pid=1280,fd=4)) LISTEN 0 10 172.19.0.1:4840 0.0.0.0: users:(("codesyscontrol.",pid=41864,fd=25))
Last updated: 2025-08-06

Post by superjojo2002 on Licensing info not available. ^{CODESYS Forge talk (Post)}
I updated the docker container runtime to version 4.11.0.0. and build the container with this "Dockerfile" FROM arm64v8/debian:11.6 RUN apt-get update RUN apt-get install -y wget sudo unzip libusb-1.0-0-dev procps ENV CDS_VERSION "4.11.0.0" ENV EDGE_VERSION "4.11.0.0" ENV URL "https://store-archive.codesys.com/ftp_download/3S/LinuxARM64/2302000039/$CDS_VERSION/CODESYS%20Control%20for%20Linux%20ARM64%20SL%20$CDS_VERSION.package" ENV EDGE_URL "https://store-archive.codesys.com/ftp_download/3S/EdgeGatewayLinux/000120/$EDGE_VERSION/CODESYS%20Edge%20Gateway%20for%20Linux%20$EDGE_VERSION.package" RUN wget --output-document=/tmp/codesys.package $URL && \ unzip -p /tmp/codesys.package '*codemeter*.deb' > /tmp/codemeter.deb && dpkg -i /tmp/codemeter.deb && \ unzip -p /tmp/codesys.package '*codesyscontrol*.deb' > /tmp/codesys.deb && dpkg -i /tmp/codesys.deb RUN wget --output-document=/tmp/edge.package $EDGE_URL && \ unzip -p /tmp/edge.package '*arm64.deb' > /tmp/edge.deb && dpkg -i /tmp/edge.deb EXPOSE 11740 1217 11743 ENTRYPOINT ["/bin/sh", "-c" , "/etc/init.d/codemeter start && /etc/init.d/codemeter-webadmin start && /etc/init.d/codesyscontrol start && /etc/init.d/codesysedge start && tail -f /dev/null"] Now cmu -x" returns root@sensoredge-field-netfield-produktmanagment:/# cmu -x cmu - CodeMeter Universal Support Tool. Version 8.00 of 2023-Nov-28 (Build 5967) for Linux/ARMHF 64-Bit Copyright (C) 2007-2023 by WIBU-SYSTEMS AG. All rights reserved. But still CODESYS development system reports that it needs a dongle and when I click install that "value cannot be null. Parameter name: containerToLicenses" It seems that Codemeter is forced to look for a dongle instead of a CMsoftcontainer. Can you confirm that CODESYS licensing works also when CODESYS is installed in a Docker container?
Last updated: 2024-03-21

Post by mariussandu on OPC-UA ^{CODESYS Forge talk (Post)}
Hello, I am experiencing an intermittent OPC UA server issue on CODESYS Control for Raspberry Pi SL 4.21.0.0. Runtime information: codesyscontrol 4.21.0.0 Raspberry Pi 4 Model B Rev 1.1 - 4Gb OPC UA Server: CmpOPCUAServer 3.5.22.x Server IP: 192.168.0.110 OPC UA endpoint: opc.tcp://192.168.0.110:4840 The main OPC UA client is Node-RED running on 192.168.0.111. This has an active subscription with some tags and also some write functions active. The system normally works correctly for a period, but at some time the OPC UA communication stopped. Node-RED started reconnecting continuously but could not reconnect. I also tried connecting using UaExpert, but UaExpert returned: BadTimeout At the same time, the PLC application itself was still running. Before restarting CODESYS, I captured the TCP connections. The OPC UA server was still listening: tcp 11 0 192.168.0.110:4840 0.0.0.0:* LISTEN However, there were many connections from the Node-RED client stuck in CLOSE_WAIT: 192.168.0.110:4840 192.168.0.111:45008 CLOSE_WAIT 192.168.0.110:4840 192.168.0.111:53678 CLOSE_WAIT 192.168.0.110:4840 192.168.0.111:44032 CLOSE_WAIT 192.168.0.110:4840 192.168.0.111:36612 CLOSE_WAIT 192.168.0.110:4840 192.168.0.111:45012 CLOSE_WAIT 192.168.0.110:4840 192.168.0.111:36592 CLOSE_WAIT ... Some of these sockets also had data remaining in Recv-Q, for example: Recv-Q = 61 Recv-Q = 121 There were roughly 15–20 OPC UA connections in CLOSE_WAIT. Restarting only the CODESYS runtime immediately restored OPC UA communication. After restart: LISTEN 0 10 192.168.0.110:4840 and both Node-RED and UaExpert can connect normally again. There are no obvious OPC UA errors during startup or in log. On RPI 2 I had a memory leak regarding OPCUA so I had to upgrade to RPI4. What can I do in this case? Thank you!
Last updated: 2026-08-26

Post by denizerm on Deploy Control SL cant find Podman ^{CODESYS Forge talk (Post)}
Hello, CODESYS seems to have problems finding the container engine. In the "Deploy Control SL" window, after connecting via ssh, it simply says: [INFORMATION] Connected successfully! [INFORMATION] Successfully connected to target (192.168.4.199) [WARNING] Error detecting container architecture running podman info yields normal results. My podman info output is as follows: home/Admin$ podman info host: arch: amd64 buildahVersion: 1.35.3 cgroupControllers: - cpu - memory - pids cgroupManager: systemd cgroupVersion: v2 conmon: package: Unknown path: /usr/bin/conmon version: 'conmon version 2.1.10, commit: affab49967eb62f75d2a47398344ab053326289f' cpuUtilization: idlePercent: 99.36 systemPercent: 0.3 userPercent: 0.34 cpus: 4 databaseBackend: sqlite distribution: codename: scarthgap distribution: redagv version: 1.0.0 eventLogger: journald freeLocks: 2040 hostname: secure-automation-os idMappings: gidmap: - container_id: 0 host_id: 1000 size: 1 - container_id: 1 host_id: 100000 size: 65536 uidmap: - container_id: 0 host_id: 1100 size: 1 - container_id: 1 host_id: 100000 size: 65536 kernel: 6.6.65-intel-pk-standard linkmode: dynamic logDriver: journald memFree: 6115598336 memTotal: 8086278144 networkBackend: cni networkBackendInfo: backend: cni dns: {} ociRuntime: name: crun package: Unknown path: /usr/bin/crun version: |- crun version 1.14.3.0.0.0.8-89d44-dirty commit: 89d44467e3b410b73f2065756a12789be45b855b rundir: /run/user/1100/crun spec: 1.0.0 +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL os: linux pasta: executable: /usr/bin/pasta package: Unknown version: "" remoteSocket: exists: true path: /run/podman-shared/podman.sock security: apparmorEnabled: false capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT rootless: true seccompEnabled: true seccompProfilePath: "" selinuxEnabled: false serviceIsRemote: true slirp4netns: executable: /usr/bin/slirp4netns package: Unknown version: |- slirp4netns version 1.2.0-beta.0+dev commit: unknown libslirp: 4.7.0 SLIRP_CONFIG_VERSION_MAX: 4 libseccomp: 2.5.5 swapFree: 0 swapTotal: 0 uptime: 1h 36m 10.00s (Approximately 0.04 days) variant: "" plugins: authorization: null log: - k8s-file - none - passthrough - journald network: - bridge - macvlan - ipvlan volume: - local registries: localhost:5000: Blocked: false Insecure: true Location: localhost:5000 MirrorByDigestOnly: false Mirrors: null Prefix: localhost:5000 PullFromMirror: "" search: - localhost store: configFile: /home/serviceuser/.config/containers/storage.conf containerStore: number: 2 paused: 0 running: 2 stopped: 0 graphDriverName: overlay graphOptions: {} graphRoot: /data/containerfiles graphRootAllocated: 119952025600 graphRootUsed: 13801246720 graphStatus: Backing Filesystem: extfs Native Overlay Diff: "true" Supports d_type: "true" Supports shifting: "false" Supports volatile: "true" Using metacopy: "false" imageCopyTmpDir: /var/tmp imageStore: number: 4 runRoot: /run/user/1100/containers transientStore: false volumePath: /data/containerfiles/volumes version: APIVersion: 5.0.2-dev Built: 1711987427 BuiltTime: Mon Apr 1 16:03:47 2024 GitCommit: bb81e85a430fa95d23a15b77c717fd68bf06ebf2 GoVersion: go1.22.12 Os: linux
Last updated: 2025-10-22

Post by hyplcmotion on The element of type 'VisuFbElemImage' could not be updated. Reason: Index was outside the bounds of the array. ^{CODESYS Forge talk (Post)}
Hello, I’m encountering the same issue. I only receive these errors when downloading to the PLC—there are no errors during the build—after upgrading to CODESYS 3.5.21.10. Is there any known fix or recommended solution? Visualization seems running ok, no PLC log error. Visualization: Error: The element of type 'VisuFbLabel' could not be updated. Reason: Source array was not long enough. Check srcIndex and length, and the array's lower bounds. Visualization: Error: The element of type 'VisuFbElemSimple' could not be updated. Reason: Source array was not long enough. Check srcIndex and length, and the array's lower bounds. Visualization: Error: The element of type 'VisuFbElemSimple' could not be updated. Reason: Source array was not long enough. Check srcIndex and length, and the array's lower bounds. Visualization: Error: The element of type 'VisuFbElemImage' could not be updated. Reason: Source array was not long enough. Check srcIndex and length, and the array's lower bounds. Visualization: Error: The element of type 'VisuFbElemSimple' could not be updated. Reason: Source array was not long enough. Check srcIndex and length, and the array's lower bounds. Visualization: Error: The element of type 'VisuFbElemSimple' could not be updated. Reason: Source array was not long enough. Check srcIndex and length, and the array's lower bounds. Visualization: Error: The element of type 'VisuFbElemImage' could not be updated. Reason: Source array was not long enough. Check srcIndex and length, and the array's lower bounds. Visualization: Error: The element of type 'VisuFbElemButton' could not be updated. Reason: Source array was not long enough. Check srcIndex and length, and the array's lower bounds. Visualization: Error: The element of type 'VisuFbElemButton' could not be updated. Reason: Source array was not long enough. Check srcIndex and length, and the array's lower bounds. Visualization: Error: The element of type 'VisuFbElemSimple' could not be updated. Reason: Source array was not long enough. Check srcIndex and length, and the array's lower bounds.
Last updated: 2026-01-26

Post by manuknecht on Persistence Manager does not save alphabetically first value ^{CODESYS Forge talk (Post)}
After some more digging I realized that I get an error on the PLC Logger saying PersistenceChannel: 150 (invalid type in data: SimpleLibrary). I suppose the issue could be found in the ConfigData, which is automatically generated and which looks like this: 1 9##83 SimpleLibrary#GVL.aMoreZeros.[1]#0#64512#15#0 <[2]#0#64520#15#0 <[3]#0#64528#15#0 <[4]#0#64536#15#0 <#0#64544#15#0 <[6]#0#64552#15#0 <<lrVar#0#64560#15#0 <strVar#0#64428#16#80 <uiDummy#0#64370#11#0 Perhaps the fact that the variable is stored within a library confused the compiler? I tried changing the PersistenceChannel parameters to xCompressTags := FALSE which changed the entry in the data file from _xCompressTags BOOL:TRUE _xCompressTags BOOL:FALSE but the actual content of the data file and also the config data did not change.
Last updated: 2023-10-17

Post by janber0206 on Gateway doesn't come online, regarding a working internet connection ^{CODESYS Forge talk (Post)}
Solved EN: The Problem is that the Codesys Edge-Gateways have a License with a runtime of an half year, as long the Gateways are online they will self renew themselfs. In my Case the RevPi was more than a year offline and so the Edge-Gateway was not working anymore. The solution: I accessed a laptop that was directly connected to the RevPi. I installed the Codesys service tool and renewed the certificate manual. DE: Das Propblem ist das die Codesys Edge-Gatways eine Lizenz haben die nur ein halbes Jahr gültig ist. Solange das Gateway eine Internet verbindung hat aktualisiert sich das Zertifikat von alleine. In meinem Fall war das Gateway aber über ein Jahr offline und hat somit nicht mehr funktioniert. Die Lösung: Ich hab auf einen Laptop von Kunden mit TeamViewer zugegriffen, der Laptop wurde mit Kabel direkt mit RevPi verbunden. Codesys Service Tool installiert und dann das Gatewayzertifikat aktualisiert.
Last updated: 2023-10-26

Sort by relevance or date