EtherCat problem
| FORUM | LATEST POST | # TOPICS |
|---|---|---|
|
General Discussion Forum about anything you want to talk about. |
No posts yet | 1 |
Recent Activities
-
baltzer posted a comment on discussion Engineering 🇬🇧
Setup: Net Base Services (NBS), TCP_Client + TLSContext, ePurpose := CLIENT_SIDE, connecting to a third-party embedded device (Velux KLF200 home automation gateway) whose factory-installed TLS certificate expired on 2026-07-12 and has no user-facing renewal path. Tested on both CODESYS Control for Raspberry Pi SL (3.5.19.0) and CODESYS Control Win V3 x64, with identical results on both. Goal: Accept the peer's expired certificate via a custom ICertificateVerifier implementation, since the certificate...
-
eschwellinger modified a comment on discussion Deutsch 🇩🇪
Hallo Falk, schau mal im CODESYS Installer ob "CODESYS FBD/LD" installiert ist - wenn nein nachinstallieren. Grüße
-
Hallo Flak, schau mal im CODESYS Installer ob "CODESYS FBD/LD" installiert ist - wenn nein nachinstallieren. Grüße
-
ct-f posted a comment on discussion Deutsch 🇩🇪
Hallo Zusammen, ich muss ein Projekt von Sp16P4 auf SP21 portieren, einige FBs wurden damals in FUP und KOP erstellt. Zu meiner großen Verwunderung gab es beim kopieren/einfügen eine Fehlermeldung. Jetzt wollte ich in KOP einen leeren FB erstellen, aber es gibt bei mir im Auswahlmenü weder KOP noch FUP. Gibt es eine Erweiterung, welche ich installieren muss? Konnte dazu nichts finden. Beste Grüße Falk
-
tvm posted a comment on discussion Visualization 🇬🇧
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.
-
tvm posted a comment on discussion Engineering 🇬🇧
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.
-
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...
-
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
-
TimvH posted a comment on discussion Engineering 🇬🇧
A customer of us had the same issue. They updated (at that time) to CODESYS 3.5.21.50 and Control for Linux SL versie 4.19.0.0. After that they couldn't reproduce the issue anymore. You might give this a try too.
-
nixola modified a comment on discussion Runtime 🇬🇧
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...