Post by mark on IO link on IFM AL133x only single digital input on a channel ^{CODESYS Forge talk (Post)}
I have a problem with the CODESYS IO-Link SL software. When I insert a IO link master AL1332 and plug a discrete digital input to a channel it reads only 1 of the 2 available inputs on that channel. Is there anyone who sorted out if the second input is also usable? When we configure the module without the CODESYS IO-Link SL software then the second input on the channel can be used. At the moment we use some channels on a module as IO-link port, and some as discrete IO. It would be very nice if we can use both inputs on a channel with the use of CODESYS IO-Link SL.
Last updated: 2023-12-18

Post by preimesbergert on Raspberry Pi 4 B HW 1.5 Codesys control 4.10.0 stopps after a few seconds ^{CODESYS Forge talk (Post)}
Wanted to play a bit with a raspberry Pi 4 Model B HW 1.5 and Codesys. Regardless of the image (tried 32bit / 64bit version from Raspberry Pi Imager) and with all tested Codesys Control versions (4.2.0, 4.8.0, 4.10.0) and regardless if single core / multicore / 64 bit variant, always is the runtime stopped after about 30sec with the nice message: ooops... this runtime was built for RASPBERRYPI. Hardware version or firmware version not supported! (-7, 0x00000BB8, 0xFFFFFFFB) Whats wrong with it?!?!? I read a lot about the issue in topics from 2020-2021 but it always was stated with new Codesys control version issue will be fixed (4.4 for example) but still it is there.
Last updated: 2023-12-21

Post by preimesbergert on Raspberry Pi 4 B HW 1.5 Codesys control 4.10.0 stopps after a few seconds ^{CODESYS Forge talk (Post)}
Wanted to play a bit with a raspberry Pi 4 Model B HW 1.5 and Codesys. Regardless of the image (tried 32bit / 64bit version from Raspberry Pi Imager) and with all tested Codesys Control versions (4.2.0, 4.8.0, 4.10.0) and regardless if single core / multicore / 64 bit variant, always is the runtime stopped after about 30sec with the nice message: ooops... this runtime was built for RASPBERRYPI. Hardware version or firmware version not supported! (-7, 0x00000BB8, 0xFFFFFFFB) Whats wrong with it?!?!? I read a lot about the issue in topics from 2020-2021 but it always was stated with new Codesys control version issue will be fixed (4.4 for example) but still it is there.
Last updated: 2023-12-21

Post by vformanek on irq-set piority is not working in plc-shell ^{CODESYS Forge talk (Post)}
Hello, I am currently having issues on CODESYS Control for linux SL with DTH expiring. I have followed several tutorials of creating a proper RT linux. Then I further configured the linux based on this tutorial: https://content.helpme-codesys.com/en/CODESYS%20Control/_rtsl_performance_optimization.html Currently I am getting DHT expires in the communication and I am trying to increase of the priority of the network task which manages the PROFINET network adapter. I am following this tutorial: https://content.helpme-codesys.com/en/CODESYS%20PROFINET/_pnio_trouble_connection_failure.html But the irq-set is not changing the priority. See the image bellow....
Last updated: 2024-01-05

Post by yang123 on EtherCAT Can't reconnect to servo drive ^{CODESYS Forge talk (Post)}
I am using Ethercat Master 4.6.0.0 and have use the automatic restart slaves feature. But we found of after the Ethercat communication normal and slave drive power-off and power-on the slave can't reconnect sucess. The PLC Log show the drive was al status "6#34 : Invalid DC Timeout Error" and its was reconnection sucess first but seconced later the drive will show the "16#2C : Fatal Sync error" and then drive will can't reconnection. Other slave are reconnect sucess which was link after the can't reconnect's drive the drive was OMRON R88D-1SN
Last updated: 2024-01-23

Post by mondinmr on Shared Memory Access Issues ^{CODESYS Forge talk (Post)}
In Windows I need create shared memory in PC software and connect from CODESYS. If shm is not GLOBAL doesn't work due different users between runtime and PC software. PC software need admin privileges. Name need "Global\\" before key. Very unsafe!!! If CODESYS create shared I cannot find key PC side. In Linux I can create shared memory as standard user, bind in the runtime docker, use keys without any "Global\\". Much more safe!!! If CODESYS create shared you need play with permissions to use app as standard user. I prefer create form PC software as standard user.
Last updated: 2024-01-30

Post by karol-abktech on Raspberry and problem with runtime ^{CODESYS Forge talk (Post)}
Hi, My problem is with raspberry pi 4 with 2 GB ram,. Install codesys is correct but runtime works only few seconds or I can connect with device few seconds. I can ping raspberry and in system info I can see " !!!! Warning: no runtime license - running in demo mode(~2 hours)" but it is 2 minutes after runtime. When I press Start runtime I have another few seconds when I can connect to raspberry. After this time I couldn't find device. Of course, reapet start runtime works every time on few second. Raspberry is new and works with fresh install raspberry os 32 bit. Where should I start looking for solve of my problem ?
Last updated: 2024-02-14

Post by valenting on Runtime not working on raspberry pi Bullseye ^{CODESYS Forge talk (Post)}
Hello I have a problem with Codesys on Raspberry pi with Bullseye The device is not recognized as a Raspberry pi, as I get this error : ooops... this runtime was built for RASPBERRYPI. Hardware version or firmware version not supported! (-18, 0x00000BB8, 0xFFFFFFFB) I'm running Codesys on a compute module 4S with Raspbian GNU/Linux 11 (bullseye), my kernel version is Linux 5.10.90-v7l+ Codesys version is the latest, released last week (4.11.0.0, CODESYS Control V3.5.19.61 for ARM-32Bit - build Feb 22 2024) I know it works on the same device if I use Raspbian 10 (Buster) with Linux 5.4.81-v7l+ kernel, but for some other reasons I have to use Bullseye. What can I do ?
Last updated: 2024-03-01

Post by superjojo2002 on Licensing info not available. ^{CODESYS Forge talk (Post)}
I recognized that I have to start the two services "/etc/init.d/codemeter" and "/etc/init.d/codemeter-webadmin" in the docker container as well. If I do so, then the command "cmu -x" returns root@sensoredge-field-netfield-produktmanagment:/# cmu -x cmu - CodeMeter Universal Support Tool. Version 7.60c of 2023-Aug-09 (Build 5625) for Linux/ARMHF 64-Bit Copyright (C) 2007-2023 by WIBU-SYSTEMS AG. All rights reserved. So this time there is no indication any more that "Codemeter is not running". But still we are getting the error when using the license manager in CODESYS development system.
Last updated: 2024-03-21

Post by bschraud on Speicherbegrenzung für lokale Variablen ^{CODESYS Forge talk (Post)}
Aufgrund einer Schnittstellenänderung muss ich meine Messagebuffer erheblich vergrößern. U.g. Konstante bestimmt die Größe einer Byte-Array-Definition, die in einer Struktur für 9 Botschaften verwendet wird. Ich benötige also 177372byte zusätzlichen Speicher in dem Modul in dem die Struktur als lokale Variable angelegt wird. Dynamisches Allokieren zur Laufzeit möchte ich vermeiden, damit ich nicht während des Betriebes Fehler aus dem Allokieren behandeln muss. Für ein Reservieren des Speicherbereiches habe ich in Codesys keine Einstellmöglichkeiten gefunden. Die Applikation läßt sich ohne weitere Modifikation kopilieren, scheitert aber bei der Ausführung. Welche Lösungs- oder Einstellmöglichkeiten gibt es? Bei c_w_process_result_content_len_max: WORD := 292; [INFORMATION] Größe des lizenzierten Benutzercodes: 363304 Bytes [INFORMATION] Speicherverbrauch auf dem Gerät, nicht für Lizenzierung verwendet: [INFORMATION] Speicherbereich 0 enthält Daten, Eingang, Ausgang, Speicher und Nicht-sichere Daten: Größe: 2807632 Bytes , höchste verwendete Adresse: 2159712, größte zusammenhängende Speicherlücke: 647920 Bytes (23 %) [INFORMATION] Speicherbereich 3 enthält Code: Größe: 7267784 Bytes , höchste verwendete Adresse: 5590600, größte zusammenhängende Speicherlücke: 1677184 Bytes (23 %) Übersetzung abgeschlossen -- 0 Fehler, 10 Warnungen : Bereit für Download Speicherprüfung: [WARNUNG] PAC: MC0006: Pointeradresse außerhalb des verwalteten Speichers für Eintrag GVL.htFactory._itfInstList.__Interface in Area 0, Offset 0x000033BC (0x71C15414) [WARNUNG] PAC: MC0006: Pointeradresse außerhalb des verwalteten Speichers für Eintrag __datasourcesInstancesGVL.__datasourcesInstances.dsInst._allItemsHashtable._ht.__Interface in Area 0, Offset 0x00128904 (0x71D3A95C) [WARNUNG] PAC: MC0009: Pointer to Interface zeigt nicht auf die erwartete Schnittstelle in einer FB-Instanz für Eintrag IoConfig_Globals.PiXtend_V2_L_Instance._IIoDrv.__Interface in Area 0, Offset 0x0018EC00 (0x71DA0C58) [WARNUNG] PAC: MC0009: Pointer to Interface zeigt nicht auf die erwartete Schnittstelle in einer FB-Instanz für Eintrag IoConfig_Globals.PiXtend_V2_S_DAC_Instance._IIoDrv.__Interface in Area 0, Offset 0x0018F090 (0x71DA10E8) [INFORMATION] PAC: Überprüfter Speicher für 21336 Objekte. 4 Prüfung(en) fehlgeschlagen. [INFORMATION] PAC: Check took 00:00:13.9743220. Applikation lässt sich downloaden und funktioniert auf dem Gerät. Nach der Vergrößerung: c_w_process_result_content_len_max: WORD := 20000; [INFORMATION] Größe des lizenzierten Benutzercodes: 363304 Bytes [INFORMATION] Speicherverbrauch auf dem Gerät, nicht für Lizenzierung verwendet: [INFORMATION] Speicherbereich 0 enthält Daten, Eingang, Ausgang, Speicher und Nicht-sichere Daten: Größe: 4114264 Bytes , höchste verwendete Adresse: 3164816, größte zusammenhängende Speicherlücke: 949448 Bytes (23 %) [INFORMATION] Speicherbereich 3 enthält Code: Größe: 7267832 Bytes , höchste verwendete Adresse: 5590640, größte zusammenhängende Speicherlücke: 1677192 Bytes (23 %) Übersetzung abgeschlossen -- 0 Fehler, 10 Warnungen : Bereit für Download Speicherprüfung: (gleiches Ergebnis wie vorher) [WARNUNG] PAC: MC0006: Pointeradresse außerhalb des verwalteten Speichers für Eintrag GVL.htFactory._itfInstList.__Interface in Area 0, Offset 0x000033BC (0x71C15414) [WARNUNG] PAC: MC0006: Pointeradresse außerhalb des verwalteten Speichers für Eintrag __datasourcesInstancesGVL.__datasourcesInstances.dsInst._allItemsHashtable._ht.__Interface in Area 0, Offset 0x0021DF38 (0x71E2FF90) [WARNUNG] PAC: MC0009: Pointer to Interface zeigt nicht auf die erwartete Schnittstelle in einer FB-Instanz für Eintrag IoConfig_Globals.PiXtend_V2_L_Instance._IIoDrv.__Interface in Area 0, Offset 0x00284238 (0x71E96290) [WARNUNG] PAC: MC0009: Pointer to Interface zeigt nicht auf die erwartete Schnittstelle in einer FB-Instanz für Eintrag IoConfig_Globals.PiXtend_V2_S_DAC_Instance._IIoDrv.__Interface in Area 0, Offset 0x002846C8 (0x71E96720) [INFORMATION] PAC: Überprüfter Speicher für 21336 Objekte. 4 Prüfung(en) fehlgeschlagen. [INFORMATION] PAC: Check took 00:00:14.0491831. Applikation lässt sich downloaden. Ausführen mündet in Ausnahmefehler Die Applikation läuft auf der Runtime CODESYS Control for Raspberry Pi MC SL. Die Codesys Version ist 3.5 SP20 mit allen Updates. Kennt jemand eine Speichergrenze für lokale Variablen bzw. eventuelle Einstellmöglichkeiten? Vielen Dank
Last updated: 2024-05-06

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 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 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 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 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 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

Post by naps on cant install runetime on 750-8202 ^{CODESYS Forge talk (Post)}
Hello, im trying to install the 3.5 Runtime on a a fresh image on my 750-8202. Product Description: WAGO 750-8202 PFC200 CS 2ETH RS Firmware Revision: 03.10.08(22) ~~~ df -h Filesystem Size Used Available Use% Mounted on ubi0:rootfs.1 82.5M 66.5M 11.8M 85% / devtmpfs 117.8M 16.0K 117.8M 0% /dev none 118.3M 12.0K 118.3M 0% /tmp none 118.3M 0 118.3M 0% /media none 4.0M 136.0K 3.9M 3% /var/log none 118.3M 112.0K 118.2M 0% /var/run none 118.3M 0 118.3M 0% /var/lock none 118.3M 0 118.3M 0% /var/tmp none 118.3M 0 118.3M 0% /sys/fs/cgroup tmpfs 118.3M 48.0K 118.2M 0% /run /dev/ubi0_1 58.6M 3.4M 52.2M 6% /home /dev/ubi0_1 58.6M 3.4M 52.2M 6% /settings /dev/ubi0_1 58.6M 3.4M 52.2M 6% /log ~ After installation and reboot i have still the wago webinterface. No runtime on Information Tab and the Runtime button from the configuration tab is lost. iv try it with firmware 22 and 21. Same problem. What can i do?
Last updated: 2024-09-29

Post by egau on Hard shutdown: no code on device after power on ^{CODESYS Forge talk (Post)}
This explanation aligns with the issues we’re experiencing with our machines. The scenario I described is happening with one of them (let’s call it Machine A). This machine is identical to another one (Machine B), except for some custom code that facilitates communication with an external Beckhoff PLC for MES integration in the production line. Machine B has been powered on and off daily for at least three months and has never had this problem. Given that, I highly doubt the MES custom code is the cause of the code corruption. This being said, your explanation does seem plausible. However, if faulty EtherCAT cables were the issue, why wouldn't the error occur during normal operation? Why would bad cables only cause problems during a hard shutdown? One last question: When you encountered this behavior, did you see a similar error in your logs? i.e, an "AccessViolation" exception in the EtherCAT Task?
Last updated: 2024-10-03

Post by timvh on Device diagnosis ( EtherCAT IO card ) ^{CODESYS Forge talk (Post)}
You can get the state by just using the name of your node (same name as in device tree): VAR etcState: IoDrvEthercatDriverLib.ETC_SLAVE_STATE; END_VAR etcState := EJ1100.wState; Alternatively, you can iterate through the device tree to get the status of all (Ethercat) nodes. See here an example (no guarantee it works, just give as suggestion): PROGRAM P_IO_State VAR CONSTANT uiMAX_NR_OF_TERMINALS : UINT := 100; END_VAR VAR // general device diagnosis // can only be used when the Device - PLC Settings - Advanced settings - enable diagnosis for devices is enabled // this will add the DED library coupler: DED.INode; terminal: DED.INode; aDeviceState: ARRAY[0..uiMAX_NR_OF_TERMINALS - 1] OF DED.DEVICE_STATE; uiTerminalCount : UINT; uiIndex : UINT; // for each terminal check if it implements device diagnostics xQueryResult: BOOL; itfDevice : DED.IDevice2; xDiagAvailable: BOOL; eError: DED.ERROR; xEverythingOK: BOOL; END_VAR uiTerminalCount := 0; // start at the top of the device tree with the first EtherCAT coupler coupler := EtherCAT_Master.FirstChildNode; WHILE coupler <> 0 DO // for each coupler that is found start at the first terminal terminal := coupler.FirstChildNode; WHILE terminal <> 0 AND uiTerminalCount < uiMAX_NR_OF_TERMINALS - 1 DO // for each terminal that is found get the status through the device diagnosis interface xQueryResult := __QUERYINTERFACE(terminal, itfDevice); IF xQueryResult THEN aDeviceState[uiTerminalCount] := itfDevice.GetDeviceState(xDiagnosisInfoAvailable => xDiagAvailable, eError => eError); uiTerminalCount := uiTerminalCount + 1; END_IF terminal := terminal.NextSiblingNode; END_WHILE coupler := coupler.NextSiblingNode; END_WHILE uiIndex := 0; xEverythingOK := TRUE; WHILE uiIndex < uiTerminalCount DO IF aDeviceState[uiIndex] <> DED.DEVICE_STATE.RUNNING THEN xEverythingOK := FALSE; EXIT; END_IF uiIndex := uiIndex + 1; END_WHILE
Last updated: 2025-02-06

Sort by relevance or date