Post by rmaas on Fieldbus has lost synchronicity ^{CODESYS Forge talk (Post)}
Hi, On a gantry system with 2 axis i am getting the following error: SMC_DI_FIELDBUS_LOST_SYNCRONICITY This happens random, sometimes it happens every 5 minutes and sometimes no error for 2 hours... The Setup: - Using codesys 3.5 SP20 with all latest libs... - Kontron AL Pi-Tron CM4 with Preempt realtime patch (Raspberry Pi 4) - Codesys runtime 4.11.0.0 (single core) - CODESYS Control for Raspberry Pi SL licensed - Softmotion + CNC + Robotics licensed - 2x Leadshine EL8-EC400 servo drives - Axis group for a 2-axis T-Gantry Ethercat network wiring: Ethercat master softmotion -> Beckhoff EK1100 -> Servo drive #1 -> Servo drive #2 Ethercat Cycle time = 4ms Max Jitter = 140~150 What i have tried so far: - changed the sync offset from 20% to 30% - changed ethercat task priority from 1 to 0 Running tasks: - Ethercat tast: Prio = 0, Interval = 4ms - Main task: Prio = 1, Interval = 8ms - Visu task: Prio = 31, Interval = 100ms - Softmotion planning task: Prio = 15, Freewheeling - 3 other default tasks that were created by AC_Persist Motion fb's are called in the ethercat task... Does anyone have an idea how to fix this? Any help is greatly appreciated!
Last updated: 2024-04-11

Post by leafy on Use third party actuator with IO-Link Master (IFM) ^{CODESYS Forge talk (Post)}
Hey there! I am currently doing a little automation project for uni. I am trying to integrate a control-valve-system (Buerkert AirLINE Field) in my IO-Link environment. With IFM sensors, I used their pre-built function blocks, but with this third-party device, i need to write my own function block. Thankfully, IFM provides a generic sensor-fb so I can write my own FB with "extends" and "super". So far, so good. I found the IODD and some other documentation and I thought I get how it works, but somehow can't really get it to work at all. From my understanding, i need to write data into the PDO-Array. But i get confused with the indices and subindices of IO-Link. I'll append the IODD and some screenshots of my project. There is an AOI for LogicXDesigner, but I can't use that in Codesys. I hope someone has integrated a IOL-device in Codesys before and can help me with this. Cheers leafy
Last updated: 2024-04-16

Post by leafy on Use third party actuator with IO-Link Master (IFM) ^{CODESYS Forge talk (Post)}
Hey there! I am currently doing a little automation project for uni. I am trying to integrate a control-valve-system (Buerkert AirLINE Field) in my IO-Link environment. With IFM sensors, I used their pre-built function blocks, but with this third-party device, i need to write my own function block. Thankfully, IFM provides a generic sensor-fb so I can write my own FB with "extends" and "super". So far, so good. I found the IODD and some other documentation and I thought I get how it works, but somehow can't really get it to work at all. From my understanding, i need to write data into the PDO-Array. But i get confused with the indices and subindices of IO-Link. I'll append the IODD and some screenshots of my project. There is an AOI for LogicXDesigner, but I can't use that in Codesys. I hope someone has integrated a IOL-device in Codesys before and can help me with this. Cheers leafy
Last updated: 2024-04-16

Post by fontrap on cmDongle Raspberry Pi issue ^{CODESYS Forge talk (Post)}
Hello mates, I'm working with CODESYS V3.5 SP20 on a Raspberry Pi and I use "Raspberry Pi MC SL" as device on the project. I've installed the Control Standard L (multicore) license on a Wibu System usb-Dongle (cmStick/4.50) that already had another license from another vendor. I follow the online activation procedure from CODESYS documentation. Raspberry Pi has already CodeMeter installed for the other license. When I plugin the dongle on Raspberry and start the Runtime from Raspberry Pi Update in CODESYS I receive the message that I'm on Demo mode because the license is missing. I double checked that the license is activated in the dongle, through the WebAdmin of CodeMeter and the second license runs properly without any issue. I have already try to change the dongle from HID to MSD device and backward but the the Runtime cannot recognize the Dongle. I have also try to stop and start the Runtime through CODESYS without success. Is there anything else I can do to fix this issue?
Last updated: 2024-04-22

Post by timvh on Toradex and CODESYS and licensing ^{CODESYS Forge talk (Post)}
For the Virtual Control you need to use a "Network license". The Virtual Control has parameters of which one is the reference to the license server. This can be the device itself, but you need to activate the license on the host system (not in the container). For this, CODESYS has a Network License server with WBM (web based management). See for the Network License configuration: https://content.helpme-codesys.com/en/CODESYS%20Control/_rtsl_license_controller_linux.html If it is only for evaluation, I would advise to use a CODESYS (USB) key and activate the license on the key. Then you still have to install the CODESYS Network License server on the host, but you don't have to activate the license as soft license on the device. The benefit is that you can easily move your license to another device when needed. Off course your device must have a free USB port available to be able to do this.
Last updated: 2025-10-20

Post by nixola on CmpCharDevice blocks gpiochip access on Raspberry Pi 5 since update from SP18 to SP21 ^{CODESYS Forge talk (Post)}
Hi, I added the following lines to /etc/codesyscontrol/CODESYSControl_User.cfg: [CmpCharDevice] PermittedPath.0=/dev/i2c* PermittedPath.1=/dev/spidev* PermittedPath.2=/sys/class/gpio/* PermittedPath.3=/dev/gpiochip* However, I'm still unable to read or control GPIO pins from any CODESYS application. Specifically, setting the pin direction (and, thus, the IoDrvGpioSysfs driver configuration) fails, with a rather non-descript error in the logs: Description Component Setting direction failed for GPIO pin 586 IEC Update configuration failed from driver IoDrvGPIOSysfs CmpIoMgr I'm running CODESYS Control for Linux ARM64 SL version 4.21.0.0; it's running in rootless mode, as the codesyscontrol user, but said user is in the gpio group and can otherwise normally interact with GPIO, both via gpioset/gpioget and via the sysfs driver in /sys/class/gpio/. The system is a custom 64-bit Raspberry OS based distro, running on a Raspberry Pi CM5 on kernel 6.18.34 with PREEMPT_RT scheduling.
Last updated: 2026-07-21

Post by animesh on SoftPLC (CODESYS Control x86 RTE V3 x64) OPC UA binds only to 127.0.0.1 — Not binding to LAN IP ^{CODESYS Forge talk (Post)}
Hello everyone, I am facing a persistent issue with the OPC UA Server on Advantech Soft PLC with hard realtime for Win64 (V3_5_2010_3) and need help from the community. Device Information Name: Advantech Control x86 RTE V3 x64 Vendor: Advantech Co., Ltd. Categories: PLCs Version: 3.5.20.10 Description: Advantech Soft PLC with hard realtime for Win64 (V3_5_2010_3) Problem Summary The OPC UA Server works perfectly when accessed via: opc.tcp://localhost:4842 opc.tcp://<hostname>:4842</hostname> But it does NOT work when using the LAN IP: opc.tcp://192.168.0.XX:4842 In UAExpert I get: Discovery FindServers on opc.tcp://192.168.0.XX:4842 failed (BadCommunicationError) Port is LISTENING in windows Firewall.. Tried with turning off the firewall completely. System Information Windows 10 x64 Advantech CODESYS RTE Soft-PLC (hard real-time) Network IP: 192.168.0.XX Hostname: WINDOWS-XXXXX Need your Support
Last updated: 2025-11-24

Post by fredashbolt on Dynamically Update JSON Payload ^{CODESYS Forge talk (Post)}
I am trying to generate a JSON payload populated with a value that updates for use with a telemetry system, the payload is to be published by MQTT. I have established the MQTT client and can publish a working JSON payload but I can't get the payload to update as the value (iValue) changes. I am using a timer to trigger the .SetValue function periodically, but the JSON will only give the value as it is when it is first initialized using xFirst IF statement. Any suggestions? Thanks VAR pJsonData : POINTER TO JSON.JSONData := factory.Create(); fb_JBuilder : JSON.JSONBuilder; diRootIndex, diObject1Index : DINT; iValue : INT := 10 ; jsonArrayWriter : JSON.JSONByteArrayWriter; wsJsonData : WSTRING(1000); xFirst : BOOL := TRUE; utf8JsonData : STRING(2000); diTempVal : DINT ; PublishTimer : TON ; END_VAR IF xFirst = TRUE THEN fb_JBuilder ( pJsonData := pJsonData , diRootObj => diRootIndex ) ; diObject1Index := fb_Jbuilder.SetKeyWithObject ( "Device" , diParentIndex := diRootIndex ) ; diTempVal := fb_Jbuilder.SetKeyWithValue ( "Temp" , iValue , diParentIndex := diObject1Index ) ; xFirst := FALSE ; END_IF PublishTimer ( IN := PublishTimer.Q = 0 , PT := T#5S ) ; IF PublishTimer.Q THEN fb_JBuilder.SetValue ( iValue , diTempVal ) ; END_IF jsonArrayWriter( xExecute := PublishTimer.Q , pwData := ADR(wsJsonData), udiSize := SIZEOF(wsJsonData), jsonData := pJsonData^, xAsyncMode := FALSE ) ; JSON.Stu.ConvertUTF16toUTF8( ADR ( wsJsonData ) , ADR ( utf8JsonData ) , SIZEOF ( utf8JsonData ) , bStrictConversion := TRUE ) ;
Last updated: 2026-03-10

Post by meke001 on Visualisierungswerkzeuge ^{CODESYS Forge talk (Post)}
Hallo zusammen, ich habe ein hartnäckiges Problem mit der CODESYS-Visualisierung und hoffe auf eure Expertise. In meinem Projekt wird die Toolbox ("Werkzeuge") für die Visualisierung komplett leer angezeigt, es lassen sich also keine Basis-Elemente wie Rechtecke oder Kreise in die Zeichenfläche ziehen. Mein System: CODESYS V3.5 SP22 Patch 2 (64-bit) Device / Compiler-Version: 3.5.22.20 Das Kuriose:Das eigentliche Projekt läuft absolut einwandfrei. Mein Programmcode lässt sich ohne Probleme übersetzen, die SPS-Logik funktioniert fehlerfrei und auch die Simulation läuft einwandfrei durch. Nur das "Gesicht" des Projekts fehlt. Zwischendurch tauchte in den Meldungen der Fehler auf: Die Bibliothek '#System_VisuElems' konnte nicht aufgelöst werden. Was ich bereits zur Fehlerbehebung versucht habe: Installer-Check: Im CODESYS Installer geprüft, ob das Add-on "CODESYS Visualization" installiert ist (ist vorhanden und aktiv). Profil erzwungen: Im Visualisierungsmanager das Visualisierungsprofil manuell auf die aktuellste Version gesetzt. Gerät aktualisiert: Das Device im Projektbaum per Rechtsklick sauber auf die Version 3.5.22.20 hochgezogen. Clean Build: Mehrfach "Alles bereinigen" ausgeführt und neu übersetzt. Neues Projekt: Selbst wenn ich ein komplett neues Standardprojekt anlege, fehlen die Werkzeuge in der Visualisierung weiterhin. Hat jemand von euch eine Idee, woran das noch liegen könnte? Gibt es unter Windows eventuell einen versteckten Cache-Ordner für die Visualisierungs-Bibliotheken, den man manuell leeren muss? Für jeden Tipp wäre ich sehr dankbar! Viele Grüße
Last updated: 2026-06-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 megasilver on Cannot download program to CR1074 – Version mismatch error ^{CODESYS Forge talk (Post)}
Hello, I am having a problem downloading my application to an ifm CR1074 using CODESYS. When I try to download the program to the controller, I get the following errors: [FATAL ERROR] Version mismatch at: 'KEYBOARD_SET_MAPPING' Requested version: 2.0.0.12 Implemented version: 3.4.0.0 [FATAL ERROR] Version mismatch at: 'SYSCFG_SPLASH_SET_SPLASH_SCREEN_VISIBLE' Requested version: 2.0.0.12 Implemented version: 3.4.0.0 [FATAL ERROR] Version mismatch at: 'SYSTEM_IO_BACKLIGHT_SET_CURRENT_BACKLIGHT_BLOCKING' Requested version: 2.0.0.12 Implemented version: 3.4.0.0 [FATAL ERROR] Version mismatch at: 'SYSTEM_IO_BACKLIGHT_SET_CURRENT_BACKLIGHT' Requested version: 2.0.0.12 Implemented version: 3.4.0.0 [FATAL ERROR] Version mismatch at: 'KEYBOARD_RESET_LEDS_BLOCKING' Requested version: 2.0.0.12 Implemented version: 3.4.0.0 [FATAL ERROR] Version mismatch at: 'KEYBOARD_SET_LED_COLOR' Requested version: 2.0.0.12 Implemented version: 3.4.0.0 [FATAL ERROR] Version mismatch at: 'SYSCFG_DEVINFO_GET_KEYBOARDS_INFO' Requested version: 2.0.0.12 Implemented version: 3.4.0.0 The controller is running an OS version that should be compatible with CODESYS 3.5 SP16, and I am using the latest available ifm/ecomatDisplay package for this OS version. Therefore, I do not think this is simply a CODESYS or OS compatibility issue. It looks like the application expects system functions with version 2.0.0.12, while the controller implements version 3.4.0.0. Could this be caused by an incorrect or outdated library, device description, package installation, or a mismatch between the libraries used in the project and the libraries installed on the CR1074? What would be the correct way to identify which component is requesting version 2.0.0.12 and how can I resolve this version mismatch? Thank you for your help.
Last updated: 2026-08-21

Post by pernockham on Gateway in China - "Gateway not connected" ^{CODESYS Forge talk (Post)}
Some new test. Now I cannot connect from Automation server to my gateway in any way also from my office setup with my unit directly connected to my router by dhcp. I can use the IDE and the tool "Connect Edge Gateway" and successfully connect to my server/link to my Automation server account. However no PLC will respond from Automation server "Network scan". I guess the traffic should be initiated by the gateway towards automation server? Any tips on how I can diagnose my problem? Ports to be opened etc? Thing is that this has been working previously but not now (base system has been updated from debian 12 to debian 13, but I dont know at which point it has stopped working). Setup as before. A "Codesys Control for Linux SL" running on a debian 13 installation. Any help/tips appreciated! Per Update. Found the error. Had a wrong gateway-setting. Which meant the PLC could not reach internet. Checked by "ping google.com" from the PLC.
Last updated: 2026-02-12

Post by risele on Modbus connection via Qronox PCD3 M6893 ^{CODESYS Forge talk (Post)}
You are welcome. Also note, that it's valid only if you modbus-device use same real/float value representation (IEEE 754). That's true for most of systems. But some devices may have other representation, such as integer + position of the decimal point, for example 123.456 is integer = 123456 and position = 3 Also note, that, ones again, depending on endianess of each system, you may also need to swap not just words, but bytes. TYPE u_Real : UNION rVal:REAL; wVal:ARRAY[0..1] OF WORD; bVal:ARRAY[0..3] OF BYTE; dwVAL:DWORD; //same as previous, may be easier to specify the MB register END_UNION END_TYPE than swapping may be something as VAR A,B,C,D:BYTE; //Bytes of the real value uIn, uOut:u_Real; rVal:REAL; ModbusReg1,ModbusReg2:WORD; END_VAR uIn.rVal:=rVal; uOut.A:=uIn.D; uOut.B:=uIn.C; uOut.C:=uIn.B; uOut.D:=uIn.A; ModbusReg1:=uOut.wVal[0]; ModbusReg1:=uOut.wVal[2]; Or you even need to reorder bits... Ones again, sending float/real values is not defined by Modbus protocol itself, so it is hardware- and software-dependent. The Modbus Poll (and most of modbus tools) have configuration parameters that will properly swap bytes on their side. Ones again, that's very helpful: https://www.scadacore.com/tools/programming-calculators/online-hex-converter/
Last updated: 2026-02-19

Post by darwin03 on Mismatch between coordinate monitor and actual motion using SMC_GroupJog2, MC_MoveLinearAbsolute (6DOF) ^{CODESYS Forge talk (Post)}
Hi Georg, Thank you very much for your help and for taking the time to look into my issue! After reversing the directions of A2 and A3, the robot now moves correctly according to the coordinate system. That solved the main issue with the joint rotation directions. However, I still have two issues: When I command the robot to move along the X, Y, and Z axes, the movement seems slightly off, and the trajectory appears somewhat diagonal instead of following a straight line along the commanded axis. The A6 axis also rotates during the movement, whereas I would expect it to maintain its orientation and remain unchanged. Do you have any suggestions on how I could correct the Cartesian linear movement and keep A6 fixed during the motion? Thank you again for your support! Best regards, Darwin Video link: https://drive.google.com/file/d/1tnokDYoNUEDy--eQtX_JZavMVSn-a9Le/view?usp=sharing
Last updated: 2026-10-15

Post by struccc on Wish: CODESYSControl.cfg - again ^{CODESYS Forge talk (Post)}
Before creating this topic, I was browsing the search results for CodesysControl.cfg - many results, and I remember very well, it's a problematic issue for a long time. To summarize: there were many requests for documentation on this file - the most comprehensive reply is: https://forge.codesys.com/forge/talk/Runtime/thread/ebbf851a3d/#eb85 Hi, not really, this is covered by the manual which you get if you use a runtime toolkit which is not free of charge. Maybe we need to extract the config file part from that documentation if that is possible. BR Edwin I am not sure how much is this relevant, since we buy SL License directly from CODESYS... I think it is a reasonable demand, to get documentation on the configuration entries affecting the documented behaviour of the runtime system and it's components The actual reason I bring up this issue again can be read here: https://forge.codesys.com/forge/talk/Runtime/thread/febad3cc40/#0e12 but mostly my frustration about noticing some new, unknown and undocumented entries in my configuration file. Again. And this happens a lot recently. Just some examples: Changes with SysFile - and mandatory use of IEC path Introduction of Mandatory user management File transfer service now disabled by default SysProcess - allowed commands The above mentioned CmpApp parameters... And finally (Regaridng windows install): With the newer versions, the installation directory (together with the configuration file) tends to hide itself to some super silly location under the roaming profile data of local system account. I am not sure if this change was documented somewhere, but was a very unpleasant one. Someone could please explain the reason and the concept of the introduction of this release specific directories (I am sure, there is a good reason) - how to use them properly? - How to re-introduce user configuration (to preserve configuration data between versions)? - How to do version - to version migrations properly? - How to keep old version of runtime available and ready to start with it's original configuration and application? - ... Therefore, the lack a regularly updated description of CodesysControl .cfg , including all the configuration entries, together with their default values for different runtime versions is really a big deficiency.* This should be done for all components storing or just seeking data from this file... (Maybe there is such thing but I failed to find???) It is regularly causing trouble when introducing a new version (together with the long awaited bug fixes and enhancements), what has changed it's default behaviour for security or other practical reasons. I agree this is very important, and it is logical to change the default options: But it must be documented historically, and make it easily available, so we can prepare better for the upgrade of the runtime. Forge talk is a great source, but not very practical for this kind of documentation purposes... Thanks in advance for CODESYS staff 🙏🙏🙏 (Ps.: It would look rather silly, if some members of the user community prepares this documentation on a Forge Wiki page... Or??? Should we?)
Last updated: 2024-11-21

Post by kuegerls on PROFINET Controller SL: WRREC remains BUSY forever, no DCE/RPC packets transmitted (RevPi Connect 5 + NORD SK205E) ^{CODESYS Forge talk (Post)}
Hello , I am currently evaluating the CODESYS PROFINET Controller SL on a Revolution Pi Connect 5 and have encountered a problem with acyclic PROFINET Record Access (WRREC/RDREC). System Hardware: Revolution Pi Connect 5 Runtime: CODESYS Control 4.16.0.0 (SDK 3.5.21.10) Development System: CODESYS V3.5 SP21 (64-bit) CommFB: 3.5.17.10 ProfinetCommon: 4.6.0.0 PROFINET Controller Device: PN-Controller 4.6.0.0 PROFINET Device: NORD DRIVESYSTEMS SK205E with SK TU4-PNT GSDML: GSDML-V2.46-NORDDRIVESYSTEMS-PNT-20251016.xml Network The PROFINET network is completely separated from the office network. RevPi: eth0 → Office network eth1 → PROFINET wlan0 → Visualization The PN Controller is configured to use eth1. IP configuration: RevPi (eth1): 192.168.100.1/24 NORD Drive: 192.168.100.3 Connection is established successfully. Current Status The PN Controller reports: Controller Status = Run Online = TRUE IP Active = TRUE Connections = 1 Cyclic PROFINET IO communication works correctly. Problem I am trying to access PKW parameters via WRREC (Record Index 100). The request buffer contains: 01 14 00 04 92 00 00 00 00 00 00 which corresponds to Reference = 0x01 Request = Read Axis = 0 Parameter = 170 + 1000 Subindex = 0 Value = 0 The WRREC call is fbWRREC( REQ := xWrReq, ID := ConnectionID, INDEX := 100, LEN := 11, RECORD := ADR(TxBuffer) ); REQ is pulsed for one PLC cycle only. Observed Behaviour WRREC enters BUSY state and never finishes. Observed values: BUSY = TRUE DONE = FALSE ERROR = FALSE STATUS = 16#FFFFFFFF indefinitely. Packet Capture A Wireshark capture was taken on the PROFINET network. Observed traffic: PROFINET RT LLDP DCP Observed: successful cyclic IO Not observed: DCE/RPC Record Write Record Read RPC Bind No RPC packets are transmitted at all. Diagnostic Messages The controller repeatedly reports AR alarm.ind(err) AR CMI timeout although cyclic IO communication continues to work. Already Verified The following points have already been checked: correct Ethernet interface (eth1) correct CREATE_ID result correct Device ID correct Slot/Subslot correct GSDML correct REQ pulse RECORD buffer is larger than LEN cyclic IO communication works different Record Indices (100...104) tested Question Is there any known issue or limitation where WRREC/RDREC requests remain permanently BUSY and no RPC Record Access packets are generated? Could this behaviour be related to Runtime 4.16.0.0, PN Controller 4.6.0.0, the missing runtime license (currently running in demo mode), or any known issue with the PROFINET Controller SL? I am currently evaluating the PROFINET Controller SL and therefore the runtime is operating in demo mode. Could you please confirm whether WRREC/RDREC (acyclic Record Data services) are fully supported in demo mode, or whether a valid license is required for these services? If required, I can provide: complete project archive Wireshark capture (.pcap) GSDML online screenshots diagnostic log Thank you very much for your help. Best regards, Stefan
Last updated: 2026-07-17

Post by maldus512 on How to adapt Codesys Control SL to custom board ^{CODESYS Forge talk (Post)}
Hello everyone, I have been given the task to develop I/O drivers for a custom made, Linux based board to allow for Codesys applications to run and control the hardware. I have successfully installed Codesys Control SL for ARM/Linux and tested it with a simple demo application. Now I should start interfacing the runtime to the actual hardware; I should be able to interact with 2 RS485 serial ports, a few GPIOs and an I2C port, all of which already have the corresponding /dev/ interface in the Linux system. I am having trouble understanding how it should be approached. I have found sporadic references that fail to lead to a really comprehensive documentation. For example: The store page (https://store.codesys.com/en/codesys-control-for-linux-arm-sl-1.html#options) mentions a "runtime package" that should allow "Integration of existing C code" and "Usage of local I/Os", which seems exactly what I need to interact with custom peripherals. I have found no further reference to Codesys-C interpop. The Codesys Help page for the runtime package has a page on the "Development of Drivers" (https://content.helpme-codesys.com/en/CODESYS%20Control/rtsllinuxrbpdriverdevelopment.html) that suggests to either "Implement a function block" or "Implement I/O drivers". Those in turn lead to this page (https://forge.codesys.com/drv/io-drivers/doc/Generic/) which describes briefly an XML schema to describe new devices; unfortunately, it doesn't mention what to do with such a description (i.e. how does the runtime know about it) or how it is in any way connected to the actual hardware. Could anyone give me some pointers? I should also mention I have no prior experience with Codesys, so maybe I'm missing an obvious answer.
Last updated: 2024-08-09

Post by jeffg on ERROR: GetNetLinkSockAndInfoByMac(): could not open netlink socket: Too many open files ^{CODESYS Forge talk (Post)}
I just installed codesys runtime on a raspberry pi Cortex-A72 (ARM v8) 64-bit SoC @ 1.5GHz (Compute Module 4) I am running on Codesys control for raspberry pi 64 SL ver 4.13.0 and I keep getting a crash after about five to ten minutes. This program was running fine on a 32bit system with runtime 4.8 previously but they upgraded the panel PC cause it got smashed. Looking at the logs I see this error "ERROR: GetNetLinkSockAndInfoByMac(): could not open netlink socket: Too many open files" at the time of crash. I do have a UDP socket open for a serial to ethernet adapter and im wondering if maybe its opening a bunch of sockets and while receiving messages, Im not sending anything to the device only receiving. Below is the code used for the UDP VAR // Scale Comm fbPeerServer : NBS.UDP_Peer; ipAddress : NBS.IPv4Address; fbReceive : NBS.UDP_Receive; xPeerActiv : BOOL := TRUE; abyReceive : ARRAY [0..255] OF BYTE; sLastValidReceive : STRING(255); udiIndex : UDINT; END_VAR IF xPeerActiv AND NOT fbPeerServer.xBusy THEN ipAddress.SetInitialValue(ipAddress := gvlSettings.sIPAddres); fbPeerServer(xEnable := TRUE, itfIPAddress := ipAddress, uiPort := gvlSettings.uiPort); END_IF fbPeerServer(); fbReceive(xEnable := fbPeerServer.xBusy, itfPeer := fbPeerServer, pData := ADR(abyReceive), udiSize := SIZEOF(abyReceive)); IF fbReceive.udiCount > 0 THEN IF fbReceive.udiCount < SIZEOF(sLastValidReceive) THEN SysMem.SysMemCpy(pDest := ADR(sLastValidReceive), pSrc := ADR(abyReceive), udiCount := fbReceive.udiCount); // Set End of String sLastValidReceive[fbReceive.udiCount] := 0; END_IF END_IF If anyone as seen this I could really use some help figuring it out. I included the Log report
Last updated: 2024-09-19

Post by gorditron on I2C Communication with ^{CODESYS Forge talk (Post)}
Hello, I have problems with the I2C communication to an ADS7828 AD converter. I don't get any value back from the chip. I use a Kontron chip (ARM 32SC) with Linux as the operating system. I also use the CmpCharDevice library. ADS7828 parameters Address: A1 = 0 / A0 = 0 = SD = 1 = Single End C2 = 0 / C1= 0 / C0= 0 / Channel 0 PD1 = Internal Reference and PD0 = AD Converter ON Here is my code: VAR b_i2cAdr : BYTE := 16#48; (* Standard I2C-Adresse des ADS7828 *) x_Init: BOOL;(* Flag für die Initialisierung *) b_config_byte: BYTE;(* Konfigurationsbyte für den ADS7828 *) ab_cmd_buffer : ARRAY [0..0] OF BYTE; (* Buffer für den Befehl *) ab_data_buffer : ARRAY [0..1] OF BYTE; (* Buffer für die empfangenen Daten *) ui_adc_value_1 : UINT; (* Ausgelesener ADC-Wert *) I2C_Handle: RTS_IEC_HANDLE; (* Handle für das I2C-Device *) di_result_open: DINT;(* Ergebnis der Funktionsaufrufe *) di_result_adr: DINT;(* Ergebnis der Funktionsaufrufe *) di_result_wr_cmd: DINT;(* Ergebnis der Funktionsaufrufe *) di_result_rd_cmd: DINT;(* Ergebnis der Funktionsaufrufe *) di_result_close: DINT;(* Ergebnis der Funktionsaufrufe *) END_VAR //*** Init from the I2C communication port *** IF NOT x_Init THEN I2C_Handle := CDOpen(szFile:= '/dev/i2c-0', dFlags:= O_RDWR, pResult:= ADR(di_result_open)); //* I2C opening * //*** set of the I2C address *** CDIoctl(hFile:=I2C_Handle , dRequest:=1795 , dParameter:=b_i2cAdr , pResult:=ADR(di_result_adr) ); x_Init := TRUE; END_IF (* Hauptlogik *) IF I2C_Handle <> 0 THEN (* Konfigurationsbyte setzen: Single-Ended Kanal 0, interne Referenz *) b_config_byte := 16#8C; (* 10001100b: AIN0, interne Referenz, Single-Ended *) ab_cmd_buffer[0] := b_config_byte; (* Schreiboperation zum Konfigurieren des Chips *) CDWrite(hFile:= I2C_Handle, pbyBuffer:= ADR(ab_cmd_buffer), udCount:= SIZEOF(ab_cmd_buffer), pResult:= ADR(di_result_wr_cmd)); IF di_result_wr_cmd = 0 THEN (* Leseoperation, um den ADC-Wert zu erhalten *) CDRead(hFile:= I2C_Handle, pbyBuffer:= ADR(ab_data_buffer), udCount:= SIZEOF(ab_data_buffer), pResult:= ADR(di_result_rd_cmd)); IF di_result_rd_cmd = 0 THEN (* ADC-Wert aus den Daten extrahieren *) ui_adc_value_1 := SHL(TO_UINT(ab_data_buffer[0]), 8) OR TO_UINT(ab_data_buffer[1]); ELSE (* Fehler beim Lesen der Daten *) ui_adc_value_1 := 0; (* ADC-Wert auf 0 setzen *) END_IF ELSE (* Fehler beim Schreiben der Konfiguration *) ui_adc_value_1 := 0; END_IF END_IF
Last updated: 2024-12-13

Post by s1ack on Wago PFC200 Ethernet / IoDrvEthernet Issue? ^{CODESYS Forge talk (Post)}
CODESYS Control for PFC200 4.13.00 CODESYS IIoT Libraries SL 1.11.0.0 Application Based License: CODESYS Control Standard M I have (2) projects with similar code base and both using Wago PFC200. On the second project I am seeing 2 things that I have not been able to resolve: 1) Errors in the log under the Ethernet Item: IoDrvEthernet: [PCI\E1Q51CE62] Could not be found on target! Please check the Ethernet settings. 2) Exception for CPU Load. "Processorload watchdog: plcload=100, maxplcload=95" I have slowed down cyclic tasks on this project, even though on the first project there is actually more code - and it does not exhibit this behavior. In looking at the CPU loading via Linux 'TOP' command there appears to be 20% idle. So plenty of headroom (my opinion). In an effort to troubleshoot I have duplicated the target hardware on my bench. It ran overnight without a CPU load exception. On the test system, I have tried (3) version of the ethernet device. 3.5.16.0 3.5.17.0 and 4.2.0.0 Presently the log does not show the error, but status says the module reports an error. I really do not know if this issue is related to the CPU load exception. The issue does not appear to effect ethernet communications (ModbusTCP or SNMP or Webvisu or PuTTy into Linux Shell). On my test bench I have ModbusTCP slave simulators for all ModbusTCP slaves, but only (1) of the (5) SNMP devices present.
Last updated: 2025-01-21

Post by jeindhoven on Deploying to raspberry pi 5 hangs ^{CODESYS Forge talk (Post)}
Yep sure, though now that i think of it, its a pi 4. My bad. The whole ordeal was necessary to use the VGA666 adapter. That needs the old graphical system and GPIO directly on the CPU. Edit: Putty on the virtual development machine connects fine. But i did change the login/pw. The account is still a sudo'er so that should be all right. Edit2: Sorry i get a "Comment rate limit exceeded" from the forum. Then i'll add it as edit here. So i have tried the stock raspberry pi image on a different pi5 (truly 5 this time). Packages updated. Standard password. Same symptoms, no runtime deployed and long hang time. Versions of this pi: pi@raspberrypi:~ $ uname -a Linux raspberrypi 6.12.25+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.12.25-1+rpt1 (2025-04-30) aarch64 GNU/Linux pi@raspberrypi:~ $ lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 12 (bookworm) Release: 12 Codename: bookworm pi@raspberrypi:~ $ apt list --installed | grep openssh-server openssh-server/stable,now 1:9.2p1-2+deb12u6 arm64 [installed,automatic] Attached is the Device information and error text that Codesys comes up with. Edit 3 (Comment rate limit, otherwise it would be a new post) Now i have tried booting an older native Windows 10 machine (no virtualization), and it just works as expected. I have now a raspberry pi 4 and raspberry pi 5 with version 4.16.0.0 of the control application. Windows 10 native: build 19045 (same as virtualised Win 10), same .NET version, same CODESYS version. It seems that running CODESYS virtualized somehow messes with the deployment?
Last updated: 2025-06-23

Post by jst69 on Python script: Launch Codesys, Execute Script, Exit Codesys ^{CODESYS Forge talk (Post)}
Dear all: Question about scripting: I am creating a .NET program that is supposed to Open codesys, open template project, export a bunch of pou, then exit codesys. Launch works, Open project works, Export works, But how do i tell codesys to close itself? I can tell windows to terminate codesys, but i would prefer to do it properly. from __future__ import print_function import sys import System proj = projects.primary # We're interested in POU nodes: POUGuid = Guid("6f9dac99-8de1-4efc-8465-68ac443b7d08") # We collect all POU nodes in that list. pous = [] # From the parent node on, we recursively add POU nodes: def CollectPous(node): if node.type == POUGuid: pous.append(node) else: for child in node.get_children(): CollectPous(child) # Now we collect all the leaf nodes. for node in proj.get_children(): CollectPous(node) # We print everything just to know what's going on. for i in pous: print("found: ", i.type, i.guid, i.get_name()) # And now we export the files. for candidate in pous: # We create a list of objects to export: # The object itsself objects = [candidate] # And sub-objects (POUs can have actions, properties, ...) objects.extend(candidate.get_children()) # And the parent folders. parent = candidate.parent while ((not parent.is_root) and parent.is_folder): objects.append(parent) parent = parent.parent # Create an unique file name: if len(sys.argv) == 1: filename = "parent\\%s.export" % (candidate.get_name()) else: filename = "%s\\%s.export" % (sys.argv[1],candidate.get_name()) # print some user information print("exporting ", len(objects), " objects to: ", filename) # and actually export the project. proj.export_xml(objects, filename) proj.close() print ("script finished.") System.exit(0) // Dont work .NET: public static void Export(string path,string proj) { if (checkSettings()) { var p = new System.Diagnostics.Process(); p.StartInfo.FileName = Properties.Settings.Default.CSVersion +"\\CODESYS\\Common\\CODESYS.exe"; p.StartInfo.Arguments = " --Profile=" + qoute(Properties.Settings.Default.CSProfile) + " --culture=en" + " --project=" + qoute(path + "\\" + proj) + " --runscript=" + Properties.Settings.Default.LastOpenProjectPath + "\\INPUT_DATA\\SCRIPT\\Export.py" + " --scriptargs:" + qoute(path) ; p.StartInfo.RedirectStandardOutput = true; p.StartInfo.UseShellExecute = false; p.StartInfo.CreateNoWindow = false; p.Start(); p.StandardOutput.ReadToEnd(); p.CloseMainWindow(); p.Close(); } }
Last updated: 2024-01-16

Post by gallusrrr on usb2can in Codeysy 3.5 Can Gateway ^{CODESYS Forge talk (Post)}
Hallo und guten Morgen, Ich danke für die Rückmeldung. ich habe das oben geschriebene durchgeführt und auch festgestellt das mit die Commandos für die Can befehle noch fehlen. (Google angeschmissen und geschaut auch gefunden) sudo apt-get install can-utils (damit auch jemanden anders der Post hilft) Anschließend habe ich das CAN System komplett aufgebaut so das ich mit einen anderen CAN Adapter schauen konnte ob die Nachricht auch ankommt. die Nachricht kommt an :) danach habe ich follgende Ausgabe: pi@Codesys:~ $ sudo ip -s -d link show can0 3: can0: <noarp,up,lower_up,echo> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10 link/can promiscuity 0 allmulti 0 minmtu 0 maxmtu 0 can state ERROR-ACTIVE restart-ms 0 bitrate 250000 sample-point 0.875 tq 250 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1 brp 12 gs_usb: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..1024 brp_inc 1 clock 48000000 re-started bus-errors arbit-lost error-warn error-pass bus-off 0 0 0 0 0 0 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 tso_max_size 65536 tso_max_segs 65535 gro_max_size 65536 parentbus usb parentdev 1-1.4:1.0 RX: bytes packets errors dropped missed mcast 3549 819 0 0 0 0 TX: bytes packets errors dropped carrier collsns 32 4 0 0 0 0</noarp,up,lower_up,echo> (Sorry habe kein Speicherplatz im Web um Bilder anzuzeigen..) man kan sehen das die Nachricht abgeht und auch 32 Byte Empfangen worden sind. Die nachricht ist auch am anderen CAN Adapter sichtbar gewesen. Wie bekomem ich den einrichteten Adapter in Codesys rein? das ich den Befehl sudo ip link set can0 up type can bitrate 500000 das ich die Einrichtungs des Can Adapters noch in die Rasperry Start rutine nehmen muss ist mir klar. Ich bedanke mich .
Last updated: 2024-01-18

Post by testlogic on Sending Sequential Modbus TCP Packets ^{CODESYS Forge talk (Post)}
I have a Modbus TCP slave device where I need to do sequential writes to the same register. The register I'm writing to is kind of like a command line, each packet is a command word encoded in Hexadecimal. I am having difficulty implementing this system in CoDeSys 3.5 SP19. I feel like the structure of the program should be something along the lines of (Pseudocode): ModbusTCPSend(Command Register, Command1) ModbusTCPSend(Command Register, Command2) ModbusTCPSend(Command Register, Command3) I have tried to implement this with a rising edge trigger wMot1OPCode := 16#E1; //Stop Motor & Kill Program xMot1SendOP := TRUE; //Send OP on rising edge xMot1SendOP := FALSE; //Reset wMot1OPCode := 16#9E; //Disable Motor xMot1SendOP :=TRUE; //Send OP on rising edge xMot1SendOP := FALSE; //Reset Where "wMot1OPCode" is the IO map for writing to the command register, and "xMot1SendOP" is the rising edge trigger for that modbus channel. However, this doesn't work. The device never responds to the modbus commands. It seems like the trigger variable is switched too quickly for modbus to send the packet. I know the modbus register is working, because I can set the channel to cyclic and the device will respond. However, I can't use this reliably because I need each command to be sent once, in order. Cyclic keeps re-sending the commands and seems like it could miss a command as well if one was sent in-between cycle time. I have also trying using the Application trigger as described by https://faq.codesys.com/pages/viewpage.action?pageId=24510480, but this is also not working for me. See attached picture for my FBD code. This seems like a simple function, I can't tell what I'm doing wrong here. Thanks for the help.
Last updated: 2024-03-06

Post by superjojo2002 on Licensing info not available. ^{CODESYS Forge talk (Post)}
I updated the docker container runtime to version 4.11.0.0. and build the container with this "Dockerfile" FROM arm64v8/debian:11.6 RUN apt-get update RUN apt-get install -y wget sudo unzip libusb-1.0-0-dev procps ENV CDS_VERSION "4.11.0.0" ENV EDGE_VERSION "4.11.0.0" ENV URL "https://store-archive.codesys.com/ftp_download/3S/LinuxARM64/2302000039/$CDS_VERSION/CODESYS%20Control%20for%20Linux%20ARM64%20SL%20$CDS_VERSION.package" ENV EDGE_URL "https://store-archive.codesys.com/ftp_download/3S/EdgeGatewayLinux/000120/$EDGE_VERSION/CODESYS%20Edge%20Gateway%20for%20Linux%20$EDGE_VERSION.package" RUN wget --output-document=/tmp/codesys.package $URL && \ unzip -p /tmp/codesys.package '*codemeter*.deb' > /tmp/codemeter.deb && dpkg -i /tmp/codemeter.deb && \ unzip -p /tmp/codesys.package '*codesyscontrol*.deb' > /tmp/codesys.deb && dpkg -i /tmp/codesys.deb RUN wget --output-document=/tmp/edge.package $EDGE_URL && \ unzip -p /tmp/edge.package '*arm64.deb' > /tmp/edge.deb && dpkg -i /tmp/edge.deb EXPOSE 11740 1217 11743 ENTRYPOINT ["/bin/sh", "-c" , "/etc/init.d/codemeter start && /etc/init.d/codemeter-webadmin start && /etc/init.d/codesyscontrol start && /etc/init.d/codesysedge start && tail -f /dev/null"] Now cmu -x" returns root@sensoredge-field-netfield-produktmanagment:/# cmu -x cmu - CodeMeter Universal Support Tool. Version 8.00 of 2023-Nov-28 (Build 5967) for Linux/ARMHF 64-Bit Copyright (C) 2007-2023 by WIBU-SYSTEMS AG. All rights reserved. But still CODESYS development system reports that it needs a dongle and when I click install that "value cannot be null. Parameter name: containerToLicenses" It seems that Codemeter is forced to look for a dongle instead of a CMsoftcontainer. Can you confirm that CODESYS licensing works also when CODESYS is installed in a Docker container?
Last updated: 2024-03-21

Sort by relevance or date