wiki Discussion ^{afrazeh2026 wiki (Discussion)}
Forum for wiki comments
Last updated: 2026-07-15

blog Discussion ^{afrazeh2026 blog (Discussion)}
Forum for blog comments
Last updated: 2026-07-15

Home ^{afrazeh2026 wiki (WikiPage)}
Project Members: afrazeh2026 (admin)
Last updated: 2026-07-15

(no subject) ^{afrazeh2026 wiki (Thread)}
Last updated: 2026-07-15

Post by e13740e on Discussion for Home page ^{traffic-control home (Post)}
[-download button: missing =-] A Built-From-Scratch Digital Twin of a Traffic Intersection and Adaptive Traffic Control System (CODESYS / Structured Text) A year ago, I completed my first project — automating a welding production process via offline robot programming in RoboDK. - Published on the RoboDK website: https://robodk.com/example/Material-Handling-and-Welding-with-Fanuc-and-KUKA - YouTube Video: https://youtu.be/yB0ctZ6emPE - LinkedIn Post: https://www.linkedin.com/posts/yevhenii-kutei-08651b351_robodk-offlineprogramming-industrialautomation-activity-7316474707438981120-HpHb At that moment, I realized: to become a truly comprehensive automation systems engineer, I need to master PLC programming. From the entire IEC 61131-3 standard, I chose Structured Text and the CODESYS development environment. As always, mastering something "new" requires a massive challenge. In this case — studying Object-Oriented Programming (OOP), modular development, architecture, data structuring, code execution optimization, building abstractions, and complex visualization. I chose a real-world object — the largest intersection in my city (View on Google Maps). Having absolutely no official documentation, I performed a complete reverse engineering of the intersection's operational logic solely through visual observation. 🎥 Demonstration & Source Code The extended 4K video review below demonstrates the results of my work: https://youtu.be/HEWyx1gOcKs The CODESYS file, source code, and accompanying technical documentation are available here: - GitHub Repository: https://github.com/e13740e/CODESYS-Adaptive-Traffic-Control - Google Drive: https://drive.google.com/drive/folders/1P619CBIfJyTh8SYTZRu7tSgysg4Qu9o8 For ease of review, the repository contains: - AdaptiveTrafficLightControl_DK22-DK25_CODESYS.projectarchive — for a quick download and seamless launch of the project in CODESYS. - src folder — fully replicates the structure of the project's codebase. This allows you to easily view and analyze the code (POU, GVL, DUT) directly in your browser on GitHub, without needing to open the IDE. ⚙️ Technical Architecture & Features The project was created in CODESYS V3.5 SP21 Patch 1+ (64 bit). Since everything was written entirely from scratch (including the math, simulator, and adaptive logic) and designed to run in a standard free CODESYS environment, the project does not require the installation of any third-party libraries. Everything is accompanied by detailed technical documentation: - A full description of the intersection's structure and a comprehensive specification of the operational logic for all its components (written before coding even began). - A Unified Naming Standard (developed at the initial stage and strictly adhered to throughout the development process). The system is built on the principle of deep, multi-level modularity. Here are the key modules (top abstraction level): 1) Intersection Control Core A logic controller that synchronizes the operation of all actuators and displays the current state. The operation of all physical inputs and outputs is visualized on the main screen (the intersection model). The visualization implements connections specifically to hardware variables, not just logical ones. 2) Settings Manager An isolated security module acting as a protective gateway between the user interface (HMI) and the main controller. - Operational settings screen: For quick parameter changes. - Critical settings dialog: Operates on a transactional validation principle ("all or nothing") to guarantee configuration integrity. 3) Adaptive Traffic Control Logic Analyzes intersection data in real-time (generated by the MOCK simulator). Adaptive logic decisions include: - Phase Skipping: Determining the next traffic phase with the possibility of skipping it if there is no traffic waiting, and no requests from dependent pedestrian phases. - Phase Prolonging: Extending the current traffic phase in case of local overload (relative to its own norm) or global overload (relative to the overall intersection state). - Gap-Out (Early Termination): Terminating the currently active traffic phase upon cascaded fulfillment of conditions: completion of the minimum threshold time, absence of traffic on the current lanes for a specified time, presence of confirmed demand elsewhere, and absence of active parallel pedestrian phases. (All logic operations are visualized on a separate HMI screen to monitor the system's decisions). 4) MOCK Simulator An independent multi-parameter module that generates a dynamic traffic simulation (imitating the operation of a CCTV system and inductive loops). - Schematic dynamic visualization of traffic movement. - Hierarchical dialog HMI screens for configuring traffic generation parameters. 🌐 Multilingual & Scalable The visualization supports 4 languages (English, German, Polish, Ukrainian) via Text Lists and native CODESYS localization. The software core is highly flexible and capable of scaling from a simple T-junction to a complex X-junction with 12 entry lanes without rewriting the code. 🚀 Future Aspirations Initially, this project was created as a testing ground for learning Structured Text, but a deep dive made this field truly fascinating. However, my focus is not limited solely to traffic control. In the future, I am interested in solving complex architectural challenges in the following areas: 1. Robot Kinematics (SoftMotion): Developing control systems for N-axis open kinematic chains based on the mathematical apparatus from K. Lynch and F. Park's "Modern Robotics" (2019). 2. Renewable Energy: Automatic control systems for wind turbines. 3. Bioengineering: Industrial automation of bioreactors for biowaste processing. 4. Agro-industry: Automation systems for poultry farming complexes. 🤝 Currently, I am open to new career opportunities in the field of industrial automation, robotics, and PLC programming. If you are looking for an engineer who isn't afraid of unconventional challenges — let's talk! I would appreciate a repost or a comment! PLC #CODESYS #StructuredText #Automation #TrafficControl #Engineering #HMI #Robotics
Last updated: 2026-07-15

youtube4kvideodemonstration Discussion ^{traffic-control youtube4kvideodemonstration (Discussion)}
Forum for youtube4kvideodemonstration comments
Last updated: 2026-07-15

youtubevideodemonstration Discussion ^{e13740e youtubevideodemonstration (Discussion)}
Forum for youtubevideodemonstration comments
Last updated: 2026-07-15

Home (version 1) discussion ^{traffic-control home (Thread)}
Home (version 1) discussion
Last updated: 2026-07-15

Home (version 1) discussion ^{williamcorlin wiki (Thread)}
Home (version 1) discussion
Last updated: 2026-07-16

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

Home (version 1) discussion ^{mecivietnam wiki (Thread)}
Home (version 1) discussion
Last updated: 2026-07-17

Home (version 1) discussion ^{sevensworld wiki (Thread)}
Home (version 1) discussion
Last updated: 2026-07-17

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

(no subject) ^{frankyu wiki (Thread)}
Last updated: 2026-07-23

Home ^{frankyu wiki (WikiPage)}
Project Members: frankyu (admin)
Last updated: 2026-07-23

wiki Discussion ^{jinlau wiki (Discussion)}
Forum for wiki comments
Last updated: 2026-07-24

blog Discussion ^{jinlau blog (Discussion)}
Forum for blog comments
Last updated: 2026-07-24

(no subject) ^{jinlau wiki (Thread)}
Last updated: 2026-07-24

Home ^{jinlau wiki (WikiPage)}
Project Members: jinlau (admin)
Last updated: 2026-07-24

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

Home (version 1) discussion ^{encumurus wiki (Thread)}
Home (version 1) discussion
Last updated: 2026-07-27

Sort by relevance or date