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 i-campbell on Official MQTT-Client: MAX_RECEIVE_BUFFER_SIZE_EXCEEDED ^{CODESYS Forge talk (Post)}
256MB for the protocol yes, but the default value for this library parameter limits the library to 6kB per task scan.
Last updated: 2023-09-27

Post by andrax on Prüfen ob Datei existiert wenn nicht neu erstellen ^{CODESYS Forge talk (Post)}
Auch wenn es bissl spät ist, DANKESCHÖN. Dann hatte ich mir das richtig gedacht. Aus Sicherheitsgründen habe ich die Task gegenseitig verriegelt
Last updated: 2024-07-01

Post by pietrobalint on Retain / Persistent Variables in Codesys for Raspberry Pi ^{CODESYS Forge talk (Post)}
Ok, I figured out that I do not call the program in the main task. Thank you for the source code, it works!
Last updated: 2024-08-17

Post by micik on Retain / Persistent Variables in Codesys for Raspberry Pi ^{CODESYS Forge talk (Post)}
Hello pietrobalint, could you please how exactly you call this program? if not in the main task? Caould you please share a screenshot of how exactly you made it work? Thank you!
Last updated: 2024-08-20

Post by eschwellinger on Problem with edge gateway config mode ^{CODESYS Forge talk (Post)}
if this does not work, you could install the 3.5.20.0 Gateway from the CODESYS Store. https://store.codesys.com/de/codesys-edge-gateway-for-windows.html then it is possible to enable it by righclick inthr task tray
Last updated: 2024-10-21

Post by davidbo on AC_Datalog DataLogChannel Save Cyclic is not working ^{CODESYS Forge talk (Post)}
"Save Cyclic" is set to 30s, but in my log I can see my variables are logged every 500ms which equals the cyclic time for my Task. Why is "Save Cyclic" ignored
Last updated: 2025-07-11

Post by open on How to create a stopwatch? ^{CODESYS Forge talk (Post)}
Thanks everyone for your input, I am using persistent variables to retain the timer value after machine shutdown, and main task to be as low as possible for the seconds TON to be accurate.
Last updated: 2023-12-14

Post by acc00 on Variable Sync Issue In Soft Plc Redundancy ^{CODESYS Forge talk (Post)}
Hi arundara, I'm also experimenting with Redundandcy. Is the sync variable function the following: "RedundancySynchronizeData()" ? Does the Task time increase a lot when you activate the sync function?
Last updated: 2024-03-11

Post by eschwellinger on Two OneWireMaster on one Raspberry PI 5 ^{CODESYS Forge talk (Post)}
the project has only one OneWire Master - so if you add the setting "PlaceholderFilePath.2=/sys/devices/w1_bus_master2, $OneWire2$ to the config file it will fail and the Ethercat task will be blocked by the OneWire Master readings?
Last updated: 2025-10-21

Post by eschwellinger on Two OneWireMaster on one Raspberry PI 5 ^{CODESYS Forge talk (Post)}
Could you check the taskcycle time in the taskmonitor (online monitor) - do you really see this 1s on Ethercat Task? Need to check this on my hardware but will take some time...
Last updated: 2025-10-21

Post by i-campbell on Official MQTT-Client: MAX_RECEIVE_BUFFER_SIZE_EXCEEDED ^{CODESYS Forge talk (Post)}
I can't answer why it's not resetting, but from the description of g_udiMaxReceiveBufferSize, I would guess the sum of sizes of the mqtt packets received in one cycle exceeded this value. So the answer may be to increase that parameter. https://content.helpme-codesys.com/en/libs/MQTT%20Client%20SL/Current/MQTT-Client/Common/Params/MQTTParam.html https://content.helpme-codesys.com/en/CODESYS%20Development%20System/_cds_dlg_library_parameter.html
Last updated: 2023-09-26

Post by trusty-squire on Confused by dwIpoTime input for SMC_Interpolator ^{CODESYS Forge talk (Post)}
OK, that makes sense. Because the FB is provided a specific interval period, it would change the target position accordingly based on the time it "thought" elapsed. If it has the wrong interval provided, it updates the target positions every cycle incorrectly so the axes will end up moving faster or slower. Thanks!
Last updated: 2024-07-22

Post by reinier-geers on SysFileOpen does not work after update to V3.5 SP19 Patch 5 ^{CODESYS Forge talk (Post)}
At 19.1 the hFile_test should be RTS_IEC_HANDLE and always open-write - close in one cycle udi_handle: RTS_IEC_HANDLE; //handle-number. Is created by SysFileOpen udi_handle:=SysFileOpen(sFileName,Sysfile.AM_WRITE_PLUS, ADR(udi_ErrorCode)); udi_RetValWrite:=SysFileWrite(udi_handle, pRemBuffer, szRemBufSize, ADR(udi_ErrorCode)); //closing file IF udi_RetValWrite < szRemBufSize THEN ui_Error:=cWriteError; END_IF//error writing data udi_ErrorCode_Close:=SysFileClose(udi_handle);
Last updated: 2024-02-19

Post by manuknecht on High Cycle Times for SoftMotion_PlanningTask when using AxisGroup ^{CODESYS Forge talk (Post)}
Hi, thanks a lot for the response. I did check all these parameters, but if the PlanningTask takes up to 60 ms, I can't increase the Buffer to such values. I contacted the Codesys support with a projectarchive. Let's see if they can help. Thanks again for your great support!
Last updated: 2024-03-22

Post by gseidel on Movesuperimposed Command Aborted Error ^{CODESYS Forge talk (Post)}
Hi transcend, most likely cause: one of the motion FBs was not called in each IEC cycle. See https://content.helpme-codesys.com/en/CODESYS%20SoftMotion/_sm_basic_common_errors.html. A different possible error, if you are using buffermode buffered or blending: the execution order of the motion FBs was wrong. See https://content.helpme-codesys.com/en/CODESYS%20SoftMotion/_sm_buffermode_execution_order.html. Best regards, Georg
Last updated: 2026-04-13

Post by sturmghost on Visualization using methods and cyclic ST-calls ^{CODESYS Forge talk (Post)}
Im looking for a way to implement ST-code into the visualization element without creating a helper POU or method in my device/application tree. Like visualization properties are evaluated at each VISU_TASK cycle I want to be able to create own ST code which interacts with the visualization interface variables. To be more specific I want to have a property which executes user defined ST-code at each VISU_TASK cycle exactly like its already possible for Input Configuration on various mouse and dialog events. Also a property for initialization (so only executed once) and a timed property would be nice. With the situation right now I'll have to create a POU function which handles the ST-code and misuse a property, like the text variable, to execute this POU function at each VISU_TASK cycle. Or does it exist and I don't know it?
Last updated: 2023-10-02

Post by ryandmg on Web Client (HMI) Disconnects from Webvisu (Weidmuller u-OS) ^{CODESYS Forge talk (Post)}
Hey Everyone, I'm having a bit of a struggle finding settings that will reliably maintain a connection between the webvisu and a touchscreen client. Every so often the HMI disconnects and will perpetually display the red spinning arrow with the "Error Happened, Will resume automatically" text. Power cycling the HMI to force a reconnect will re-establish comms. It seems to happen during periods of inactivity if that's a clue. From what I've gathered so far this seems to have something to do with the webvisu update rate, buffer size as well as the visu task scan rate. We first tried the default settings as follows: Webvisu Update Rate: 200 ms Webvisu Buffer Size: 50,000 Visu Task Scan Rate: 100 ms Priority 31 Other Tasks for Reference: Main Task Scan Rate: 100 ms Priority 1 Alarm Manager Scan Rate: 50 ms Priority 31 Ethercat Task: 4 ms Priority 1 This would disconnect some what regularly. We then made the following changes to try and stabilize: Webvisu Update Rate: 150 ms Webvisu Buffer Size: 75,000 Visu Task Scan Rate: 75 ms Kept other tasks the same. This seems to disconnect even more frequently. Also for reference the network is very small and only consists of the PLC, a small switch and the HMI. We're also not controlling frames from outside the visu program itself. The frame changes are all done natively. Any suggestions to get this to stop disconnecting? Oh and whatever the issue is the log does not record it. Figured I would ask here before opening a ticket. Thanks in advance for your help!
Last updated: 2023-09-06

Post by trusty-squire on SysProcessCreate2 on Linux runtime ^{CODESYS Forge talk (Post)}
Hi, I'm trying to launch a continuously running python script from Codesys and monitor the script status inside the Codesys runtime (running on a Linux enviroment). For now I'm testing with the below to emulate a continuously running Python script: #test.py i = 0 while True: i += 1 I'm able to successfully run the script using SysProcessExecuteCommand2 (I can see the Python process running in the task manager). However, this "freezes" the Codesys execution of the task - it sits on that command and will not continue until the Python script ends. I've proven this works by using the task monitor to kill the process, then Codesys continues on happily through the task. What I want to do is use SysProcessCreate2 to set up the Python script as a background task and monitor the process using SysProcessGetState. This always results in the error "ERR_OPERATION_DENIED". I know that I'm able to execute commands (as above), so my config should be correct. Is SysProcessCreate2 functional on a Linux environment? Is there something in the config file I'm missing? Here's my "working" code that uses SysProcessExecuteCommand2: VAR bTest : BOOL; sCommand : STRING := '/usr/bin/python3 /var/opt/codesys/PlcLogic/Application/test.py'; refCommand : REFERENCE TO STRING REF= sCommand; sOutput : STRING; refOutput : REFERENCE TO STRING REF= sOutput; result : RTS_IEC_RESULT; END_VAR IF bTest THEN SysProcessExecuteCommand2( pszCommand:= refCommand, pszStdOut:= refOutput, udiStdOutLen:= SIZEOF(sOutput), pResult:= ADR(result) ); bTest:= FALSE; END_IF And here's the code that always results in the ERR_OPERATION_DENIED error: VAR bTest : BOOL; sApp : STRING := '/usr/bin/python3'; sCommand : STRING := '/var/opt/codesys/PlcLogic/Application/test.py'; refApp : REFERENCE TO STRING REF= sApp; refCommand : REFERENCE TO STRING REF= sCommand; hResult : SysProcess.RTS_IEC_RESULT; hHandle : SysProcess.RTS_IEC_HANDLE; END_VAR IF bTest THEN hHandle := SysProcessCreate2( pszApplication:= refApp, pszCommandLine:= refCommand, ulFlags:=SYSPROCESS_CREATEFLAG_HIDDEN, pResult:= ADR(hResult) ); bTest:= FALSE; END_IF Here's the relevant section from the config file at /etc/codesyscontrol/CODESYSControl.cfg: [SysProcess] Command=AllowAll Appreciate any support or ideas. Thanks!
Last updated: 2025-03-16

Post by winki on ModbusFB ClientRequest: never recovers after a single ReplyTimeout (requires full download) ^{CODESYS Forge talk (Post)}
Library: ModbusFB (CODESYS Modbus package) IDE / Runtime: CODESYS V3.5 SP___ / Control runtime ___ Target: ___ (e.g. gateway, Linux ARM64 / Debian) Slave: Modbus TCP inverter Summary I poll a Modbus TCP slave with a permanent connection: one ClientTCP (kept connected, xConnect:=TRUE) and one ClientRequestReadHoldingRegisters, triggered cyclically. Everything works fine after a fresh application download. But as soon as one single ReplyTimeout occurs (slave temporarily not answering), the request never recovers. It stays stuck and no further messages are sent, even though the TCP connection is still reported as alive. Only a full application download brings it back — an online change or a runtime reset is not enough / not what I want in production. State observed when stuck So the connection is alive, the request finished in ReplyTimeout, the FB is back to _state = None, but udiNumMsgSent no longer increases — as if a new rising edge on xExecute is no longer accepted / no longer produces a new message. My trigger logic (simplified) Each PLC cycle, in this order: If the request is fully at rest (NOT xExecute AND NOT xBusy AND NOT xDone AND NOT xError) and a read is pending, I set xExecute := TRUE. I call clientTcp() then clientRequest(rClient := clientTcp) once each, per cycle. On xDone or xError, I set xExecute := FALSE. I made sure to insert at least one full cycle with xExecute = FALSE (seen by the FB call) before re-triggering, so the falling edge is processed. Questions After a ReplyTimeout (xError = TRUE), what is the exact, correct sequence to re-trigger the same ClientRequest so a new message is actually sent again? Is a full cycle with xExecute = FALSE between two executions mandatory? Is there a known condition where, after ReplyTimeout, the ClientTCP keeps xConnected = TRUE but silently stops sending new requests (e.g. an internal request queue / _udiRequestId that gets out of sync)? udiNumMsgSent freezing at 23 while the FB shows _state = None is what puzzles me. Is the recommended pattern to drop the connection (ClientTCP.xConnect := FALSE for one cycle, then TRUE) on a request error, rather than keeping it alive? The docs state a request error does not close the connection, so I kept it open — but maybe that is the issue here. Could the large uiStartItem (50514) be relevant? It works right after download, so addressing seems correct, but I want to rule it out. Any guidance on the canonical recovery pattern after a request timeout would be greatly appreciated. Thanks!
Last updated: 2026-06-19

Post by serwis on Dynamic target position tracking ^{CODESYS Forge talk (Post)}
Hello, I am trying to control a servo drive and dynamically set its position. I control the drive via EtherCAT with a cycle time of 500us. I use the MC_MoveAbsolute block for this. The problem is that when using a PID controller, I generate the positions I want the drive to move to on an ongoing basis, and I would like the position to be set immediately. The MC_MoveAbsolute block must receive a rising edge to execute, and I would like the movement to be performed without waiting for this edge. I have created a function that generates a rising edge every 1 ms, but I am unable to change this time to 500 µs because the TON function does not support times shorter than 1 ms. Below is the code to call the rising edge: IF Exe = TRUE THEN delay1(IN:=TRUE, PT:=T#1MS); IF delay1.Q = TRUE THEN Exe := FALSE; delay1(IN:=FALSE); END_IF END_IF IF Exe = FALSE THEN delay(IN:=TRUE, PT:=T#1MS); IF delay.Q = TRUE THEN Exe := TRUE; delay(IN:=FALSE); END_IF END_IF END_IF Here is the code for calling the MC_MoveAbsolute function: MoveDegree( Axis:= Tilt, Execute:= Exe, Position:= position_target - (base_angle_real * feedforward_turn), Velocity:= vel, Acceleration:= acc, Deceleration:= dec, Jerk:= jerk, Direction:= MC_DIRECTION.shortest, BufferMode:= MC_BUFFER_MODE.Aborting, Done=> , Busy=> , Active=> , CommandAborted=> , Error=> , ErrorID=> ); I realize that there are probably better methods for performing this type of task. How can I implement motion with a dynamically changing setpoint? THANKS
Last updated: 2025-09-05

Post by jeroenaero on CodeSys Raspberry pi I2C driver not found ^{CODESYS Forge talk (Post)}
Hello, We have a problem with CodeSys on a raspbery pi with an ADS1015 analog to I2C module. It can't find the I2C device on the i2c bus, it says No I2C Driver Found. When we use the RPI terminal we can find the I2C device and read it out. The i2c-1 bus is also accessible from codesys. The device address of the Analog to I2C module is 0x48. Can someone have a look what the problem is? i submitted the screenshots in the attachments. i also include the device description and library.
Last updated: 2024-11-07

Post by albzen on EtherCat Slaves diagnosis ^{CODESYS Forge talk (Post)}
Hello everybody, I'm working on a RunTime Plc (Codesys 3.5.16/18.20) connected to an EtherCat bus with many devices. The bus has some communication fault but I don't know how understand which is the device or the cable that has the trouble. To understand the cause of the problem I would like to read the WKC (Working counter) of the devices (0x0300...0x030C), how is explained in EtherCat documents, but it seems that the read of the counter is disabled. Attached there is an extract of the Ethercat document. Can anyone give me some advice about how and with function can I read it. Thank you in advance!
Last updated: 2024-03-29

Post by albzen on EtherCat Slaves diagnosis ^{CODESYS Forge talk (Post)}
Hello everybody, I'm working on a RunTime Plc (Codesys 3.5.16/18.20) connected to an EtherCat bus with many devices. The bus has some communication fault but I don't know how understand which is the device or the cable that has the trouble. To understand the cause of the problem I would like to read the WKC (Working counter) of the devices (0x0300...0x030C), how is explained in EtherCat documents, but it seems that the read of the counter is disabled. Attached there is an extract of the Ethercat document. Can anyone give me some advice about how and with function can I read it. Thank you in advance!
Last updated: 2024-03-29

Post by marckl on Bosch BME 280 bzw 688 Sensor per I2C Bus steuern und Daten in Codesys verarbeiten ^{CODESYS Forge talk (Post)}
Hallo allerseits, Ich möchte für mein Projekt einen BME 688 Environmental Sensor benutzen, aber weiss nicht wie ich ihn in Codesys ans Laufen bekommen soll. Der Händler hat auf der Website eine Anleitung um ihn in der Kommandozeile des Raspberry Pi´s laufen zu lassen, das funktioniert auch super. Der Sensor ist per I2C Bus angeschlossen. Wie kann ich jetzt in Codesys die Sensordaten auslesen? Ich habe dies schon viel recherchiert und habe gesehen, dass jemand schonmal das Gleiche mit einem BME 280 probiert hat, allerdings konnte ich nicht nachvollziehen wie er den ans laufen gebracht hat. Ich hoffe mir kann jemand helfen
Last updated: 2024-05-22

Sort by relevance or date