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

Post by eschwellinger on codesys installer deletes itself instead of updating ^{CODESYS Forge talk (Post)}
I would try to use: https://store.codesys.com/de/codesys-installer.html this standalone version. Seems if your version out of SP19 setup have some update problem.
Last updated: 2026-08-11

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 (Thread)}
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
Last updated: 2026-08-11

codesys installer deletes itself instead of updating ^{CODESYS Forge talk (Thread)}
codesys installer deletes itself instead of updating
Last updated: 2026-08-11

Post by manuknecht on Persistence Manager does not save alphabetically first value ^{CODESYS Forge talk (Post)}
Update: As of now (CODESYS V3.5 SP21 Patch 6) this Bug was fixed.
Last updated: 2026-08-12

Persistence Manager does not save alphabetically first value ^{CODESYS Forge talk (Thread)}
Persistence Manager does not save alphabetically first value
Last updated: 2026-08-12

Post by leag on Reset device password Festo PLC ^{CODESYS Forge talk (Post)}
Hi, I am new to CODESYS, and I want to program a new FESTO, but I am getting this authentication screen. I don't remember the password. I tried with Administrator/Administrator and some other defaults I found online but nothing works. I also tried searching for CODESYSControl_User.cfg and many other recommended directories but I dont seem to have any of them (like CODESYSControlWinV3x64) Could you please help me understand what I need to reset? Thanks a lot
Last updated: 2026-08-12

Post by eschwellinger on Reset device password Festo PLC ^{CODESYS Forge talk (Post)}
these credentials are saved in the plc - you need to ask Festo how to do this.
Last updated: 2026-08-13

Reset device password Festo PLC ^{CODESYS Forge talk (Thread)}
Reset device password Festo PLC
Last updated: 2026-08-13

Post by hammer on Cartesian XY Chart — 2-D array binding: "Element to use" enumerates the wrong dimension ^{CODESYS Forge talk (Post)}
Title: Cartesian XY Chart — 2-D array binding: "Element to use" enumerates the wrong dimension; documented example (Dialog: XY Chart Configuration, "Two-dimensional array of base type REAL") appears transposed Product / version: CODESYS Development System V3.5 SP21 Patch 40 (3.5.21.40). Cartesian XY Chart visualization element (System_VisuElemXYChart / VisuElemXYChart). Summary: When a curve's Data X/Data Y is bound to a two-dimensional array, the element treats the last array dimension as the per-point record (the one selected by "Element to use") and iterates the first dimension as the sequence of curve points. The online documentation's worked example has the dimensions in the opposite order, so following it produces a non-functional curve and a nonsensical "Element to use" list. Steps to reproduce (fails — matches the documented layout): 1. Declare aData : ARRAY[0..1, 0..4095] OF LREAL; (2 data sets × 4096 points, i.e. first dimension = set, second = point). 2. In XY Chart Configuration, bind a curve's Data X (and Y) Variable to this array. 3. Observe the "Element to use" combobox. Actual result: The "Element to use" combobox lists 4096 entries (the indices of the second dimension) instead of 2 (the data sets in the first dimension). Selecting a row does not produce the expected curve; at most a single/degenerate point is plotted. Steps to reproduce (works — transposed): 1. Declare aData : ARRAY[0..4095, 0..1] OF LREAL; (points first, set second). 2. Bind Data X/Y to this array; "Element to use" now correctly lists [0] and [1]. 3. Populate aData[point, set] and the curve plots as expected. Expected result: Either the documented example should select the data set from the first dimension (as its [1]/[2] "Element to use" implies), or the documentation should state that the last dimension is the record dimension (stride) and the first dimension is the point sequence — consistent with how the element actually behaves. Analysis: The behavior is self-consistent if the element always walks a single array by a fixed byte stride, reading one element per point — the same mechanism as the documented "one-dimensional array of a DUT" case, where it strides by SIZEOF(DUT) and "Element to use" picks the member offset. For a 2-D array the record is the last dimension: to plot column/set c it starts at [0, c] and strides by the last-dimension length to reach [1, c], [2, c], … (row-major layout makes this a contiguous column walk). Under that rule, ARRAY[0..N, 0..1] is correct (record length 2 → "Element to use" [0]/[1]), and the documented ARRAY[1..2, 1..50] with "Element to use" [1]/[2] is transposed. Documentation reference: Dialog: XY Chart Configuration → Data X / Data Y → "Example: Two-dimensional array of the base type REAL" (ARRAY[1..2, 1..50], Element to use [1]/[2], "100 array values are displayed"). This example does not plot as described in 3.5.21.40; transposing to ARRAY[1..50, 1..2] does. Request: Please confirm whether this is (a) a documentation error (example dimensions reversed) or (b) an element defect (combobox enumerates the wrong dimension). Either way, a corrected example plus an explicit statement of which dimension is the point sequence vs. the record/stride dimension would prevent others from hitting this. Two separate 1-D arrays for Data X and Data Y work correctly and are unaffected.
Last updated: 2026-08-14

Cartesian XY Chart — 2-D array binding: "Element to use" enumerates the wrong dimension ^{CODESYS Forge talk (Thread)}
Cartesian XY Chart — 2-D array binding: "Element to use" enumerates the wrong dimension
Last updated: 2026-08-14

Post by lmarmonti on Login problem with FileTransfer on Raspberry Pi 5 ^{CODESYS Forge talk (Post)}
Last updated: 2026-08-18

Login problem with FileTransfer on Raspberry Pi 5 ^{CODESYS Forge talk (Thread)}
Login problem with FileTransfer on Raspberry Pi 5
Last updated: 2026-08-18

Sort by relevance or date