V3.5 SP19 patch 2. Out of retain memory ^{CODESYS Forge talk (Thread)}
V3.5 SP19 patch 2. Out of retain memory
Last updated: 2024-03-20

Problem with the license of libraries IIoT ^{CODESYS Forge talk (Thread)}
Problem with the license of libraries IIoT
Last updated: 2024-04-04

Can't Add New Version of Modbus TCP Master ^{CODESYS Forge talk (Thread)}
Can't Add New Version of Modbus TCP Master
Last updated: 2024-04-09

Maximum dynamic limits of MC_MoveLinearAbsolute and MC_MoveLinearRelative ^{CODESYS Forge talk (Thread)}
Maximum dynamic limits of MC_MoveLinearAbsolute and MC_MoveLinearRelative
Last updated: 2024-05-08

Change the Opening Position of the Dialog using VU.FbOpenDialog ^{CODESYS Forge talk (Thread)}
Change the Opening Position of the Dialog using VU.FbOpenDialog
Last updated: 2024-05-09

Discontinuity of A/B/C axis movement. ^{CODESYS Forge talk (Thread)}
Discontinuity of A/B/C axis movement.
Last updated: 2024-05-09

Raspberry Pi: List of available example applications ^{CODESYS Forge talk (Thread)}
Raspberry Pi: List of available example applications
Last updated: 2024-05-15

Create an alarm list without use of Alarm config ^{CODESYS Forge talk (Thread)}
Create an alarm list without use of Alarm config
Last updated: 2024-06-06

TargetVisu element stacking on top of each other ^{CODESYS Forge talk (Thread)}
TargetVisu element stacking on top of each other
Last updated: 2024-06-17

[SOLVED] Safety EL6900 - SELC0012 Invalid number of connections[ ^{CODESYS Forge talk (Thread)}
[SOLVED] Safety EL6900 - SELC0012 Invalid number of connections[
Last updated: 2024-06-17

Codesys access to DICTIONARY OBJECTS of ethercat (CoE ) Servo Drive ^{CODESYS Forge talk (Thread)}
Codesys access to DICTIONARY OBJECTS of ethercat (CoE ) Servo Drive
Last updated: 2024-06-19

Codesys access to DICTIONARY OBJECTS of ethercat (CoE ) Servo Drive ^{CODESYS Forge talk (Thread)}
Codesys access to DICTIONARY OBJECTS of ethercat (CoE ) Servo Drive
Last updated: 2024-06-19

Synaxis of library declarations in the ST ^{CODESYS Forge talk (Thread)}
Synaxis of library declarations in the ST
Last updated: 2025-11-26

Non-formal invocation of function blocks in CODESYS ^{CODESYS Forge talk (Thread)}
Non-formal invocation of function blocks in CODESYS
Last updated: 2025-12-04

Non-formal invocation of function blocks in CODESYS ^{CODESYS Forge talk (Thread)}
Non-formal invocation of function blocks in CODESYS
Last updated: 2025-12-05

How to read effective version of libraries? ^{CODESYS Forge talk (Thread)}
How to read effective version of libraries?
Last updated: 2025-12-11

C0138: No matching 'FB_Init' method found for instantiation of VisuClientObjectMgr ^{CODESYS Forge talk (Thread)}
C0138: No matching 'FB_Init' method found for instantiation of VisuClientObjectMgr
Last updated: 2025-12-18

How to reset scroll of a table element ^{CODESYS Forge talk (Thread)}
How to reset scroll of a table element
Last updated: 2026-04-13

Importing a library overrides parameters of a referenced library ^{CODESYS Forge talk (Thread)}
Importing a library overrides parameters of a referenced library
Last updated: 2026-05-04

The Unspoken Reality of Online Education: When Ambition Meets Overwhelm ^{CODESYS Forge talk (Thread)}
The Unspoken Reality of Online Education: When Ambition Meets Overwhelm
Last updated: 2026-06-01

Conversion of analogue input into Real measurement value ^{CODESYS Forge talk (Thread)}
Conversion of analogue input into Real measurement value
Last updated: 2026-01-26

Linux ARM64 Deploy Fail - Index out of range ^{CODESYS Forge talk (Thread)}
Linux ARM64 Deploy Fail - Index out of range
Last updated: 2026-07-01

The future and proper use of CAA.BOLT, CAA.SEMA,.. ^{CODESYS Forge talk (Thread)}
The future and proper use of CAA.BOLT, CAA.SEMA,..
Last updated: 2026-07-14

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

Post by danieldiaz on Problem with FB execution ^{CODESYS Forge talk (Post)}
Hello everyone, I've been working on a system which needs an error function, with this purpose I've created a FB programmed in LD, after debugging I run the simulation. It seems that the variable linked to a coil doesn't change the value when the contacts are associated to input variables. When I use internal variables the logic works properly. I don't know if the problem is related to the variables definition or with the logic program. As you can see in the image, I1 and I2 are variables declared on the FB, the rest are input variables. If I force the eStop and Reset signals to TRUE the coil value should change, but it doesn't. However in the second network if I1 is TRUE the coil change to TRUE as it has to be. To sum up, my doubt is why that coil doesn't change its value? I would like someone to shed a light on this. Thanks!
Last updated: 2024-04-02

Sort by relevance or date