Post by reinier-geers on Resize and position Numpad/Keypad ^{CODESYS Forge talk (Post)}
HI, I download the scale dialog. But cant find were i can Set the size of the dialogs. only the position. I want the diolog bigger
Last updated: 2026-04-15

Post by husarz17 on How change Unity-ID in TCP Modbus Slave ^{CODESYS Forge talk (Post)}
Good to know there's a solution to this problem. I hope you'll be able to share it with me. I can't wait to hear about it.
Last updated: 2026-04-20

Post by malie on Issue with library updates ^{CODESYS Forge talk (Post)}
Hello, i got the same problem, but on my site it started with version 3.5.21, with version 3.5.19.7 it worked like a charm. How get the old behavior back? Or how to reload the librarys in an open project/library manually?
Last updated: 2026-04-24

Post by reinier-geers on Network variable stops sending ^{CODESYS Forge talk (Post)}
What version. 20.5 ? ive got also problems wiyth that version. Online change, it hangs itself after one hour. Then one project can problems. Ive change display with 21.0 . At home i turned on the 20.5 display. After 1 hour i goes to stop.
Last updated: 2026-05-06

Post by alex-n on Problem with keeping up the distance between two axes ^{CODESYS Forge talk (Post)}
We use Inovance AC802 as PLC, IS810N Drive, library 4.10, connection via Ethercat and no any suprise at work.
Last updated: 2026-06-02

Whether You’re New to Nursing or a Seasoned Pro, Grasping the Basics of NURS FPX 4055 Assessment 1 Offers Many Benefits ^{CODESYS Forge talk (Thread)}
Whether You’re New to Nursing or a Seasoned Pro, Grasping the Basics of NURS FPX 4055 Assessment 1 Offers Many Benefits
Last updated: 2026-06-13

Post by eschwellinger on Linux ARM64 Deploy Fail - Index out of range ^{CODESYS Forge talk (Post)}
Which Deploy Tool version is installed? the ssh login does work? If yes could we get a screenshot of the device information see my example:
Last updated: 2026-07-01

Post by arj3090 on Linux ARM64 Deploy Fail - Index out of range ^{CODESYS Forge talk (Post)}
I used Tools->Deploy Control SL in the IDE that I downloaded yesterday. So I assume it is the latest version. I did a manual install using SSH and it works.
Last updated: 2026-07-01

Post by tvm on Generic Variables and FDB ^{CODESYS Forge talk (Post)}
I also ran into this, try using Coil<1> as the type in the FBD box. From what I understand, with VAR_GENERIC CONSTANT, the compiler creates separate data types for each different function block declaration.
Last updated: 2026-07-22

Post by tvm on XY Chart causes extremely long cycle in Visu Task ^{CODESYS Forge talk (Post)}
No solution, but we have also seen similar behaviour with the XY chart, using Schneider M262 PLCs. It was a contributing factor to our decision to switch to TwinCAT HMI.
Last updated: 2026-07-22

Post by eschwellinger on CAN TX regression in Control for Raspberry Pi 4.21.0.0 with CAN API library (RX works, TX silently fails) ^{CODESYS Forge talk (Post)}
seems to be an accident but there is a workaround in the Configfile: [CmpSocketCanDrv] AsyncSend=1 and will be solved with 4.22.0.0 Release
Last updated: 2026-08-17

CAN TX regression in Control for Raspberry Pi 4.21.0.0 with CAN API library (RX works, TX silently fails) ^{CODESYS Forge talk (Thread)}
CAN TX regression in Control for Raspberry Pi 4.21.0.0 with CAN API library (RX works, TX silently fails)
Last updated: 2026-08-17

Post by patrik on Wish: CODESYSControl.cfg - again ^{CODESYS Forge talk (Post)}
Really good post. I hope that it gets seen by CoDeSys staff. I often find the documentation lacking when it comes to using CoDeSys in more complex ways. If using standard "basic PLC functionality", then it's fine and functions are documented in a sufficient way. Once you go outside of that bubble then I find the documentation not enough. CODESYSControl.cfg is a good example of this. And why isn't more of this integrated in the IDE. like changing port of the webserver. Why is it hidden in this file and not accessible through the IDE. It feels like a layer of complexity purposely left in so you don't change it if you don't know what you are doing. Like the argument is if you have the know-how to find the file you have the know-how to edit it. I find the documentation lacking when it comes to more complex libraries too. Like the element collections library. there is parameters I still don't quite know what they do. I can't find any documentation about them. There is an example project to download from CoDeSys so you can see how you are supposed to set your factories up. I leave some parameters like it is in the example. Should I? I don't know. Does it work. Yes. But I could perhaps create memory leaks if I get something wrong and I don't see that until way later. In the create method of your element factory you have a function called __vfinit and you just have to accept that it works. Why can't I get insight in what it does through documentation? Don't CoDeSys want us to know how these work so we can't use them to accidentally break something? I find the error logging lacking too. I've had the CoDeSys service crash but it doesn't say why. I've seen windows noticing the crash but no error code was sent or error message. Also in my current issue where the application fails to start after power outage. I can see in the log that it fails to load retain in the application as one log entry and application failing to start as another. But why? Why does loading the retain fail? give me more information! Is it just a skill issue with me? I don't know. If it is then I'd still want CoDeSys to step up their game when it comes to documentation. I'm sorry if a lot of frustration comes though in this post. I really like the product and what I can do with it compared to other PLC brands.
Last updated: 2024-11-21

Post by sahin6033 on DSE M840-001-02: DSEServiceTool transfers CodesysApp.pkg successfully, but device shows “No application loaded ^{CODESYS Forge talk (Post)}
Hi, I am trying to load a test application into a DSE M840-001-02 display, but after reboot the device still shows: “No application loaded” I would like to understand whether the problem is in my project, the package creation process, or firmware/runtime compatibility. Hardware Device: DSE M840-001-02 Firmware used: M840 MKII Firmware File v4.1.2 Software CODESYS V3.5 SP12 (32-bit) DSE CODESYS Package v1.5.44 DSEServiceTool What I did Created a new empty Standard Project Selected target/template: M840-02 V4.1 Used a minimal ST program only: PROGRAM PLC_PRG VAR xAlive : BOOL := TRUE; END_VAR Confirmed: project builds PLC_PRG is assigned to MainTask created Boot Application Generated CodesysApp.pkg Put the M840 into bootloader mode Sent the package using DSEServiceTool DSEServiceTool result Transfer completes successfully and I get: connection accepted 100% download package ACK <status>OK</status> ** Example log:** Searching for controllers.... sendPackageToController: waiting for incoming data connection... sendPackageToController: connection accepted... <status>Downloading</status> <percent>20</percent> <percent>40</percent> <percent>90</percent> <percent>100</percent> sendPackageToController: sent 112cb8 bytes OK Package ...\CodesysApp.pkg transferred to controller c0a80101 OK sendPackageToController: package ACK <status>OK</status> Actual result After reboot, the display still shows: “No application loaded” Additional issue I also saw earlier At one stage I also had these fatal errors in CODESYS: [FATAL ERROR] Unresolved reference: 'IOMGRLOCKENTER' [FATAL ERROR] Unresolved reference: 'IOMGRLOCKLEAVE' I checked library versions and adjusted them to: IoDrvBase = 3.5.5.0 IoStandard = 3.5.10.0 Also, I am using CODESYS SP12, which I understand is the correct version for DSE M840. My questions If DSEServiceTool shows Status OK and package ACK, but the device still says “No application loaded”, does that mean: the .pkg was transferred but not accepted as a valid application? the package was built incorrectly? the boot application / runtime / firmware versions are still mismatched? What is the correct procedure to generate CodesysApp.pkg for M840-02 V4.1? Is there any known compatibility issue between: DSE CODESYS Package 1.5.44 M840 MKII Firmware 4.1.2 CODESYS 3.5 SP12 Has anyone successfully loaded even a minimal empty test project into M840-001-02, and if so, what exact versions/process did you use? Any help would be appreciated.
Last updated: 2026-03-17

Post by toffeebonbon on Die richtige CODESYS-Runtime auf dem Raspberry Pi ausrollen (3.5 SP18) ^{CODESYS Forge talk (Post)}
Guten Morgen, wie der Titel verrät soll es hier um das Ausrollen der CODESYS Runtime auf einem Raspberry Pi gehen. Ob ein klassischer Raspberry Pi aus dem Consumer-Bereich oder ein Compute-Modul spielt in dem Fall keine Rolle. Ich möchte nur anderen Nutzern Hilfestellung geben, die vielleicht ein vergleichbares Problem haben wie ich: Auf Raspberry Pi lief bei mir eine Anwendung, die mit Lizenzen auf einem CODESYS-Dongle lizenziert waren (Multicore-Support und Softmotion). Nach einem Hardware-Defekt habe ich meinen Rasperry Pi gegen eine robustere Lösung getauscht. Ich wollte auf der neuen Hardware die Runtime ausrollen und habe ständig den Fehler gezeigt bekommen, dass die Target- oder Zielsystem-ID nicht stimmt. Für den Raspberry Pi gibt es ja drei verschiedene Optionen der Runtime: 32bit Singlecore (armv6l) 32bit Multicore (armv7l) 64bit Multicore (aarch64) Entscheidend dafür, ob die 32 oder 64 Bit Runtime benötigt wird ist das auf der dem Raspberry Pi installierte Betriebssystem. In meinem Fall hatte ich durch die neue Hardware auch ein aktuellen Betriebsystem-Image aufgespielt, weshalb sich da der Umstieg von 32 auf 64Bit eingeschlichen hatte. In der Entwicklungsumgebung kann über Tools -> Control SL ausrollen das Fenster geöffnet werden, um die richtige Laufzeitumgebung auf dem Steuerungsrechner zu installieren. Bei kleinen Bildschirmen (bei mir ein 15" Laptop) kann der rechte Bereich "abgeschnitten" und das Dropdown-Menü als solches nicht auf den ersten Blick erkennbar sein. Mein Fehler war, dass ich den Scrollbalken nicht gesehen habe! (Bild im Anhang mit freundlicher Genehmigung von Herrn Heberle vom CoDeSys-Support) Nach dem auswählen der jeweils passenden Version kann die Runtime installiert und das Programm wieder geladen werden. Die Lizenzen sind bei mir wieder korrekt erkannt worden und alles läuft wie vorher (nur mit neuer Hardware). Vielen Dank an der Stelle noch mal an die schnelle Hilfe vom Support. Das hat wirklich top funktioniert.
Last updated: 2025-02-27

Post by fmon on Modbus : dis- / re-connect cable: modbus does not re-start ^{CODESYS Forge talk (Post)}
Hello, I am using codesys Modbus TCP client (4.4.0.0) to communicate with a python modbus server (package pyModbusTCP). I first start my python server on the distant machine. After a fresh codesys compilation, a plc connection/transfer and a PLC run, the modbus connection is OK. Every time in this context the connection is created correctly. When I shut down the server, the modbus connection falls, that is normal. When I restart the python server, impossible to recreate the modbus connexion. With the client autoreconnection, I see on my server that the client tries to connect but unsuccesfully. I have the following message : DEBUG:pyModbusTCP.server:accept new connection from ClientInfo(address='192.168.1.20', port=33476) DEBUG:pyModbusTCP.server:Exception during request handling: NetworkError('recv return null') I tried to stop the codesys client and to restart it with these commands : Modbus_TCP_Client.xStop := True; // Or False Modbus_TCP_Client.Enable := True; // Or False Modbus_TCP_Server.Enable := True; // Or False I tried to confirm the error manually to force reconnection with: Modbus_TCP_Server_Motors.xConfirmError := TRUE; I tried also this command to STOP/RESET/START client and server (codesys side) but nothing happens : status_client := Modbus_TCP_Client.SetCommunicationState(eRequestedState := DED.DEVICE_TRANSITION_STATE.STOP); // .RESET & .START The answer of this function when executed is "status_client = NOT_SUPPORTED" It seems that is a socket problem, but I do not understand if it is on the client or server side. I tried a modbus simulator called "ananas.exe" and the result is the same. Impossible to get a modbus reconnection. What is different at the first connection and at a reconnection attempt ? Thanks for your help
Last updated: 2025-03-14

Post by gilad on CODESYS SoftMotion Generic DSP402 on WAGO PFC200 + Festo CMMT-AS: MC_Power stays Busy, Controlword remains 0 ^{CODESYS Forge talk (Post)}
Hello, I am trying to connect a Festo CMMT-AS-C4-3A-MP-S1 servo drive to a WAGO PFC200 (750-8210) using EtherCAT and CODESYS SoftMotion. Hardware PLC: WAGO PFC200 750-8210 Drive: Festo CMMT-AS-C4-3A-MP-S1 Communication: EtherCAT CODESYS version: Device description version 6.3.1.1 Drive firmware: 36.10.3 Current Status EtherCAT communication is working correctly: EtherCAT master = Running Drive detected and operational PDO input and output mapping is active Statusword, position and velocity are updating correctly Current PDO mapping: Outputs: 6040 Controlword -> %QW0 6060 Modes of operation -> %QB2 607A Target position -> %QD1 60FF Target velocity -> %QD3 Inputs: 6041 Statusword -> %IW2 6061 Modes of operation display -> %IB6 6064 Position actual value -> %ID2 606C Velocity actual value -> %ID3 SoftMotion Axis I added a SoftMotion CiA402 axis under the EtherCAT slave: Axis type: SM_Drive_GenericDSP402 Axis communication state: operational (100) No SoftMotion mapping errors anymore Problem MC_Power is executed with: Enable = TRUE bRegulatorOn = TRUE bDriveStart = TRUE but: Status = FALSE Busy = TRUE Error = FALSE ErrorID = SMC_NO_ERROR The axis remains in: SMC_AXIS_STATE.power_off DSP402 state = SWITCH_ON_DISABLED The most important observation: Statusword = 32784 (0x8010) Controlword (%QW0) remains 0 all the time SoftMotion never writes 6, 7, or 15 to the Controlword. Additional Information The axis status page reports: "The license is missing or invalid. The PLC runs in demo mode." I am not sure whether: The missing SoftMotion license prevents Controlword generation completely. The axis is still not correctly connected to the EtherCAT slave despite operational communication. There is an additional CiA402 configuration step required for the Festo CMMT-AS drive. Has anyone successfully used a Festo CMMT-AS MP drive with CODESYS SoftMotion Generic DSP402 on a WAGO PFC200? Any suggestions on what should be checked next would be greatly appreciated.
Last updated: 2026-06-24

Post by dclements on Feature Request: Read-Only References / Pointer-to-Const Support ^{CODESYS Forge talk (Post)}
I would like to suggest adding support for persistent read-only references or pointers in CODESYS, similar to a C++ pointer-to-const (const T*). For example, something conceptually similar to: POINTER TO CONSTANT ST_MyData or REFERENCE TO CONSTANT ST_MyData The important distinction is that the reference itself may still be passed around or reassigned, but the referenced object cannot be modified through that reference. CODESYS currently supports VAR_IN_OUT CONSTANT, which provides read-only reference semantics for parameters, but there does not appear to be an equivalent type that can be stored in a variable or returned from a method. A practical use case is a registry that owns long-lived definitions. The registry needs to retain ownership of the data while downstream systems maintain persistent references to it. Currently, the main options are: Return the struct by value, which loses reference semantics and requires a copy. Return POINTER TO ST_Definition, which allows consumers to modify registry-owned data. Convert the structure into a Function Block and expose a getter-only interface, which provides the desired encapsulation but introduces more complexity and memory overhead. A read-only reference/pointer type would allow libraries to expose persistent, zero-copy access to internally owned data while preserving encapsulation. This would be particularly useful for library APIs and object-oriented CODESYS architectures where ownership of data should remain with one component while other components are allowed to observe it. Similar requests for constant references/pointers have been discussed on CODESYS Forge previously, so this appears to be a recurring use case rather than something specific to one application.
Last updated: 2 days ago

Post by kevinl on Weidmüller und u-OS bugs ^{CODESYS Forge talk (Post)}
Hallo zusammen Wir setzen mehrere Weidmüller UC20-WL2000 mit CODESYS Runtime und System-Bus ein und kämpfen seit einiger Zeit mit Problemen, für die wir bisher keine Ursache finden konnten. Aktuell beobachten wir zwei Phänomene: System-Bus Probleme Bei einer Anlage verlieren die I/O-Module sporadisch die Verbindung. Im Log erscheinen Meldungen wie: SLIO:CheckModule missing NotReachable Module Unplugged Nach diversen Updates (u-OS 2.7, aktuelle Runtime, aktuelles CODESYS) wurde das Verhalten eher schlechter statt besser. Anfangs traten die Fehler sporadisch auf, inzwischen funktioniert der System-Bus teilweise gar nicht mehr. Auch ein Downgrade auf eine ältere u-OS Version half nicht wirklich, aber ev ist es mit der aktuellen Runtime nicht kompatibel. Probleme nach Spannungsunterbruch / Neustart Mehrfach hatten wir bereits den Fall, dass eine Steuerung nach einem Spannungsunterbruch oder Neustart nicht mehr vollständig hochkommt. Teilweise startet die CODESYS Runtime nicht mehr (vermutlich aufgrund von Problemen mit Persistent-Daten), in einem aktuellen Fall ist zusätzlich das u-OS Backend nicht mehr erreichbar. Die Welcome-Seite erscheint noch, beim Login läuft der Request jedoch in einen 504 Gateway Timeout. Hardware: UC20-WL2000 u-OS 2.x System-Bus mit mehreren UR20 Modulen CODESYS Control SL Runtime Mich würde interessieren: Hat jemand ähnliche Erfahrungen mit UC20-WL2000 oder u-OS gemacht? Gibt es bekannte Probleme mit dem System-Bus? Gibt es Workarounds bezüglich Persistent-Daten oder Recovery nach Spannungsunterbruch? Hat jemand ähnliche 504-Fehler im u-OS Backend gesehen? Vielen Dank für jeden Hinweis.
Last updated: 2026-06-05

Post by kurtk on SysProcess Execute Command unable to run commands with special characters ^{CODESYS Forge talk (Post)}
Thank you for this additional information. Could you please provide the references to the official documentation where you found this information ? I got as far as: Then insert this: [SysProcess] BasePriority=Realtime Command=AllowAll devoid of references of where the CodesysContol.cfg file was located or of the need to run codesys as root I incrementally located bits of information with perplexity searches but remained mired at error 25 ERR_NO_ACCESS I am curious whether root access is MANDATORY to run SysProcessExecuteCommand (- and/or any other SysProcess functions) or if a more access-constrained User=quasiroot could suffice without the security concerns ? Apparently codesys runs fine without User=root for almost everything... That raises the question: What IS the default codesys user ? I notice in the prototypes: VAR sCommand : STRING := '/usr/bin/whoami'; sOutput : STRING(255); refCommand : REFERENCE TO STRING; refOutput : REFERENCE TO STRING; resultCmd : UDINT; END_VAR whenever I attempt to build this Codesys v3.5 SP2 whines that "cannot convert type REFERENCE TO STRING to STRING" don't remember the exact message... Apparently this happens whenever a fixed-length string is involved. if I get rid of (255) and just set the string := ' '; that is sufficient to make the compiler happy. Is this a recently enforced constraint ? Why does this compile for you and not for me ? There are references to functions / utilities which are used/needed to massage the string references - but I see no specific details... I also notice you specify: Make sure the lib SysProcessImplementation, SysTypes, and CmpErrors is on the project. I don't comprehend why all of the dependent libraries are not automatically referenced, added ? I don't recall seeing anywhere but here that SysProcessImplementation must be included... It just seems odd that the default is to exclude essential libraries, or require alchemical conjuring to assemble all the ingredients for gnat soup ;-) Thanks a lot... I'm still a codesys newby getting my wheels on - or sometimes just partially on
Last updated: 2025-09-12

Post by rkohser on Scripted Git clone / checkout being blocked by "Project Environment" popup ^{CODESYS Forge talk (Post)}
Hi, I am trying to build a CI/CD pipeline around our codesys projects. The only entry point if the git url and branch, as we do not put our project file under source control, so we needed to find a way to git clone from the python scripting engine. This is currently how we do this : system.commands["Git", "Clone"].execute( "ProjectLocation=" + project_dir, "ProjectName=" + project_file_name, "RemoteUrl=" + project_git_remote_url, "GitProjectStoragePath=" + project_git_local_dir, ) system.commands["Git", "Checkout", "Branch"].execute( "PrimaryProjectHandle=0", "BranchName=origin/" + project_git_branch ) This works fine, except that, depending on the environment and the project, the "Project Environment" popup gets displayed to suggest for some updates, and waits for a user interaction, even with the "--noUI" flag injected as parameter. I investigated the VersionUpdateFlags, but the problem is that the git clone is an atomic operation that clones and directly opens the generated project without the possibility to inject any updateFlags argument (only used in the ScripProjects.open() function. I also tried to simulate some keyboard events acknowledge the window from script but I did not find the right location for the SendKeys statement, I think before the git clone call is too early and after is too late. So I am wondering if there would be some other way to do that. Is there some more proper scripting api for the git add on ? Is there a global configuration of the VersionUpdateFlags that would allow the popup to be disabled outside from any project context ? Is there some way to automatically acknowledge this kind of messages in a "--noUI" mode ? What do you suggest ? Thanks for your help, Roland Edit : I managed to solve my problem by following these steps in my pipeline : - create a template of a project and opt file preconfigured not to open the popup - open this project - initialize an empty git repo - add the remote, fetch and checkout the needed branch -> no popup is displayed, hourra Edit2 : The initial question was raised on a CODESYS V3.5 SP18 Patch 2 profile. Since CODESYS 3.5.19.30 a scripting API is available for Codesys Git that allows cloning a project with the support of VersionUpdateFlags https://content.helpme-codesys.com/en/CODESYS%20Git/_git_using_scripting.html
Last updated: 2024-01-19

Post by axberry 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)}
Hi, I'm trying to run CODESYS Control for Raspberry Pi SL on a Raspberry Pi 5, and the runtime consistently fails to start with the following error when launched manually: ooops... this runtime was built for RASPBERRYPI. Hardware version or firmware version not supported! (-18, 0x00000BB8, 0xFFFFFFFB) Hardware: Raspberry Pi 5 Model B Rev 1.1 Revision code: d04171 CPU: aarch64, BCM2712 Serial number is correctly exposed via /proc/cpuinfo and /proc/device-tree/serial-number /proc/device-tree/model correctly reports "Raspberry Pi 5 Model B" What I've tried (all resulting in the same error): CODESYS Control for Raspberry Pi SL 4.11.0.0 (SDK 3.5.19.61) — the version that introduced Pi 5 support CODESYS Control for Raspberry Pi SL 4.21.0.0 (SDK 3.5.22.20) — latest available Raspberry Pi OS Bookworm (64-bit) with kernel 6.12.93+rpt-rpi-2712 (June 2026 build) Fresh install on Raspberry Pi OS Bookworm (64-bit) with an older image from November 24, 2025 — same error, ruling out a kernel-version regression Bootloader/EEPROM confirmed up to date (rpi-eeprom-update reports "up to date") Clean purge and reinstall of the codesyscontrol package each time (verified via dpkg -l, no leftover files) Verified /etc/codesyscontrol/3S.dat correctly symlinks to /etc/codesyscontrol/3S_aarch64.dat The service starts (systemctl status briefly shows active (running) with a real PID under /opt/codesys/bin/codesyscontrol.bin), but crashes shortly after and the process disappears — port 11740 never opens. Since this happens identically across two different runtime versions and two different OS images (5+ months apart), it doesn't seem to be a kernel/firmware timing issue. Could this be specific to the Rev 1.1 board revision, or is there a known issue with the hardware detection logic in the SL runtime that I should be aware of? Happy to provide full debug logs (-d flag output) or journalctl output if useful. Thanks in advance!
Last updated: 2026-08-10

Post by danp1406 on Question about Demo License limitations for Modbus TCP communication and Fieldbus Instances ^{CODESYS Forge talk (Post)}
Hello everyone, I am currently working with CODESYS Virtual Control for Linux running in Docker on a Debian virtual machine. I am deploying my application using Deploy Control SL, and in my project I am using the ModbusFB library to implement Modbus TCP communication. My setup is the following: I am trying to establish a Modbus TCP connection between a virtual PLC (CODESYS acting as Modbus TCP Client/Master) and a Siemens S7-1200 PLC acting as a Modbus TCP Server. From the Debian VM, I can successfully ping the S7-1200 and verify that port 502 is open using tools like nc. Network-wise, everything appears to be correct. However, when running the application in CODESYS, I receive messages such as “Demo mode for Modbus/TCP Master started. Will expire and stop!” and socket errors like “ClientSocket.UpdateStatus socket error 111 disconnecting.” The ClientTCP block from the ModbusFB library attempts to connect, but the connection does not remain stable. My main question is whether the CODESYS demo license explicitly limits or interrupts Modbus TCP Master communication. Is it expected that in demo mode the runtime will automatically close sockets after some time or prevent stable Modbus TCP connections? I would like to confirm whether this behavior is normal when using ModbusFB in demo mode, or if I should continue troubleshooting the configuration. Additionally, I would like clarification regarding the “fieldbus instances” mentioned in CODESYS licensing options (for example, 2, 4, or 16 instances). What exactly is considered one fieldbus instance? Does one Modbus TCP Client block count as one instance? Does each active connection to a different device count separately? Do Modbus TCP Master and Server count independently toward the total number of instances? Finally, I would appreciate clarification on any other practical limitations of demo mode when using industrial communication libraries such as ModbusFB. Are there limits on the number of connections, number of requests, or communication duration? I am trying to determine whether demo mode is sufficient for testing a virtual PLC communicating with a Siemens S7-1200 over Modbus TCP, or whether a full license is required even for this kind of validation scenario. Thank you in advance for any guidance.
Last updated: 2026-02-25

Post by jinlee on Dynamic I/Os Mapping ^{CODESYS Forge talk (Post)}
Hi guys, Recently, I am working at the Dynamic I/Os mapping feature in Ecockpit or Codesys v3.5. I have been trying the libraries. However, it looks like it will not work as I wanted. I want to build the PLC which can detect all the I/Os itself and from there, I can do something on these channels. For example, the current setup is one digital input card, one digital output card and one analogue input card. Then, I want to add one more card into the setup e.g. one more digital input. Then, wago screen can detect this and we can assign them to tasks for example to control digital output. May I know is it possible ? Kind regards
Last updated: 2023-08-18

Post by ggarcia94 on CANOPEN SDO configuration ^{CODESYS Forge talk (Post)}
Hello, I´m connected to two drives via CANOPEN. The connection seems to be ok. However, I´m not able to get the PDOs to work even tho they are configured as in the manual of the drives. Looking at the SDOs I´ve seen that for each PDO there is a "Disable PDO" SDO that does not exist in the manual or in the EDS file of the drives. This "Disable PDO" signal has the same Index and Subindex as another SDO used to set and enable the COB-ID of the PDO. I´m assuming this is normal but why is Codesys creating a "Disable PDO" SDO for each PDO and could that be the reason the PDOs are not working?
Last updated: 2023-09-25

Sort by relevance or date