Post by eschwellinger on Codesys MODBUS RTU devices ^{CODESYS Forge talk (Post)}
On which plc you want to add this your screenshot show that it would work on Control Win ?
Last updated: 2026-07-14

Codesys MODBUS RTU devices ^{CODESYS Forge talk (Thread)}
Codesys MODBUS RTU devices
Last updated: 2026-07-14

Engineering Dissertation Help & Assignment Assistance. ^{CODESYS Forge talk (Thread)}
Engineering Dissertation Help & Assignment Assistance.
Last updated: 2026-07-13

Post by afrazeh2026 on Curtis 1226BL Drive ^{CODESYS Forge talk (Post)}
Subject: Curtis 1229-4105 CANopen (CiA 301 / CiA 402) Hello everyone, I am developing a battery-powered industry vehicle using a Curtis 1229-4105 motor controller together with a Siemens S7-1200 PLC and an HMS (Ixxat) CANopen Master. I am looking for someone who has practical experience with the Curtis 1229-4105 CANopen implementation. I would appreciate your help with the following questions: Does the Curtis 1229-4105 support only CANopen CiA 301, or does it also support CiA 402? Is an EDS file available for this controller? Is the CANopen Object Dictionary available? Has anyone successfully communicated with the Curtis 1229-4105 from a Siemens S7 PLC or another CANopen master? Are the CANopen PDOs and Object Dictionary based on the standard CiA profile, or are they Curtis-specific? Any documentation, examples, or practical experience would be greatly appreciated. Thank you very much.
Last updated: 2026-07-15

Curtis 1226BL Drive ^{CODESYS Forge talk (Thread)}
Curtis 1226BL Drive
Last updated: 2026-07-15

Post by charly29160 on CmpCharDevice blocks gpiochip access on Raspberry Pi 5 since update from SP18 to SP21 ^{CODESYS Forge talk (Post)}
Hi, after updating CODESYS Control for Raspberry Pi SL from patch level 18 to 21 (currently 4.21.0.0), the IoDrvGPIO driver ("GPIOs B+/Pi2") can no longer open any GPIO chip on a Raspberry Pi 5. Log output on login: Could not open GPIOChip0. Access to path /dev/gpiochip0 not allowed. Add /dev/gpiochip0 to permitted paths in configuration file if required Could not open GPIOChip4. Trying to open GPIOChip0 Access to path /dev/gpiochip4 not allowed. Add /dev/gpiochip4 to permitted paths in configuration file if required Could not open any GPIOChip. System details: Raspberry Pi 5, 32-bit Raspberry Pi OS (armv7l), kernel 6.12.47+rpt-rpi gpiodetect correctly shows gpiochip0 [pinctrl-rp1] (54 lines) as the RP1 GPIO controller Runtime: CODESYS Control for Raspberry Pi SL 4.21.0.0, Runtime Toolkit SP21+ This worked without issues before the update to SP21. I've tried adding the following to CODESYSControl_User.cfg without success: ini[CmpCharDevice] Linux.DevicePath.1=/dev/gpiochip0 Linux.DevicePath.2=/dev/gpiochip4 Could you tell me the correct section/key to whitelist /dev/gpiochip0 (and /dev/gpiochip4) for CmpCharDevice? I suspect this is part of the general security hardening introduced around SP21 (similar to ForceIecFilePath for SysFile, or the new Gateway "accept local clients only" default), but I couldn't find it documented anywhere. Thanks in advance!
Last updated: 2026-07-19

Post by charly29160 on CmpCharDevice blocks gpiochip access on Raspberry Pi 5 since update from SP18 to SP21 ^{CODESYS Forge talk (Post)}
Hallo Herr Schwellinger - Danke für die Info. Der Fehler besteht weiterhin: Follow-up: Rootless mode is not the cause here — verified with ps aux, the runtime binary runs as root: root 1974 48.9 0.7 854852 62140 ? SLl 13:00 0:04 /opt/codesys/bin/codesyscontrol.bin /etc/codesyscontrol/CODESYSControl.cfg gpioinfo gpiochip0 as root also works flawlessly (all 54 lines listed correctly, no permission errors at the kernel level). So the block is happening purely inside CmpCharDevice's own sandboxing, not at the Linux/kernel permission level and not due to a dedicated unprivileged user. The correct config key to whitelist /dev/gpiochip0 for CmpCharDevice is still what I'm looking for. Im Voraus herzlichen Dank für Ihre Hilfe Karl Schuler
Last updated: 2026-07-20

Post by charly29160 on CmpCharDevice blocks gpiochip access on Raspberry Pi 5 since update from SP18 to SP21 ^{CODESYS Forge talk (Post)}
Hallo Herr Schwellinger - Danke für die Info. Der Fehler besteht weiterhin: Follow-up: Rootless mode is not the cause here — verified with ps aux, the runtime binary runs as root: root 1974 48.9 0.7 854852 62140 ? SLl 13:00 0:04 /opt/codesys/bin/codesyscontrol.bin /etc/codesyscontrol/CODESYSControl.cfg gpioinfo gpiochip0 as root also works flawlessly (all 54 lines listed correctly, no permission errors at the kernel level). So the block is happening purely inside CmpCharDevice's own sandboxing, not at the Linux/kernel permission level and not due to a dedicated unprivileged user. The correct config key to whitelist /dev/gpiochip0 for CmpCharDevice is still what I'm looking for. Im Voraus herzlichen Dank für Ihre Hilfe Karl Schuler
Last updated: 2026-07-20

Post by timvh on PROFINET Controller SL: WRREC remains BUSY forever, no DCE/RPC packets transmitted (RevPi Connect 5 + NORD SK205E) ^{CODESYS Forge talk (Post)}
A customer of us had the same issue. They updated (at that time) to CODESYS 3.5.21.50 and Control for Linux SL versie 4.19.0.0. After that they couldn't reproduce the issue anymore. You might give this a try too.
Last updated: 2026-07-21

PROFINET Controller SL: WRREC remains BUSY forever, no DCE/RPC packets transmitted (RevPi Connect 5 + NORD SK205E) ^{CODESYS Forge talk (Thread)}
PROFINET Controller SL: WRREC remains BUSY forever, no DCE/RPC packets transmitted (RevPi Connect 5 + NORD SK205E)
Last updated: 2026-07-21

Post by ct-f on KOP & FUP in Sp21P6 nicht vorhanden ^{CODESYS Forge talk (Post)}
Hallo Zusammen, ich muss ein Projekt von Sp16P4 auf SP21 portieren, einige FBs wurden damals in FUP und KOP erstellt. Zu meiner großen Verwunderung gab es beim kopieren/einfügen eine Fehlermeldung. Jetzt wollte ich in KOP einen leeren FB erstellen, aber es gibt bei mir im Auswahlmenü weder KOP noch FUP. Gibt es eine Erweiterung, welche ich installieren muss? Konnte dazu nichts finden. Beste Grüße Falk
Last updated: 2026-07-23

Post by baltzer on ICertificateVerifier.VerifyCertificate doesn't appear to override an ERR_CERT_HAS_EXPIRED rejection in TCP_Client.Upgrade() ^{CODESYS Forge talk (Post)}
Setup: Net Base Services (NBS), TCP_Client + TLSContext, ePurpose := CLIENT_SIDE, connecting to a third-party embedded device (Velux KLF200 home automation gateway) whose factory-installed TLS certificate expired on 2026-07-12 and has no user-facing renewal path. Tested on both CODESYS Control for Raspberry Pi SL (3.5.19.0) and CODESYS Control Win V3 x64, with identical results on both. Goal: Accept the peer's expired certificate via a custom ICertificateVerifier implementation, since the certificate itself can never be replaced. Implementation: FUNCTION_BLOCK FB_MyCertVerifier IMPLEMENTS NBS.ICertificateVerifier VAR udiCallCount : UDINT; aeCurStateLog : ARRAY[0..9] OF NBS.RTS_IEC_RESULT; END_VAR METHOD VerifyCertificate : UDINT VAR_INPUT hCert : NBS.RTS_IEC_HANDLE; eCurState : NBS.RTS_IEC_RESULT; END_VAR IF udiCallCount < 10 THEN aeCurStateLog[udiCallCount] := eCurState; END_IF udiCallCount := udiCallCount + 1; VerifyCertificate := 0; // also tried: VerifyCertificate := eCurState; Wired in via tlsContext.itfCertVerifer := certVerifier at declaration time, alongside itfTLSContext := tlsContext set at TCP_Client's own declaration (per an earlier forum thread here on ensuring inline start-values on FB-typed variables are actually honored when nested one level deep - that fix was needed and worked correctly for getting the handshake to start at all). Observed: - VerifyCertificate is confirmed called exactly once per connection attempt (via the call counter above). - eCurState passed in = 0x709 = ERR_CERT_HAS_EXPIRED - correctly reflecting the actual state of the peer's certificate. - Packet capture confirms the full TLS 1.2 handshake completes correctly at the wire level: ClientHello -> ServerHello -> Certificate -> ServerKeyExchange -> ServerHelloDone -> our ClientKeyExchange/ChangeCipherSpec/Finished -> server's ChangeCipherSpec/Finished. Both sides successfully complete the cryptographic handshake. - Despite this, TCP_Client.Upgrade() subsequently returns NBS.ERROR.CONNECTION_ERROR, and the connection is torn down with a plain TCP FIN (not a TLS alert) roughly 7-8ms after our side ACKs the server's Finished message. - TCP_Client.eErrorID (inherited from LCon) remains NO_ERROR throughout - the failure is only visible via Upgrade()'s return value. - Returning 0 (ERR_OK/ERR_CERT_OK - confirmed via the CmpErrors2 Interfaces documentation that these are literally the same value) makes no difference. - Echoing eCurState back unchanged (on the theory that this callback might work like mbedTLS's native verify callback, where the incoming state is a flags value to be cleared/modified and returned, rather than paired with a separate fixed "accept" sentinel) also makes no difference. - Identical result across udiVerificationMode := 0, 1, and 2. - Importing the peer's certificate into the runtime's trusted certificate store via cert-import trusted makes no difference either. - With itfCertVerifer left at its default (no custom verifier) and udiVerificationMode := 2, the underlying engine sends its own fatal TLS alert (handshake_failure) immediately after receiving the peer's Certificate message - suggesting built-in validation may reject at the record layer independent of whether a custom verifier is even present. Questions: 1. Is there an additional step required for a custom ICertificateVerifier to actually override an ERR_CERT_HAS_EXPIRED (or more generally, any ERR_CERT_*) rejection, or is certificate validation enforced unconditionally for a CLIENT_SIDE TLSContext regardless of what the verifier returns? 2. Is 0/ERR_OK genuinely the correct "accept" return value for VerifyCertificate, or does it expect something else (a specific bit pattern, a different constant, a value that must be computed from hCert itself)? 3. Is there a supported way to connect to a peer presenting a certificate that is both self-signed and expired, short of the peer issuing a new certificate? Happy to share the full packet captures or additional test combinations if useful. Also worth noting for anyone finding this thread later: a maintained Node-RED library for this same device (node-red-contrib-velux-klf200, forked to handle this exact expired-certificate situation) solves it by disabling built-in TLS validation entirely (rejectUnauthorized: false) and doing fingerprint-based pinning by hand after the handshake completes, rather than relying on a validation callback - which may be the more realistic approach here too if ICertificateVerifier genuinely can't override this class of rejection. Thanks in advance /Jørgen Disclosure: most of the CODESYS code and this investigation was developed with the help of Claude (Anthropic's AI assistant) - the state machine design, SLIP/checksum implementation, and debugging methodology (including the packet capture analysis) were worked through in an extended back-and-forth with it. Posting here because we've run out of self-serviceable options and this now looks like it needs input from someone with visibility into NBS's actual implementation.
Last updated: 2026-07-26

Configure encapsulation Layer while using Ethetnet/ip product ^{CODESYS Forge talk (Thread)}
Configure encapsulation Layer while using Ethetnet/ip product
Last updated: 2026-07-30

Post by aniket-b on Configure encapsulation Layer while using Ethetnet/ip product ^{CODESYS Forge talk (Post)}
I found this issue raised multiple times but I do not find a solution for this. I am getting Configure encapsulation Layer on EIP product while using with CODESYS V3.5 SP22. This product works well with Rockwell, Omron, Mithshibishi PLCs. The same device, same eds file, same EIP configuration does not work with CODESYS. Can someone please guide me here?
Last updated: 2026-07-30

CodeMeter Network Server: Keep runtime dongle local-only and export only a second CmStick ^{CODESYS Forge talk (Thread)}
CodeMeter Network Server: Keep runtime dongle local-only and export only a second CmStick
Last updated: 2026-08-02

Post by wold on CodeMeter Network Server: Keep runtime dongle local-only and export only a second CmStick ^{CODESYS Forge talk (Post)}
Hello, I am running a CODESYS Control Runtime on a Raspberry Pi. Two CmSticks are connected to the same system: CmStick A - Runtime license - MultiCore license - KNX license CmStick B - Engineering / Developer licenses My goal is: The runtime on the Raspberry Pi shall use CmStick A locally. Licenses from CmStick A shall NOT be provided by the CodeMeter Network Server. Only licenses from CmStick B shall be available to remote network clients. During troubleshooting I observed that the CodeMeter Network Server collects licenses from both CmSticks. The KNX license appears to be local-only, but the runtime and multicore licenses of the same dongle are still visible through the server. I would like to know if a supported configuration exists for the following scenario: One CmStick remains strictly local to the runtime. A second CmStick on the same machine is exported through the CodeMeter Network Server. Questions: Is it possible to exclude a specific CmStick from being exported by the CodeMeter Network Server? Can this be configured via License Access Permissions (ACL), WebAdmin, or another mechanism? Can export rules be applied per CmStick, per Firm Code, or per Product Code? If supported, could you provide a configuration example or a reference to the relevant documentation? The reason for asking is that after removing a separately installed CodeMeter server component and returning to a local-only setup, the runtime licensing behaviour became stable again. Therefore I am looking for the officially supported way to keep the runtime dongle local while still providing engineering licenses from a second dongle over the network. Thank you.
Last updated: 2026-08-02

SCADA Systems Are Becoming Easier to Integrate With Modern Applications ^{CODESYS Forge talk (Thread)}
SCADA Systems Are Becoming Easier to Integrate With Modern Applications
Last updated: 2026-08-04

Post by dmb-fan on Hilscher cards CoDeSys Control RTE ^{CODESYS Forge talk (Post)}
Hi! I'm currently trying to make my way through this jungle... Hilscher CIFX 50E PCIe cards: DP Master + CANopen Master If I want to run these under Control RTE, do I need a master license from Hilscher for each card? Or do they run entirely with CoDeSys drivers and parameterization tools? I can’t find any clear information on this from either manufacturer. Thanks
Last updated: 2026-08-06

Post by baltzer on ICertificateVerifier.VerifyCertificate doesn't appear to override an ERR_CERT_HAS_EXPIRED rejection in TCP_Client.Upgrade() ^{CODESYS Forge talk (Post)}
Follow-up: working workaround found (routing TLS outside CODESYS) For anyone finding this thread later with the same problem (a third-party device presenting a self-signed and/or expired certificate that ICertificateVerifier/udiVerificationMode won't let you connect through) - we never got a working fix within NBS itself, but found a practical workaround worth sharing. Approach: run a local TLS-terminating proxy on the same host as the CODESYS runtime, and have CODESYS talk plain, unencrypted TCP to it instead of connecting to the remote device directly over TLS: CODESYS --plain TCP--> 127.0.0.1:<port> --stunnel/TLS--> <remote device>:<port> We used stunnel (client mode), with certificate verification explicitly disabled at that layer (verifyChain = no, verifyPeer = no) - a simple, well-documented one-line option, unlike anything we could get working inside NBS. Running it as a systemd service with Restart=always means it survives reboots and recovers automatically if the proxy or the remote device drops. On the CODESYS side, this required no changes beyond pointing TCP_Client at 127.0.0.1 instead of the device's real IP, and removing the TLSContext/ICertificateVerifier code entirely - the rest of our application-layer logic (framing, checksums, etc.) was completely unaffected, since none of that ever depended on where the TLS termination happened. Confirmed working end-to-end against a real device with an expired self-signed certificate, running on CODESYS Control for Raspberry Pi SL (Linux). We haven't yet set this up on Windows - stunnel does have Windows builds available, so the same general approach should be possible there too, but that combination isn't tested or confirmed by us at this point. Caveat: this only makes sense when the proxy and the CODESYS runtime are on the same trusted host (in our case, both on the same Raspberry Pi) - don't expose the proxy's plaintext side on a reachable network interface, since that would create an unauthenticated plaintext path to the device. The original question - whether there's a supported way to override an ERR_CERT_HAS_EXPIRED/self-signed rejection from within NBS's own TLSContext/ICertificateVerifier - remains open as far as we know. Still happy to hear from anyone who's solved that particular piece, since the workaround above is a practical detour rather than an actual answer to the original question.
Last updated: 2026-08-06

ICertificateVerifier.VerifyCertificate doesn't appear to override an ERR_CERT_HAS_EXPIRED rejection in TCP_Client.Upgrade() ^{CODESYS Forge talk (Thread)}
ICertificateVerifier.VerifyCertificate doesn't appear to override an ERR_CERT_HAS_EXPIRED rejection in TCP_Client.Upgrade()
Last updated: 2026-08-06

Post by dhumphries on Codesys Installation problem ^{CODESYS Forge talk (Post)}
Installing codesys has been the biggest point of frustration for me and is the reason I'm currently working on building a VM just for the codesys engineering software so once I get a working installation I can copy the VM to new workstations instead of fighting with the installer every time I get a workstation upgrade. The best advice I've gotten in the past is to uninstall everything and start over, this is successful 50% of the time. Also don't install the latest version it's usually less stable than an older one ironically.
Last updated: 2026-08-10

Post by timvh on Codesys Installation problem ^{CODESYS Forge talk (Post)}
Instead of complete VM's, you could also create a sandbox installation using the CODESYS installer.
Last updated: 2026-08-10

Deploy Codesys Control SL to a 'secure' device ^{CODESYS Forge talk (Thread)}
Deploy Codesys Control SL to a 'secure' device
Last updated: 2026-08-10

Codesys Installation problem ^{CODESYS Forge talk (Thread)}
Codesys Installation problem
Last updated: 2026-08-10

Post by eschwellinger on CODESYS Control for Raspberry Pi 5 - "Hardware version or firmware version not supported" on Rev 1.1, persists across multiple runtime versions and OS images ^{CODESYS Forge talk (Post)}
see here: https://www.codesys.com/eco-system/up-to-date/release-lifecycle/release-plan-roadmap/ 18.8
Last updated: 2026-08-11

Sort by relevance or date