Post by lukasz on Unresolved reference when trying to upload to Codesys Runtime V3 ^{CODESYS Forge talk (Post)}
Hello! I'm working with Codesys SP21 Patch 4. The project builds without any errors. When trying to upload my project to Codesys Runtime V3 x64 I get a lot of Unresolved Reference errors, all with FU- at the start and then -CLOSELAYER2, -GETBUSINFO, -GETFRAME etc. I also get a error pop-up that I should 'update device' in the project but it's not specified to which version or anything useful really.There's also not much to choose from. When I check Runtime version in the systray I get 3.5.21.40 and it's the same as I have set up in the project as the device. All information I get is that it should be clear from the errors but no useful information is provided in the errors. Do I need to install some library? I checked other posts and for different reference error and this was the answer. Thanks in advance!
Last updated: 2026-03-25

Post by anthony-p on Codesys Installation problem ^{CODESYS Forge talk (Post)}
Hello, I'm trying to install Codesys SP21p6 (but the error occurs in SP22 too for eg.) but it fails to install ApplicationComposer. Trying to install myself (version 4.4.0.0 or 4.5.0.0) by clicking 'changing the installation' from the Codesys Installer isn't better. The only message I get is "An error occured during the installation: The file [..]/ApplicationComposer.plugin.dll isn't a valid plugin" How is that? The installation went good the last time before a reinstallation... However, installing the version 4.3.0.0 seems to be successful without knowing what's the difference. I already tried to : - Restart my computer - Delete all temporary files in C:\ProgramData\CODESYS\Temporary Files - Download the package from the store - Compare the ApplicationComposer.plugin.dll from another computer (where the installation is OK) and it's exatly the same For your information, I can install other packages, such as Codesys CFC Can you help me? Do you have any idea of what could be the problem?
Last updated: 2026-06-16

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: 2026-08-05

Post by harryc on Soft Container License issue with ARM64 Linux ^{CODESYS Forge talk (Post)}
Hi, We are working to provide our customers with CODESYS operation on our hardware product ( https://elprotech.com/product/el-qe-e-quantum-edge-series/ ). I'm trying to enable a CODESYS license (Soft container) on our product running ARM64 linux. This problem am having looks similar to here: https://forge.codesys.com/forge/talk/Runtime/thread/6d29b6b4de/ and here: https://forge.codesys.com/forge/talk/Runtime/thread/a2d0c63375/; but I am not running docker, and I am not re-installing a license. This is first time install. I have CODESYS Control SL running on my device, as well as CodeMeter. I purchased a license, and installed it to the CODESYS Development system, (Tools >> License Repository) then tried to install to the device (Tools >> License Manager >> o Device >> o Soft container >> Remote [0001] >> OK. This gives me the "License Manager - Overview" dialog, and the message "Licensing info not available. There is no dongle attached to the device." Below shows the running applications, installed packages, and current content of /var/opt/codesys Also attached screenshots of the Development software as I go through the steps to install the license. # # ps | grep -e "code" -e "CodeMeter" 1391 daemon /usr/sbin/CodeMeterLin 1407 root /opt/codesys/bin/codesyscontrol.bin /etc/codesyscontrol/CODESYSControl.cfg 1442 root /opt/codesysedge/bin/codesysedge.bin /etc/codesysedge/Gateway.cfg 29229 root grep -e code -e CodeMeter # dpkg -l Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==============-=============-============-============================================================================================== ii codemeter-lite 8.20.6539.500 arm64 WIBU CodeMeter minimal runtime ii codesyscontrol 4.14.0.0 arm64 codesyscontrol based on SDK 3.5.20.40 , from Fri Nov 29 08:35:37 CET 2024 [265], Release build ii codesysedge 4.14.0.0 arm64 codesysedge based on SDK 3.5.20.40 , from Fri Nov 29 08:34:19 CET 2024 [265], Release build # ls -la /var/opt/codesys total 208 drwxr-xr-x 6 root root 4096 Nov 7 05:31 . drwxr-xr-x 1 root root 4096 Nov 6 08:33 .. -rw-r--r-- 1 root root 23515 Nov 7 07:26 .Audit.log -rw-r--r-- 1 root root 160 Nov 7 05:31 .GroupDatabase.csv -rw-r--r-- 1 root root 160 Nov 7 04:37 .GroupDatabase.csv_ -rw-r--r-- 1 root root 20736 Nov 29 2024 .SoftContainer_CmRuntime.wbb -rw-r--r-- 1 root root 1982 Nov 29 2024 .UFC_SoftContainer_CmRuntime.WibuCmLif -rw-r--r-- 1 root root 229 Nov 7 04:35 .UserDatabase.csv -rw-r--r-- 1 root root 229 Nov 7 04:35 .UserDatabase.csv_ -rw-r--r-- 1 root root 11807 Nov 7 05:30 .UserMgmtRightsDB.csv drwxr-xr-x 6 root root 4096 Nov 6 08:30 .pki drwxr-xr-x 3 root root 4096 Nov 6 08:30 OPCUAServer drwxr-xr-x 7 root root 4096 Nov 6 08:30 PlcLogic -rw-r--r-- 1 root root 13 Nov 6 08:30 SysFileMap.cfg -rw-r--r-- 1 root root 2640 Nov 29 2024 bacstac.ini drwxr-xr-x 4 root root 4096 Nov 6 08:30 cert -rw-r--r-- 1 root root 94105 Nov 7 07:25 codesyscontrol.log # # uname -a Linux Remote 6.1.22 #5 SMP PREEMPT Tue Nov 18 11:35:46 AEST 2025 aarch64 GNU/Linux #
Last updated: 2025-12-04

Post by thommy54 on Raspi-Cam: CameraStream.project nicht zum Laufen zu bringen ^{CODESYS Forge talk (Post)}
Hallo, Ich bringe das CameraStream.project nicht zum Laufen. Ich sehe die Ursache darin, das das Beispielprogramm sehr sparsam mit Programm-Kommentaren umgeht (von der Hilfe gar nicht zu reden). Ich habe beide Varianten bei der zu ändernden Zielvariable getestet: //copy video.htm to the webserver; //the location of the webserver depends on the used Apache version as mentioned in online help hDirHtmlTest:=SysDirOpen( szDir:='/var/www', pDirInfo:= ADR(dirInfo), diMaxDirEntry:=iMaxDirEntry, szDirEntry:=szDirEntry, pResult:=ADR(iDirHtmlError)); IF (iDirHtmlError = 0) THEN SysDirClose(hDir:=hDirHtmlTest); SysFileCopy('/var/www/video.htm', '$$PlcLogic$$/Application/video.htm', ADR(dwCopySize)); ELSE .... als auch hDirHtmlTest:=SysDirOpen( szDir:='/var/www/html', pDirInfo:= ADR(dirInfo), diMaxDirEntry:=iMaxDirEntry, szDirEntry:=szDirEntry, pResult:=ADR(iDirHtmlError)); IF (iDirHtmlError = 0) THEN SysDirClose(hDir:=hDirHtmlTest); SysFileCopy('/var/www/html/video.htm', '$$PlcLogic$$/Application/video.htm', ADR(dwCopySize)); ELSE .... Die Url-Streams habe ich gelassen wie sie vorgegeben waren: urlStream := CONCAT('http://', CONCAT(sIPAddress, '/video.htm')); urlPicture := CONCAT('http://', CONCAT(sIPAddress, '/cam_pic.php')); In der Webvisu im Browser komme ich maximal dahin wie im Screeshot Video_Visu_1 zu sehen. Also scheint der Link zu video.htm zu klappen. Das der zu cam_pic.php nicht klappt, wundert mich nicht, denn es existiert nicht und wird auch nicht evtl. am rechten Ort angelegt. Ich bin mir vollkommen im Unklaren: muss da was auf dem Raspberry Pi im Hintergrund laufen , z.B. raspivid . Welcher Programmteil bedient die Cam ? Ich erkenne auch nicht, wo ein einzelnes picture entstehen soll. Wäre dankbar, wenn ich hier etwas Hilfe bekommen könnte. Evtl. gibt es Probleme mit der von mir verwendeten Codesys-Version 3.5.20.1 ? Ich benutze einen Raspberry 4 Rev.1.2. Grüße Thomas
Last updated: 2024-07-04

Post by timo on String nach erlaubten/unerlaubten Zeichen durchsuchen ^{CODESYS Forge talk (Post)}
Hallo, Ich bastele gerade an einer möglichst einfachen Möglichkeit mit der ich prüfen kann ob ein String Sonderzeichen enthält. Mein Ansatz ist ein ST FB mit einer Case Schrittkette. Ich vergleiche jedes Zeichen des Strings mit allen Zeichen eines vorher definierten Strings erlaubter Zeichen, der A-Z, a-z und 0-9 enthält und ggf angepasst werden kann, wenn ich weitere Zeichen erlaube. Leider wird meine j Zählervariable nicht richtig ausgeführt. Hat da jemand eine Idee? Oder gibt es eine einfachere Lösung/einen fertigen FB den ich mir anschauen kann? FUNCTION_BLOCK Sonderzeichen_Check VAR_INPUT inputString : STRING; // Zu prüfender String startCheck : BOOL; // Startsignal END_VAR VAR_OUTPUT ok : BOOL; // TRUE, wenn keine ungültigen Zeichen END_VAR VAR i : INT := 1; // Input-String Zähler j : INT := 1; // erlaubte Zeichen Zähler allowedChars: STRING := 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789'; // Erlaubte Zeichen currentChar : STRING[1]; // Aktuelles Zeichen step : INT := 0; // Schritt END_VAR CASE step OF 0: // Warten auf Start IF startCheck THEN step := 10; END_IF 10: // Initialisierungen i := 1; j := 1; ok := TRUE; // Standard: ok step := 20; 20: // Durchgehen des Eingangs-Strings IF i <= LEN(inputString) THEN currentChar := MID(inputString, i, 1); // Aktuelles Zeichen step := 30; ELSE step := 70; // Alle Zeichen ok END_IF 30: // Durchgehen der erlaubten Zeichen IF j <= LEN(allowedChars) THEN step := 40; // Zu Schritt 40 ELSE step := 60; // Ungültiges Zeichen END_IF 40: // Vergleich IF currentChar = MID(allowedChars, j, 1) THEN i := i + 1; // Nächstes Zeichen im Input step := 20; ELSE j := j + 1; // Nächstes erlaubtes Zeichen step := 30; END_IF 60: // Ungültiges Zeichen ok := FALSE; // Setze auf FALSE step := 0; 70: // Alle Zeichen ok step := 0; END_CASE
Last updated: 2025-01-20

Post by trusty-squire on SysProcessCreate2 on Linux runtime ^{CODESYS Forge talk (Post)}
Hi, I'm trying to launch a continuously running python script from Codesys and monitor the script status inside the Codesys runtime (running on a Linux enviroment). For now I'm testing with the below to emulate a continuously running Python script: #test.py i = 0 while True: i += 1 I'm able to successfully run the script using SysProcessExecuteCommand2 (I can see the Python process running in the task manager). However, this "freezes" the Codesys execution of the task - it sits on that command and will not continue until the Python script ends. I've proven this works by using the task monitor to kill the process, then Codesys continues on happily through the task. What I want to do is use SysProcessCreate2 to set up the Python script as a background task and monitor the process using SysProcessGetState. This always results in the error "ERR_OPERATION_DENIED". I know that I'm able to execute commands (as above), so my config should be correct. Is SysProcessCreate2 functional on a Linux environment? Is there something in the config file I'm missing? Here's my "working" code that uses SysProcessExecuteCommand2: VAR bTest : BOOL; sCommand : STRING := '/usr/bin/python3 /var/opt/codesys/PlcLogic/Application/test.py'; refCommand : REFERENCE TO STRING REF= sCommand; sOutput : STRING; refOutput : REFERENCE TO STRING REF= sOutput; result : RTS_IEC_RESULT; END_VAR IF bTest THEN SysProcessExecuteCommand2( pszCommand:= refCommand, pszStdOut:= refOutput, udiStdOutLen:= SIZEOF(sOutput), pResult:= ADR(result) ); bTest:= FALSE; END_IF And here's the code that always results in the ERR_OPERATION_DENIED error: VAR bTest : BOOL; sApp : STRING := '/usr/bin/python3'; sCommand : STRING := '/var/opt/codesys/PlcLogic/Application/test.py'; refApp : REFERENCE TO STRING REF= sApp; refCommand : REFERENCE TO STRING REF= sCommand; hResult : SysProcess.RTS_IEC_RESULT; hHandle : SysProcess.RTS_IEC_HANDLE; END_VAR IF bTest THEN hHandle := SysProcessCreate2( pszApplication:= refApp, pszCommandLine:= refCommand, ulFlags:=SYSPROCESS_CREATEFLAG_HIDDEN, pResult:= ADR(hResult) ); bTest:= FALSE; END_IF Here's the relevant section from the config file at /etc/codesyscontrol/CODESYSControl.cfg: [SysProcess] Command=AllowAll Appreciate any support or ideas. Thanks!
Last updated: 2025-03-16

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 gunstr on CODESYS control on RPi starts, shortly runs, then exits ^{CODESYS Forge talk (Post)}
Thank you very much for the quick answer! The RPi hw were delivered last week so it's probably a resent version. I found an old scrapped board (2 years or so) with a broken GPIO that I tested with the same SD card image and with that board Codeys can run for the full 2h demo period without issues. Then I went back the the new board to test the 4.17.0.0 release but the installation fails... [INFORMATION] Standard output: create and install daemon [INFORMATION] Standard output: codesyscontrol started [WARNING] Unable to detect Raspberry Pi Architecture. Setting armv6l as default, you can change this through the settings panel. [INFORMATION] Standard output: codesyscontrol stopped [ERROR] Expected exit value of command failed: expected 0, received 1 [WARNING] Error setting the Raspberry Pi Architecture [ERROR] Error installing codesyscontrol Do you have any idea what could be the reason? I'm using an OS image including Python drivers for LCD and some I/O:s from last year to keep things stable, but also after upgrading with sudo apt update && sudo apt upgrade I still get the same error Reverting back to 4.15.00 works fine: [INFORMATION] Standard output: create and install daemon [INFORMATION] Standard output: codesysedge started [INFORMATION] Successfully installed codesyscontrol [INFORMATION] Successfully started CODESYS Edge Gateway for Linux [INFORMATION] Successfully started CODESYS Control for Raspberry Pi SL but as before the Codesys services stops after 30 seconds. And I noticed that the Codesys control stops and is not reachable also if I have no application loaded.
Last updated: 2025-09-02

Post by mp9876 on Device logon problem following fresh install ^{CODESYS Forge talk (Post)}
All screenshots are enclosed in MS Word document. NOTE; 4 questions features at the end. Any assistance would be greatly appreciated! Hi everyone, I am still having device logon problem following a fresh install Here are the STEPS I went through following a FRESH CODESYS Win 64 3.5.19.60 install on a different computer. ‘Gateway not configured properly’ when attempting to REFRESH from the Users and Groups. Then did Gateway manage and confirmed it was ok: This message popped out as it was a fresh install: YES then: Initially went with Administrator twice (user & password) but it did not like it. No device is responding to …: Continued by setting a new user Pressed OK and obtained the following message: Stopped and Restarted PLC at that point: Obtained the following: Attempted to login a 2nd time without success. Then I scanned the network to see if matching device can be detected: Only way to get it detected was to remove the tick in the ‘Hide non-matching devices…’ Attempted a WINK but got a return like this one: REFRESH either @ Users and Groups or @ Access Rights returns: Then created user ‘mp’ at Project level ang logged in: Understandably device user mp9876 was not valid for the Project. Device information A few questions comes to my mind following these connection attempts: 1- Gateway not configured properly message pops out because of a non-compatible device ? 2- Why would the device not be compatible ? 3- Any way to make the device compatible ? 4- Any ideas on how to get this connectivity problem to the device solved ?
Last updated: 2024-03-17

Post by thierry-b on Blocking UDP ports 1740–1743 and 22350 to disable CODESYS network scan (startup + device discovery) ^{CODESYS Forge talk (Post)}
Hello, I am currently investigating the network behavior of CODESYS 3.5 (IDE + Gateway) in environments where the engineering workstation is connected to a very large /16 network. In such networks, the automatic device scan performed at IDE startup (and the manual “Scan Network” device discovery) can cause significant delays or freezes, due to the broadcast‑based discovery mechanism. After analyzing the traffic with Wireshark, I identified that the IDE uses the following UDP ports: 1740 – broadcast discovery 1741 – handshake / responses 1742 – fallback discovery 1743 – fallback handshake 22350 – additional runtime / gateway communication (WAGO, debug, extended discovery) To prevent the IDE from scanning the large /16 network, I tested blocking these ports in both directions (IN/OUT) on the network interface connected to the /16 segment (while keeping them open on the OT /24 network interface). Result: When UDP 1740, 1741, 1742 and 1743 are blocked on the IT interface, the IDE no longer sends any discovery traffic on that interface. The IDE still works normally on the OT interface (device discovery, online mode, download, etc.). Blocking port 22350 does not seem required to stop the scan, but I included it for completeness. My question: => Can you confirm that blocking UDP ports 1740, 1741, 1742, 1743 (and optionally 22350) on a specific network interface is a valid and supported way to completely disable the CODESYS IDE network scan on that interface (both at startup and during manual device discovery)? I am not trying to block communication with controllers on the OT network — only to prevent the IDE from scanning the large /16 IT network. Any confirmation or additional technical details about the discovery mechanism would be greatly appreciated. Thank you.
Last updated: 2026-03-31

Post by kishan on SMC_Interpolator / CNC Abort – ControlAxisByPos Sometimes Remains Busy and Axis Continues Moving ^{CODESYS Forge talk (Post)}
Hello, I am working with CODESYS SoftMotion CNC using a preprocessing chain, SMC_Interpolator, and SMC_ControlAxisByPos for controlling the CNC axes. I have noticed an issue when aborting CNC execution. When I execute the Abort command, I abort both the CNC preprocessing blocks and SMC_Interpolator. Normally the CNC process stops correctly. However, occasionally after the abort: SMC_Interpolator has already been aborted. CNC preprocessing has also been aborted/reset. But SMC_ControlAxisByPos.bBusy remains TRUE. The corresponding physical axis can still continue moving for some distance. This does not happen every time. My basic sequence is similar to: G-code / CNC preprocessing ↓ SMC_Interpolator ↓ Transformation ↓ SMC_ControlAxisByPos ↓ SoftMotion Axis When the operator requests CNC Abort, I set the Abort inputs of the interpolator and preprocessing function blocks. My questions are: Does SMC_Interpolator.bAbort only stop/reset the interpolator, or should it also stop the motion currently being executed by SMC_ControlAxisByPos? Can SMC_ControlAxisByPos remain Busy after the interpolator has been aborted? If bAvoidGaps = TRUE, could SMC_ControlAxisByPos still be trying to reach the last fSetPosition using the fGapVelocity / fGapAcceleration / fGapDeceleration settings after the interpolator has stopped? What is the recommended sequence for safely aborting a running CNC program? For example, should the sequence be something like: Stop / Abort Interpolator Disable SMC_ControlAxisByPos Execute MC_Stop for all physical axes Wait until all axes reach standstill Abort/reset preprocessing blocks and CNC queues Reset CNC state Re-enable axis controllers Or is there a recommended CODESYS CNC method for performing a complete CNC Abort? I would especially like to understand why SMC_ControlAxisByPos.bBusy can occasionally remain TRUE and continue moving the axis even though the interpolator and preprocessing blocks have already been aborted. CODESYS SoftMotion CNC is being used with real EtherCAT servo axes. Any explanation about the correct abort/stop sequence would be appreciated.
Last updated: 2026-09-25

Post by timvh on From target start Win OnScreenKeyboard ^{CODESYS Forge talk (Post)}
Check the CODESYS log. Do you see something like this?: 2026-10-28T14:27:50.602Z: Cmp=SysFile, Class=2, Error=39, Info=4, pszInfo=!!!! Access denied to 'C:/Windows/System32/osk.exe' due to ForceIecFilePath 2026-10-28T14:27:50.602Z: Cmp=SysFile, Class=1, Error=0, Info=0, pszInfo= To grant access, this path may be configured as a PlaceholderFilePath PS, if you give an irritating, or annoying or blaming answer, I will never try to help you again. Some additional info... do you run the Control Win as user, or as service. Test it first by running it as a user, else check the info that Claude gave me as suggestion (not tested): Watch out: the keyboard may not appear CODESYS Control Win normally runs as a Windows service. Windows keeps services in a separate, invisible session (session 0). The command then succeeds, but nobody sees the keyboard. You can check this in Task Manager: if osk.exe runs under the user SYSTEM, this is the cause. A reliable workaround uses the Windows Task Scheduler: Create a task named ShowOSK that starts C:\Windows\System32\osk.exe with “Run only when user is logged on” checked. That option makes it open on the user’s desktop. Have the PLC start that task instead of osk.exe: iecst sApp := 'C:\Windows\System32\schtasks.exe'; sArgs := 'schtasks /run /tn "ShowOSK"'; The command line usually repeats the program name as the first argument. 3. Whitelist it in the config: Command.1=C:\Windows\System32\schtasks.exe
Last updated: 2026-10-28

Post by bschraud on runtime received SIGABRT ^{CODESYS Forge talk (Post)}
Ich konnte den Fehler leider nicht wirklich finden. Hier mein bisheriger Fortschritt: Um nähere Informationen zu bekommen, habe ich einen strace erstellt: PID ermitteln: $ ps aux | grep codesyscontrol | grep -v grep --> 560 sudo strace -tt -f -p 560 -o /tmp/codesys_strace.log (Die Logdatei wird schnell einige hundert MB groß.) Mit grep -B 100 'si_signo=SIGABRT' /tmp/codesys_strace.log konnte ich die relevanten Einträge finden: (Die PID hat sich inzwischen wegen einem Reboot geändert) 1023 15:33:49.497136 writev(2, [{iov_base="Unexpected error 9 on netlink de"..., iov_len=45}], 1 <unfinished ...=""> .. 1023 15:33:49.498352 tgkill(545, 1023, SIGABRT <unfinished ...=""> 1023 15:33:49.498440 <... tgkill resumed> ) = 0 .. 1023 15:33:49.498730 --- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=545, si_uid=0}</unfinished></unfinished> Der Codesys Log zeigt zu diesem Zeitpunkt: Exception: HANDLED EXCPT <excpt>NonContinuable</excpt> in CH_COMM_CYCLE Mit sudo lsof -p 545 habe ich die Anzahl der geöffneten Dateien überprüft ohne Auffälligkeiten Mit sudo netstat -tunaep | grep codesys habe ich die offenen Netzwerkverbindungen der codesys Prozesse überprüft Hier sieht es so aus, dass codesyscontrol und codesysedge über die externen Netzwerkschnittstelle anstatt über den localhost kommunizieren: udp 0 0 172.19.11.127:1740 0.0.0.0: 0 17882 549/codesyscontrol. udp 0 0 172.19.11.255:1740 0.0.0.0: 0 17883 549/codesyscontrol. udp 0 0 172.19.11.255:1743 0.0.0.0: 0 16993 529/codesysedge.bin udp 0 0 172.19.11.127:1743 0.0.0.0: 0 16992 529/codesysedge.bin Leider kann ich keine Konfiguration mit einer anderen Schnittstelle einstellen.. Als nächstes habe ich die udp Kommunikation der beiden Prozesse aufgezeichnet: SPID des BlkDrvUdp Threads ermitteln: $ ps aux | grep codesyscontrol | grep -v grep --> 548 $ ps -T -p 548 | grep BlkDrvUdp --> 1200 Damit kann man den strace starten: sudo strace -p 1020 -f -tt -o /tmp/udp_control_trace.log -e trace=socket,connect,bind,sendto,recvfrom,close $ ps aux | grep codesysedge | grep -v grep --> 528 $ ps -T -p 528 | grep BlkDrvUdp --> 789 sudo strace -p 789 -f -tt -o /tmp/udp_edge_trace.log -e trace=socket,connect,bind,sendto,recvfrom,close Beim Aufzeichnen des Traces kamen wiederholte Fehlereinträge im codesyscontrol.log (diesmal ohne SIGABRT) nach folgendem Muster: tail -f /var/opt/codesys/codesyscontrol.log (mit UTC Zeit) 2025-04-17T11:23:43.147Z, 0x00000071, 1, 0, 0, Host : PAC4 2025-04-17T11:23:43.147Z, 0x00000071, 1, 0, 0, HTTP port : 8080 2025-04-17T11:23:43.147Z, 0x00000071, 1, 0, 0, HTTPS port : 443 2025-04-17T11:23:43.147Z, 0x00000071, 1, 0, 0, Connection type : HTTP 2025-04-17T11:23:43.147Z, 0x00000071, 1, 0, 0, ********** 2025-04-17T11:23:46.318Z, 0x00000061, 1, 0, 0, Create asymmetric key done! 2025-04-17T11:23:53.464Z, 0x00000071, 1, 404, 0, File $PlcLogic$/$visu$/favicon.ico not found on this server 2025-04-17T11:23:55.208Z, 0x0000100c, 1, 0, 0, Visu_PRG: Creating Client for Extern-ID: 2025487823 2025-04-17T11:23:55.216Z, 0x0000100c, 1, 0, 0, Visu_PRG: Creating Client successful for Extern-ID: 2025487823 Returned IEC-ID: 0 2025-04-17T11:40:43.471Z, 0x00000114, 4, 1, 0, ** ERROR: SysTaskCreate [CheckLicense0]: pthread_setname_np: Bad file descriptor Hier der dazu passende trace auszug von grep -B 100 '13:40:43' /tmp/udp_edge_trace.log: 798 13:40:42.592535 socket(AF_NETLINK, SOCK_RAW|SOCK_CLOEXEC, NETLINK_ROUTE) = 9 798 13:40:42.592794 bind(9, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, 12) = 0 798 13:40:42.593049 sendto(9, {{len=20, type=0x12 / NLMSG_??? /, flags=NLM_F_REQUEST|0x300, seq=1744890042, pid=0}, "\x00\x00\x00\x00"}, 20, 0, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, 12) = 20 798 13:40:42.602995 sendto(9, {{len=20, type=0x16 / NLMSG_??? /, flags=NLM_F_REQUEST|0x300, seq=1744890043, pid=0}, "\x00\x00\x00\x00"}, 20, 0, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, 12) = 20 798 13:40:42.614794 close(9) = 0 798 13:40:42.615065 socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 9 798 13:40:42.615331 close(9) = 0 798 13:40:42.616159 close(9) = 0 798 13:40:42.616318 socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 9 798 13:40:42.616555 close(9) = 0 798 13:40:42.617209 close(9) = 0 798 13:40:42.617355 socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 9 798 13:40:42.617590 close(9) = 0 798 13:40:42.618497 close(9) = 0 798 13:40:42.618712 socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 9 798 13:40:42.618995 close(9) = 0 798 13:40:42.619568 close(9) = 0 798 13:40:42.620247 close(9) = 0 798 13:40:42.620441 socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 9 798 13:40:42.620690 close(9) = 0 798 13:40:42.621181 close(9) = 0 798 13:40:42.621823 close(9) = 0 798 13:40:43.520036 close(9) = 0 798 13:40:43.520406 close(9) = 0 und grep -B 100 '13:40:43' /tmp/udp_control_trace.log 1035 13:40:43.389785 socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 20 1035 13:40:43.390043 close(20) = 0 1035 13:40:43.390681 close(20) = 0 1035 13:40:43.393690 close(20) = 0 22586 13:40:43.450945 close(0) = 0 22586 13:40:43.451230 close(0) = -1 EBADF (Ungültiger Dateideskriptor) 22586 13:40:43.451689 close(20) = 0 22586 13:40:43.452104 close(1) = 0 22586 13:40:43.452481 close(21) = 0 22586 13:40:43.452679 close(2) = 0 22586 13:40:43.452860 close(2) = -1 EBADF (Ungültiger Dateideskriptor) 1009 13:40:43.454112 close(21) = 0 22586 13:40:43.454522 close(8) = 0 22586 13:40:43.455428 close(8) = 0 22586 13:40:43.455976 close(8) = 0 22586 13:40:43.456852 close(8) = 0 22587 13:40:43.463115 close(8) = 0 22587 13:40:43.464074 close(8) = 0 22587 13:40:43.464682 close(8) = 0 22587 13:40:43.465463 close(8) = 0 22587 13:40:43.468229 close(8) = 0 22587 13:40:43.468737 close(1 <unfinished ...=""> 1009 13:40:43.468805 close(20 <unfinished ...=""> 22587 13:40:43.468849 <... close resumed> ) = 0 1009 13:40:43.468896 <... close resumed> ) = 0 22587 13:40:43.468942 close(2) = 0 22587 13:40:43.469504 +++ exited with 0 +++ 22586 13:40:43.469670 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=22587, si_uid=0, si_status=0, si_utime=0, si_stime=1} --- 22586 13:40:43.470175 +++ exited with 0 +++ 1009 13:40:43.470265 close(20) = 0 546 13:40:43.470577 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=22586, si_uid=0, si_status=0, si_utime=0, si_stime=2} --- 1035 13:40:43.470913 close(20) = -1 EBADF (Ungültiger Dateideskriptor) 22588 13:40:43.480352 --- SIGRT_7 {si_signo=SIGRT_7, si_code=SI_TKILL, si_pid=546, si_uid=0} --- 22588 13:40:43.481675 --- SIGRT_6 {si_signo=SIGRT_6, si_code=SI_TKILL, si_pid=546, si_uid=0} --- 22588 13:40:43.482410 +++ exited with 0 +++</unfinished></unfinished> Die Zeile 2025-04-17T11:40:43.471Z, 0x00000114, 4, 1, 0, **** ERROR: SysTaskCreate [CheckLicense0]: pthread_setname_np: Bad file descriptor zeigt, dass der EBADF-Fehler beim Versuch auftritt, einen neuen Thread namens "CheckLicense0" zu erstellen. Die Funktion pthread_setname_np() erhält einen EBADF-Fehler. Ich weiß leider nicht, ob das eine heiße Spur ist. Parallel dazu habe ich die Aufrufe von Systemfunktionen über SysProcess_Implementation.SysProcessExecuteCommand2 auskommentiert ohne den Fehler damit abzustellen. An diesem Punkt habe ich wegen Termindruck den alten Stand der Runtime (4.11.0.0) mit der Codesys Version 3.5 SP20 wiederhergestellt und die geänderten Programme und Visualisierungen manuell getauscht mit dem Ergebnis, dass der Fehler in den letzten 2 Stunden nicht mehr aufgetreten ist. Wenn jemand das Problem kennt, wäre ich für einen Austausch dankbar. Frohe Ostern!
Last updated: 2025-04-17

Post by alex-at-xana on EThercat Dynamic configuration ^{CODESYS Forge talk (Post)}
Hi Everyone, For a fast monitoring system I am using Ethercat oversampling and timestamping inputs. As the customers has a lot of different configurations out in the field, we went for a dynamic Ethercat configuration. Already got the whole detection chain working but now I am stuck since two days in debugging the configuration. Here are my quesitons: I extended the dynamic config example for the EL3632 16#0E303052: //EL3632 pSlave^.SetDCSettings(TRUE,TRUE,80,80,TRUE,4000,0,0); pSlave^.AddSyncManager(16#1000,128,16#26,TRUE,3); pSlave^.AddSyncManager(16#1080,128,16#22,TRUE,2); pSlave^.AddSyncManager(16#1100,0,16#4,TRUE,1); pSlave^.AddSyncManager(16#1110,214,16#20,TRUE,0); pSlave^.AddFMMU(0,214,0,7,16#1110,0,1,1); pSlave^.AddFMMU(0,1,0,0,16#80D,0,1,1); xKnown := TRUE; This leads to a PLL Error for these devices. I double and triple checked the configuraton, but cannot find the issue. There seems to be one difference: the config dialog creates a startup parameter: 16#10F3:16#05, Name: Command_0, Value:0. Bitlen: 16, Stop on fault: false, jumpt at fault: false: next line: 0 a) I do not find information on how to set this in my code. Can you help me there? b) Without trying to set the value, I get a PLL error for these devices in the master log. Is the config wrong? c) Do I need to set the Master to Autoconfigure or Manual? I used autoconfigure for my tests. The stack creates input data addresses for the slaves input data range (pSlaves[i].InputData) which are different from those created when I use the Engineering tools dialogs to configure Ethercat. Specifically, the addresses seem to be aligned at 16 byte boundaries when they are created using the engineering tool, but may appear at uneven addresses when I use the script in dynamic config. I did not try to access ULINT at uneven addresses yet, but I am suspecting this may be a problem. Do I need to manually align the addresses ? Any help is appreciated...
Last updated: 2024-09-10

Post by struccc on Application failing to boot after system reboot ^{CODESYS Forge talk (Post)}
I started to experience the same issue, after upgrading to 3.5.19 , and still persists with 3.5.20.3 , using CodesysControlWinV3 x64 on Windows. Unfortunately, this is a live application, normally it is running for months without interruption - so it was a surprise at the last cold start... It was not possible to go online with the original version, so I couldn't see the application, or system status, just the log message. First time I manually clean the Application from the PlcLogic directory (there was no coredump file in there), then I could start the runtime service, and do a fresh download, and set the bootproject. I could not try a cold system reboot - it's in a 24/7 production environment, and I was under heavy pressure to start... What I did, I have created a backup from the * complete * runtime directory, from the failed, and fixed version - before and after download. This directory in my case C:\ProgramData\CODESYS\CODESYSControlWinV3x64\55096128 - At the next shutdown, it was sufficient to copy back this backup completely, and could start the runtime service afterwards. Ugly, but local staff with some skills can do it without programming tool... I don't store any live data, configuration, log files, persistent data in this directory - the only reason I need this is to edit the CodesysControl... .cfg file.... And to see the logfiles in emergencies like this. The application concerned doesn't use any retain area. - exactly for these reasons - Maybe that is causing the problem with the newer runtime versions As far as I see, this problem occurs only if the power of the Windows PLC is interrupted without a proper shutdown. Unfortunately, this can happen sometimes. The newer versions, seems tp modify CodesysControl.cfg on the fly, and register the applications, and bootproject information after download. (I don't really see CodesysControl.cfg a proper location for this... but that's just my feeling) So now I had a look at CodesysCotrol.cfg on my laptop and I found: [CmpRetain] ;Retain.SRAM.Size=0x200200 ;Retain.SRAM.Address=0xFA3C5776 ;SimulateSRAM=1 [CmpApp] ;Bootproject.CreateOnDownload=0 ;Bootproject.StoreOnlyOnDownload=0 ;Bootproject.InvalidateByRename=1 ;Bootproject.InvalidateBySetting=1 ;Bootproject.InvalidateNever=0 ;PersistentForce=0 ;RetainType.Applications=InSRAM ;RetainType.Applications=OnPowerfail ;RetainType.Applications=None ;Exception.Hardware.GlobalStop=1 Application.1=MyTestAppNoRetain The last line appeared after download and boot project creation. Maybe... Should set RetainType.Applications=None? I wonder about all these settings, but... Will write separately about it. I hope this helps a little...
Last updated: 2024-11-21

Post by jonasz on Device diagnosis ( EtherCAT IO card ) ^{CODESYS Forge talk (Post)}
Hi, I'll link to the topic not wanting to start a new one. In the application I am building, I wanted to use the diagnostics described in the CAA Device Diagnosis library. In principle, everything is ok, except for the elements related to ModbusTCP. Despite the fact that ModbusTCP is taken into account in the documentation, it is not recognised via the interfaces. FUNCTION_BLOCK NET_HW_DIAG VAR_INPUT END_VAR VAR_OUTPUT END_VAR VAR (* Referencja do struktury z danymi dla HMI ASTRAADA.*) Visu: REFERENCE TO VISU; (* Wskaźnik na mastera EtherCAT.*) pEtherCATMaster : POINTER TO IoDrvEtherCAT; (* Wskaźnik na slave EtherCAT.*) pEtherCATSlave : POINTER TO EtcSlave; (* Interfejs dla węzła w drzewie urządzeń.*) _itfNode: DED.INode; (* Ogólny interfejs magistrali. Zapewnia podstawowe informacje o magistrali polowej.*) _itfBus: DED.IBus; (* Interfejs urządzenia. Zapewnia rozszerzone informacje o urządzeniu (magistralowym).*) _itfDevice2: DED.IDevice2; (* Ogólny interfejs magistrali. Zapewnia podstawowe informacje o magistrali polowej.*) _itfStack: DED.IStack; (* Numer węzła w drzewie urządzeń.*) uiNodes: UINT; (* Operator jest rozszerzeniem normy IEC 61131-3. W czasie wykonywania operator wykonuje konwersję typu odwołania do interfejsu na inny typ. Operator zwraca wynik BOOL. Wartość TRUE oznacza, że CODESYS pomyślnie wykonał konwersję. *) xQueryResultBus: BOOL; xQueryResultDevice2: BOOL; xQueryResultStack: BOOL; (* Struktura danych dotyczących węzłów w drzewie urządzeń.*) NetHwDiag: NW_HW_STAT; ModbusTcpClientDeviceInfo: IoDrvModbusTCP.DED.DEVICE_INFO; ModbusTcpClientDeviceState: IoDrvModbusTCP.DED.DEVICE_STATE; ModbusTcpDeviceInfo: IoDrvModbusTCP.DED.DEVICE_INFO; ModbusTcpDeviceState: IoDrvModbusTCP.DED.DEVICE_STATE; END_VAR (* Pobranie wskaźników dla pierwszego mastera i pierwszego slave w sieci EtherCAT.*) pEtherCATMaster := g_pFirstMaster; pEtherCATSlave := pEtherCATMaster^.FirstSlave; (* Diagnostyka sieci EtherCAT.*) pEtherCATMaster := g_pFirstMaster; pEtherCATSlave := pEtherCATMaster^.FirstSlave; NetHwDiag.xConfigFinished := pEtherCATMaster^.xConfigFinished; NetHwDiag.xDistributedClockInSync := pEtherCATMaster^.xDistributedClockInSync; NetHwDiag.xError := pEtherCATMaster^.xError; NetHwDiag.xSyncInWindow := pEtherCATMaster^.xSyncInWindow; NetHwDiag.sLastMessage := pEtherCATMaster^.LastMessage; NetHwDiag.LastError := pEtherCATMaster^.LastError; (* Diagnostyka drzewa urządzeń.*) uiNodes := 0; _itfNode := DED.GetRoot(); REPEAT NetHwDiag.asDeviceName[uiNodes] := DED.GetDeviceNameString(itfNode := _itfNode); xQueryResultBus := __QUERYINTERFACE(_itfNode,_itfBus); IF xQueryResultBus THEN _itfBus.GetBusInfo(buiInfo := NetHwDiag.aBusInfo[uiNodes]); NetHwDiag.aBusState[uiNodes] := _itfBus.GetBusState(); END_IF xQueryResultDevice2 := __QUERYINTERFACE(_itfNode,_itfDevice2); IF xQueryResultDevice2 THEN _itfDevice2.GetDeviceInfo(deiInfo := NetHwDiag.aDeviceInfo[uiNodes]); NetHwDiag.aDeviceState[uiNodes] := _itfDevice2.GetDeviceState(); IF pEtherCATSlave <>0 THEN pEtherCATSlave^(); IF pEtherCATSlave^.SlaveAddr = NetHwDiag.aDeviceInfo[uiNodes].idSystem THEN NetHwDiag.aAlStatus[uiNodes] := pEtherCATSlave^.ALStatus; pEtherCATSlave := pEtherCATSlave^.NextInstance; END_IF END_IF ELSE xQueryResultStack := __QUERYINTERFACE(_itfNode,_itfStack); IF xQueryResultStack THEN _itfStack.GetDeviceInfo(deiInfo := NetHwDiag.aDeviceInfo[uiNodes]); NetHwDiag.aDeviceState[uiNodes] := _itfStack.GetDeviceState(); END_IF END_IF uiNodes := uiNodes + 1; _itfNode := DED.GetNextNode(_itfNode); UNTIL _itfNode = 0 END_REPEAT (* Diagnostyka Modbus.*) Modbus_TCP_Client.GetDeviceInfo(deiInfo := ModbusTcpClientDeviceInfo); ModbusTcpClientDeviceState := Modbus_TCP_Client.GetDeviceState(); PAC_3200T.GetDeviceInfo(deiInfo := ModbusTcpDeviceInfo); ModbusTcpDeviceState := PAC_3200T.GetDeviceState(); Of course, you can take the easy way out and refer directly to the devices, but I wanted a reusable component. Any constructive help is very welcome Best regards Jonasz
Last updated: 2025-07-15

Post by ara32 on CODESYS 4 Linux: ^{CODESYS Forge talk (Post)}
Hello! I managed to correctly launch CODESYS Developer Studio 3.5.17, almost all functionality works. The only issue remaining is that when connecting to a device and obtaining its public key, the NCryptEncrypt function is called, which is not fully implemented in the DLL source code, resulting in the connection not being established. Currently, the code of this function in the Wine repository looks like this: SECURITY_STATUS WINAPI NCryptEncrypt(NCRYPT_KEY_HANDLE key, BYTE *input, DWORD insize, void *padding, BYTE *output, DWORD outsize, DWORD *result, DWORD flags) { struct object *key_object = (struct object *)key; TRACE("(%#Ix, %p, %lu, %p, %p, %lu, %p, %#lx)\n", key, input, insize, padding, output, outsize, result, flags); if (flags & ~(NCRYPT_NO_PADDING_FLAG | NCRYPT_PAD_OAEP_FLAG | NCRYPT_PAD_PKCS1_FLAG | NCRYPT_SILENT_FLAG)) { FIXME("Flags %lx not supported\n", flags); return NTE_BAD_FLAGS; } if (flags & NCRYPT_NO_PADDING_FLAG || flags & NCRYPT_PAD_OAEP_FLAG) { FIXME("No padding and oaep padding not supported\n"); return NTE_NOT_SUPPORTED; } if (key_object->type != KEY) return NTE_INVALID_HANDLE; return map_ntstatus(BCryptEncrypt(key_object->key.bcrypt_key, input, insize, padding, NULL, 0, output, outsize, result, flags)); } The program crashes due to the NCRYPT_PAD_OAEP_FLAG flag. I'm not proficient in C++, but I attempted to add handling myself, and here's the result: SECURITY_STATUS WINAPI NCryptEncrypt(NCRYPT_KEY_HANDLE key, BYTE *input, DWORD insize, void *padding, BYTE *output, DWORD outsize, DWORD *result, DWORD flags) { struct object *key_object = (struct object *)key; TRACE("(%#Ix, %p, %lu, %p, %p, %lu, %p, %#lx)\n", key, input, insize, padding, output, outsize, result, flags); if (flags & ~(NCRYPT_NO_PADDING_FLAG | NCRYPT_PAD_OAEP_FLAG | NCRYPT_PAD_PKCS1_FLAG | NCRYPT_SILENT_FLAG)) { FIXME("Flags %lx not supported\n", flags); return NTE_BAD_FLAGS; } if (flags & NCRYPT_NO_PADDING_FLAG) { FIXME("No padding not supported\n"); return NTE_NOT_SUPPORTED; } BCRYPT_OAEP_PADDING_INFO oaepInfo = { 0 }; oaepInfo.pszAlgId = BCRYPT_SHA1_ALGORITHM; NTSTATUS status = BCryptEncrypt(key_object->key.bcrypt_key, input, insize, &oaepInfo, NULL, 0, output, outsize, result, flags); if (key_object->type != KEY) return NTE_INVALID_HANDLE; return map_ntstatus(BCryptEncrypt(key_object->key.bcrypt_key, input, insize, padding, NULL, 0, output, outsize, result, flags)); } Now, when calling the connection, it crashes with the error "bcrypt:BCryptEncrypt flags 0x4 not implemented." Can anyone help with enhancing this functionality or at least point me in the right direction?
Last updated: 2024-03-22

Post by winki on ModbusFB ClientRequest: never recovers after a single ReplyTimeout (requires full download) ^{CODESYS Forge talk (Post)}
Library: ModbusFB (CODESYS Modbus package) IDE / Runtime: CODESYS V3.5 SP___ / Control runtime ___ Target: ___ (e.g. gateway, Linux ARM64 / Debian) Slave: Modbus TCP inverter Summary I poll a Modbus TCP slave with a permanent connection: one ClientTCP (kept connected, xConnect:=TRUE) and one ClientRequestReadHoldingRegisters, triggered cyclically. Everything works fine after a fresh application download. But as soon as one single ReplyTimeout occurs (slave temporarily not answering), the request never recovers. It stays stuck and no further messages are sent, even though the TCP connection is still reported as alive. Only a full application download brings it back — an online change or a runtime reset is not enough / not what I want in production. State observed when stuck So the connection is alive, the request finished in ReplyTimeout, the FB is back to _state = None, but udiNumMsgSent no longer increases — as if a new rising edge on xExecute is no longer accepted / no longer produces a new message. My trigger logic (simplified) Each PLC cycle, in this order: If the request is fully at rest (NOT xExecute AND NOT xBusy AND NOT xDone AND NOT xError) and a read is pending, I set xExecute := TRUE. I call clientTcp() then clientRequest(rClient := clientTcp) once each, per cycle. On xDone or xError, I set xExecute := FALSE. I made sure to insert at least one full cycle with xExecute = FALSE (seen by the FB call) before re-triggering, so the falling edge is processed. Questions After a ReplyTimeout (xError = TRUE), what is the exact, correct sequence to re-trigger the same ClientRequest so a new message is actually sent again? Is a full cycle with xExecute = FALSE between two executions mandatory? Is there a known condition where, after ReplyTimeout, the ClientTCP keeps xConnected = TRUE but silently stops sending new requests (e.g. an internal request queue / _udiRequestId that gets out of sync)? udiNumMsgSent freezing at 23 while the FB shows _state = None is what puzzles me. Is the recommended pattern to drop the connection (ClientTCP.xConnect := FALSE for one cycle, then TRUE) on a request error, rather than keeping it alive? The docs state a request error does not close the connection, so I kept it open — but maybe that is the issue here. Could the large uiStartItem (50514) be relevant? It works right after download, so addressing seems correct, but I want to rule it out. Any guidance on the canonical recovery pattern after a request timeout would be greatly appreciated. Thanks!
Last updated: 2026-06-19

Sort by relevance or date