Post by blade on Visualization Object missing from drop-down list... ^{CODESYS Forge talk (Post)}
Hi, For some reason, the Visualisation object is missing from the drop-down list (see the attachment). Does anyone know why it''s missing and how I can fix the problem? Thanks in advance
Last updated: 2026-07-01

Visualization Object missing from drop-down list... ^{CODESYS Forge talk (Thread)}
Visualization Object missing from drop-down list...
Last updated: 2026-07-01

Post by josepmariarams on Limit Axis CNC Jerk using SMC_Polynomial_AbsMaxLocs ^{CODESYS Forge talk (Post)}
I am using both functions for: I override SMC_LimitDynamics o calculate the individual axis jerk on polynomial movements. LimitDynamics only controls acceleration and velocity, it's not enought to create smooth movements. To solve the problem when smothing path create loops. It seems that polynomial passes two times by the same point and smc_smooth path chooses incorrect one.
Last updated: 2026-07-05

Post by shivsrikakolum on Getting SMC_ERROR 34 SMC_AXIS_NOT_READY_FOR_MOTION, while the axis should be ready for motion ^{CODESYS Forge talk (Post)}
how did you manage to get rid of the error. i have set the cycle time to 2000 microsecond but my softaxis is still amber warning
Last updated: 2026-07-07

Getting SMC_ERROR 34 SMC_AXIS_NOT_READY_FOR_MOTION, while the axis should be ready for motion ^{CODESYS Forge talk (Thread)}
Getting SMC_ERROR 34 SMC_AXIS_NOT_READY_FOR_MOTION, while the axis should be ready for motion
Last updated: 2026-07-07

Post by gseidel on Limit Axis CNC Jerk using SMC_Polynomial_AbsMaxLocs ^{CODESYS Forge talk (Post)}
Interesting. In the SMC_LimitDynamics case, do you reduce the maximum velocity of the SMC_GeoInfo based on the third derivative of the spline?
Last updated: 2026-07-09

Limit Axis CNC Jerk using SMC_Polynomial_AbsMaxLocs ^{CODESYS Forge talk (Thread)}
Limit Axis CNC Jerk using SMC_Polynomial_AbsMaxLocs
Last updated: 2026-07-09

Post by eschwellinger on Beckhoff CX9240 : Using Internal EtherCAT Bus ^{CODESYS Forge talk (Post)}
yes, you need to install Control RTE CX. In that package there is the Internal EthercatMaster / EthercatMasterSoftmotion which you could add then.
Last updated: 2026-07-10

Post by erik-gerrits on Dynamic Images ^{CODESYS Forge talk (Post)}
I ran into this issue as well. Here is the fix: Good example: CASE iBitmap OF 0 : sName := 'ImagePool.image0'; 1 : sName := 'ImagePool.image1'; END_CASE Bad example (this will only work on the target device, WebVisu will show a blank rectangle): CASE iBitmap OF 0 : sName := '/home/cds-apps/PlcLogic/visu/image0.png'; 1 : sName := '/home/cds-apps/PlcLogic/visu/image1.png'; END_CASE
Last updated: 2026-07-10

Post by eschwellinger on Beckhoff CX9240 : Using Internal EtherCAT Bus ^{CODESYS Forge talk (Post)}
you need just out of this windows rte cx package the internal EthercatMaster device description
Last updated: 2026-07-10

Dynamic Images ^{CODESYS Forge talk (Thread)}
Dynamic Images
Last updated: 2026-07-10

Post by arj3090 on Beckhoff CX9240 : Using Internal EtherCAT Bus ^{CODESYS Forge talk (Post)}
I installed Linux ARM SL and it recognizes the RJ45 ethernet ports, but I cannot get it to recognize the internal port for the IO cards.
Last updated: 2026-07-10

Post by repc2026 on Codesys MODBUS RTU devices ^{CODESYS Forge talk (Post)}
I am trying to use Codesys to connect by Modbus RTU to an Arduino UNO, I add the Modbus COM Port but when I try to add the master and the slave I don't have these options, I attach an image of the device manager. I am using Codesys 3.5 SP21.
Last updated: 2026-07-13

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

Sort by relevance or date