<Dereference of invalid pointer> ^{CODESYS Forge talk (Thread)}
<dereference of="" invalid="" pointer=""></dereference>
Last updated: 2026-06-26

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)}
Thank you very much, What FESTO provides should work even if I use another PLC (WAGO) that is not from FESTO?
Last updated: 2026-06-30

Post by arj3090 on Linux ARM64 Deploy Fail - Index out of range ^{CODESYS Forge talk (Post)}
Codesys V3.5 SP22 Patch 2 I am attemtping to install Linux Arm64 SL on a Beckhoff CX9240. When the deploy of the run time begins, an error box pops up with an unhandled exception - Index was out of range. Attached is an image of the error. I am unable to expand the complete error because the software is locked up.
Last updated: 2026-07-01

Post by gseidel on CODESYS SoftMotion Generic DSP402 on WAGO PFC200 + Festo CMMT-AS: MC_Power stays Busy, Controlword remains 0 ^{CODESYS Forge talk (Post)}
Hi gilad, I cannot tell for sure. But I think it should work on any PLC that is capable of doing motion control. Best regards, Georg
Last updated: 2026-07-01

SOFTMOTION - Error 34 when trying to execute and SMC_DI_AXIS_Error ^{CODESYS Forge talk (Thread)}
SOFTMOTION - Error 34 when trying to execute and SMC_DI_AXIS_Error
Last updated: 2026-07-07

Post by shivsrikakolum on SOFTMOTION - Error 34 when trying to execute and SMC_DI_AXIS_Error ^{CODESYS Forge talk (Post)}
I am using a Trio DX3 drive DC bus Unused , so I can control from SM3 Axis Datatype but as soon i try to Jog or Enable the MC_ Blocks It shows Error 36 can some one please the settings for this .
Last updated: 2026-07-07

Post by josepmariarams on CODESYS SoftMotion Generic DSP402 on WAGO PFC200 + Festo CMMT-AS: MC_Power stays Busy, Controlword remains 0 ^{CODESYS Forge talk (Post)}
Try to disable _bCheckBit12InPositonMode in Cia402StateMachine.
Last updated: 2026-07-08

CODESYS SoftMotion Generic DSP402 on WAGO PFC200 + Festo CMMT-AS: MC_Power stays Busy, Controlword remains 0 ^{CODESYS Forge talk (Thread)}
CODESYS SoftMotion Generic DSP402 on WAGO PFC200 + Festo CMMT-AS: MC_Power stays Busy, Controlword remains 0
Last updated: 2026-07-08

Fieldbus has lost synchronicity ^{CODESYS Forge talk (Thread)}
Fieldbus has lost synchronicity
Last updated: 2026-07-08

Post by arj3090 on Beckhoff CX9240 : Using Internal EtherCAT Bus ^{CODESYS Forge talk (Post)}
Is it possible to get CodeSys working with Beckhoff IO cards connected directly to the CX9240 running Linux?
Last updated: 2026-07-09

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-07-09

Post by yannickasselin on Beckhoff CX9240 : Using Internal EtherCAT Bus ^{CODESYS Forge talk (Post)}
Now I understand. I always thought this was not supported. I might test it later. Thanks.
Last updated: 2026-07-10

Beckhoff CX9240 : Using Internal EtherCAT Bus ^{CODESYS Forge talk (Thread)}
Beckhoff CX9240 : Using Internal EtherCAT Bus
Last updated: 2026-07-10

Post by eschwellinger on CmpCharDevice blocks gpiochip access on Raspberry Pi 5 since update from SP18 to SP21 ^{CODESYS Forge talk (Post)}
this is probably: https://content.helpme-codesys.com/en/CODESYS%20Control/_rtsl_linux_dedicated_user.html ..switch back from rootless mode due GPIO will not work.
Last updated: 2026-07-19

Post by charly29160 on CmpCharDevice blocks gpiochip access on Raspberry Pi 5 since update from SP18 to SP21 ^{CODESYS Forge talk (Post)}
wird nicht mit kopiert - sorry: PermittedPath.0=/dev/i2c PermittedPath.1=/dev/spidev PermittedPath.2=/sys/class/gpio/ PermittedPath.3=/dev/gpiochip
Last updated: 2026-07-20

Post by charly29160 on CmpCharDevice blocks gpiochip access on Raspberry Pi 5 since update from SP18 to SP21 ^{CODESYS Forge talk (Post)}
Problem gefunden und erledigt => in CODESYSControl_User.cfg ergänzt: [CmpCharDevice] PermittedPath.0=/dev/i2c PermittedPath.1=/dev/spidev PermittedPath.2=/sys/class/gpio/ PermittedPath.3=/dev/gpiochip Dann funktioniert es wieder Gruß Karl Schuler
Last updated: 2026-07-20

Post by charly29160 on CmpCharDevice blocks gpiochip access on Raspberry Pi 5 since update from SP18 to SP21 ^{CODESYS Forge talk (Post)}
Noch eine Info dazu: als Version der Pi MC SL wird mir 4.21.0.0 angezeigt. In der log steht jedoch für IoDrvGPIO: 4.17.0.0 was ist das Problem?
Last updated: 2026-07-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 eschwellinger on CmpCharDevice blocks gpiochip access on Raspberry Pi 5 since update from SP18 to SP21 ^{CODESYS Forge talk (Post)}
yes, this is a known issue which will be fixed with 3.5.23.0 .. soll will take some time. You need to switch back the runtime running not as dedicated user, like it was before 4.21.0.0 How to switch back you'll find here. ('Change service user' in the deploy tool) https://content.helpme-codesys.com/en/CODESYS%20Control/_rtsl_linux_dedicated_user.html to sumerize both problems: 1. missing entries in CODESYSControl_Usr.cfg was the problem on Raspberry PI Runtime 2. Arm64 SL is running rootless by default since 4.21.0.0 ( Pi not by default you need to switch manually if needed due this GPIO restriction)
Last updated: 2026-07-22

CmpCharDevice blocks gpiochip access on Raspberry Pi 5 since update from SP18 to SP21 ^{CODESYS Forge talk (Thread)}
CmpCharDevice blocks gpiochip access on Raspberry Pi 5 since update from SP18 to SP21
Last updated: 2026-07-22

KOP & FUP in Sp21P6 nicht vorhanden ^{CODESYS Forge talk (Thread)}
KOP & FUP in Sp21P6 nicht vorhanden
Last updated: 2026-07-24

Fehlermeldung bei Onlinechange ^{CODESYS Forge talk (Thread)}
Fehlermeldung bei Onlinechange
Last updated: 2026-07-27

Post by radar17892 on Fehlermeldung bei Onlinechange ^{CODESYS Forge talk (Post)}
Hallo, kann mir jemand was zu dieser Fehlermeldung sagen: Mitteilung vom Gerät: “Alarm online change executed but license for Online Configuration Change not aviable!” Habe erst letzte Woche noch auf dieser Steuerung (PFC300, FW30) eine Programmänderung gemacht und hat alles funktioniert. Die Meldung kommt am Schluss, wenn ich einen Online change gemacht habe. Dann geht die Steuerung mit Ausnahmefehler auf Stop.
Last updated: 2026-07-27

Post by thomas-k on SysTimeRtcHighResGet --> Millisekunden mit Zeitzone verrechnet ^{CODESYS Forge talk (Post)}
SysTimeRtc.SysTimeRtcHighResGet(pTimestamp := lstActualIPCUnixTime_ms); SysTimeRtc. SysTimeRtcConvertHighResToLocal(lstActualIPCUnixTime_ms,lstActualIPCUnixTimeLocal_ms); SysTimeRtc.SysTimeRtcConvertLocalToHighRes(lstActualIPCUnixTimeLocal_ms,lstActualTime_ms); F30_SysTimeRtcHighResGetLocal:= TO_ULINT(lstActualTime_ms); Dies hat immer die selbe Zeit in UTC. Wie bekomme ich eine HIGHRes Zeit in Millisekunden. Und diese Zeit nicht in UTC sondern mit der Zeitzone verrechnet..... Und reicht es die Zeitzone mit "SysTimeRtcSetTimezone" zu setzen oder muss die Zeitzone im Linux (PC) gesetzt werden ?
Last updated: 2026-07-31

Post by lzml on HTML5 visualization controls disabled on CODESYS Control for Linux SL - overlay not supported? ^{CODESYS Forge talk (Post)}
Hello, I'm developing a custom HTML5 visualization control (via the HTML5 Control Editor / Tools > Visualization Element Repository) and I'm running into what looks like a target-device limitation when trying to deploy it to CODESYS Control for Linux SL. I'd like to understand whether this is a known/expected limitation or something in my setup. Environment - CODESYS Development System: V3.5.22.0 - Target runtime: CODESYS Control for Linux SL, package version 4.15.0.0 (installed together with CODESYS Edge Gateway for Linux 4.15.0.0) - Visu system libraries (VisuElems, VisuElemsAlarm, VisuInputs, VisuNativeControl, etc.): version 4.7.0.0 - Host OS: Debian RT (minimal/base installation) - We only use WebVisu, not TargetVisu. What I did 1. Built a custom HTML5 control following the official HTML5-API-Examples pattern (.html5control.xml manifest + ElementWrapper.js + CSS), installed it successfully via the HTML5 Control Editor ("Save and Install") into the Visualization Element Repository. 2. In the Visualization Manager, enabled "Support client animations and overlay of native elements" (documented as required for HTML5 controls to work at all). 3. With the project's Device set to CODESYS Control for Linux SL, compiling/downloading fails with: "Overlay is not supported for your target visualization device." (Visualization Manager) Build stops with 1 error, download not possible. Isolating the cause - The Visualization Element Repository confirms the control is correctly installed. - With the project Device set to a Windows-based device, the HTML5 control appears and is enabled in the Toolbox as expected. - With the project Device set to CODESYS Control for Linux SL, the HTML5 control is disabled/missing from the Toolbox entirely, even though it's installed in the repository. This points to the Linux SL device description simply not declaring overlay/HTML5 support, rather than a missing package or Debian-side dependency (WebVisu itself already works fine for standard/native visualization elements on this same target). Questions 1. Does CODESYS Control for Linux SL currently support WebVisu overlay (and therefore custom HTML5 controls)? I found documentation stating overlay support for target visualizations (Windows and Linux) was added starting with CODESYS Development System V3.5.17.0, but that seems to refer to TargetVisu, and our case is WebVisu-only on a Linux runtime. 2. If not currently supported, is this on a roadmap, or is there a different Linux runtime package/edition that does support WebVisu overlay for HTML5 controls? 3. Is there any Linux-side configuration or package needed to enable this (given the check appears to happen against a static device capability declaration rather than a live server check), or is this purely a matter of the device description bundled with the current Control for Linux SL package? Thanks in advance for any pointers.
Last updated: 2026-08-05

Sort by relevance or date