Post by s1ack on Wago PFC200 Ethernet / IoDrvEthernet Issue? ^{CODESYS Forge talk (Post)}
CODESYS Control for PFC200 4.13.00 CODESYS IIoT Libraries SL 1.11.0.0 Application Based License: CODESYS Control Standard M I have (2) projects with similar code base and both using Wago PFC200. On the second project I am seeing 2 things that I have not been able to resolve: 1) Errors in the log under the Ethernet Item: IoDrvEthernet: [PCI\E1Q51CE62] Could not be found on target! Please check the Ethernet settings. 2) Exception for CPU Load. "Processorload watchdog: plcload=100, maxplcload=95" I have slowed down cyclic tasks on this project, even though on the first project there is actually more code - and it does not exhibit this behavior. In looking at the CPU loading via Linux 'TOP' command there appears to be 20% idle. So plenty of headroom (my opinion). In an effort to troubleshoot I have duplicated the target hardware on my bench. It ran overnight without a CPU load exception. On the test system, I have tried (3) version of the ethernet device. 3.5.16.0 3.5.17.0 and 4.2.0.0 Presently the log does not show the error, but status says the module reports an error. I really do not know if this issue is related to the CPU load exception. The issue does not appear to effect ethernet communications (ModbusTCP or SNMP or Webvisu or PuTTy into Linux Shell). On my test bench I have ModbusTCP slave simulators for all ModbusTCP slaves, but only (1) of the (5) SNMP devices present.
Last updated: 2025-01-21

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 artplc on 3.5 P20 hangs - no response ^{CODESYS Forge talk (Post)}
Subject: Solution: CODESYS Freezes Linked to Large Symbol Configuration (OPC UA) Hello everyone, I was experiencing the same problem as many here: CODESYS (v3.5 SP20+) freezing during compilation and download, especially on projects that use OPC UA for SCADA. The only workaround was to run Build > Clean all before every download. I believe I have found the root cause and a permanent solution. The Problem: The issue is directly related to a large Symbol Configuration. In my project, I only need about 700 tags for OPC UA, but the Symbol Configuration list was showing over 250,000 tags. This is because it automatically includes all variables from Global Variable Lists (GVLs) and other memory areas. When any static variable is changed, the IDE tries to rebuild this enormous list, causing it to freeze for several minutes. The Solution: Instead of letting CODESYS export every variable by default, you can use a pragma to tell it which variables or GVLs to exclude from the symbol export process. Place the following pragma at the top of any GVL or data structure that you do not want to be part of the symbol configuration: 1 {attribute 'symbol' := 'none'} 2 VAR_GLOBAL 3 // All variables in this GVL will now be excluded from the 4 // Symbol Configuration by default. 5 InternalVariable1 : INT; 6 InternalVariable2 : BOOL; 7 END_VAR After adding this pragma to all the GVLs that were not needed for OPC UA, the number of tags in my Symbol Configuration dropped to the correct amount. The compilation and download process is now fast again, with no freezing. This method is much more efficient than manually managing the symbol list in the editor. I hope this helps others who are facing this frustrating issue. Best regards.
Last updated: 2025-08-10

Post by akrawczyk on Dynamically enabling/disabling Modbus slave devices in runtime (performance issue with timeouts) ^{CODESYS Forge talk (Post)}
Hi everyone, I'm working on a CODESYS-based project running on a Weintek cMT2078X HMI with a built-in CODESYS runtime. The system communicates with multiple Modbus RTU slave devices, arranged in a cascade. The number of connected units can vary between 2 and 8, depending on the installation. Each slave has 17 Modbus channels, which are polled cyclically every 5 seconds. The issue is that when fewer devices are physically connected (e.g. only 3 out of 8), the Modbus master still attempts to communicate with all configured slaves. This leads to massive delays due to timeouts (currently 200ms per channel). For one disconnected device, that’s: 17 × 200ms = 3.4 seconds of delay per polling cycle, and this quickly multiplies with each additional missing slave. This behavior significantly degrades the system's performance and responsiveness. We attempted a workaround where we tried to trigger polling based on a variable in the PLC program, but this caused instability and even led to hardware hangs/freezes on the cMT2078X – likely due to clashes in how the Modbus polling engine and program logic interact at runtime. My main questions are: Is there a way in CODESYS to dynamically enable/disable Modbus slave devices at runtime, using a BOOL or INT variable (e.g. indicating number of active slaves)? Can devices or channels be conditionally polled or temporarily disabled without removing them from the device tree? Are there any best practices or examples for handling variable numbers of Modbus slaves in scalable systems like this? Would splitting communication across tasks or interfaces help reduce the impact of timeouts? Any advice, documentation references, or architectural suggestions would be extremely helpful. I'm looking for a robust way to dynamically scale slave polling without degrading system stability or performance. Thanks in advance!
Last updated: 2025-08-11

web visu on IFM ^{CODESYS Forge talk (Thread)}
web visu on IFM
Last updated: 2023-08-18

Project size increasing continuously ^{CODESYS Forge talk (Thread)}
Project size increasing continuously
Last updated: 2023-08-23

Function block not autofilling ^{CODESYS Forge talk (Thread)}
Function block not autofilling
Last updated: 2023-08-24

Connection to device closed ^{CODESYS Forge talk (Thread)}
Connection to device closed
Last updated: 2023-08-25

Modbus Extended Registers ^{CODESYS Forge talk (Thread)}
Modbus Extended Registers
Last updated: 2023-08-26

Ping By Name ^{CODESYS Forge talk (Thread)}
Ping By Name
Last updated: 2023-08-29

XY Chart ^{CODESYS Forge talk (Thread)}
XY Chart
Last updated: 2023-08-30

gateway problem ^{CODESYS Forge talk (Thread)}
gateway problem
Last updated: 2023-08-31

EtherCAT - Force Control Word ^{CODESYS Forge talk (Thread)}
EtherCAT - Force Control Word
Last updated: 2023-08-31

Trun off webvisu ^{CODESYS Forge talk (Thread)}
Trun off webvisu
Last updated: 2023-09-02

Error C0521 - unknow compiler ^{CODESYS Forge talk (Thread)}
Error C0521 - unknow compiler
Last updated: 2023-09-02

Webvisu auf Iphones ^{CODESYS Forge talk (Thread)}
Webvisu auf Iphones
Last updated: 2023-09-04

Post by patrik on CODESYS Control for Raspberry Pi SL on Raspberry Pi 4b ^{CODESYS Forge talk (Post)}
Hi! I'm 99% sure I'm running CoDeSys on a raspberry pi 4b. just be aware that there is a separate license for running it on multiple cores. https://store.codesys.com/en/codesys-control-for-raspberry-pi-mc-sl.html
Last updated: 2023-09-05

Schaltflächen in Visualisierung ^{CODESYS Forge talk (Thread)}
Schaltflächen in Visualisierung
Last updated: 2023-09-05

JSON_Utilities_SL JSONFileWriter error NULL_POINTER ^{CODESYS Forge talk (Thread)}
JSON_Utilities_SL JSONFileWriter error NULL_POINTER
Last updated: 2023-09-08

Code Size ^{CODESYS Forge talk (Thread)}
Code Size
Last updated: 2023-09-08

EL6751 Canopen_Manager issue ^{CODESYS Forge talk (Thread)}
EL6751 Canopen_Manager issue
Last updated: 2023-09-12

WebVisu on mobile devices ^{CODESYS Forge talk (Thread)}
WebVisu on mobile devices
Last updated: 2023-09-13

CANbus issue ^{CODESYS Forge talk (Thread)}
CANbus issue
Last updated: 2023-09-14

Post by eschwellinger on Codesys läuft nicht hoch ^{CODESYS Forge talk (Post)}
du startest so nur die SPS selber nicht die CODESYS Entwicklungsumgebung. Die kannst du entweder über den CODESYS Installer oder aber ueber das Startmenu starten. By the way, die SPS: Control Win 64 kannst du auch ueber den Tasktray unten starten ihne dieses Fenster.
Last updated: 2023-09-19

Hex string ^{CODESYS Forge talk (Thread)}
Hex string
Last updated: 2023-09-19

Sort by relevance or date