Post by gordonkeller360 on Escape character behavior for hex values in string -- what gives? ^{CODESYS Forge talk (Post)}
I have a program which sequentially places byte representations of characters from a string into an array. FUNCTION_BLOCK MoveBytesFromString VAR_IN_OUT abRxBuf: ARRAY [0..79] OF BYTE; END_VAR VAR testString : STRING := '$0A$R$L$TTesting,123...$94$86$0A'; iCount: DINT; END_VAR ---------------------------------------------------------------------------------------- // clear the buffer MEM.MemFill(ADR(abRxBuf), 80, 0); FOR iCount := 0 TO LEN(testString) - 1 DO // account for undesired null terminator of string abRxBuf[iCount] := testString[iCount]; END_FOR Escaped characters, like $T, $N, etc. work just fine, and so do their hex representation counterparts ($09, $0A, etc). However, when I put something like $94, I get a set of nonsense values... see image attached after one spin of the program. Could someone explain to me what is happening here? I'll continue to investigate...
Last updated: 2026-03-09

Post by poliautomacao on Absolute movement controlled by an external encoder. ^{CODESYS Forge talk (Post)}
Hello, I made this configuration, I'm moving the encoder value to SM_Driver_PosControl.in.wActPosition. When I make the absolute movement of my PosControl axis, my physical drive axis rotates perfectly, but I noticed that the movement is not followed by the encoder. That is, if I hold the encoder and keep it in position 0, the PosControl axis makes the absolute movement of 314 mm and stops, which is strange because the encoder is at 0. Theoretically, the PosControl axis should accelerate to try to compensate for the movement error. I haven't yet achieved perfect functionality.
Last updated: 2026-03-24

Post by jorenbeyl on library inside library ^{CODESYS Forge talk (Post)}
I am currently developing a library that contains real‑time data. To handle this real‑time data, I am using additional libraries called SysTime and SysTypes Interfaces. When I compile my library on its own, no errors occur. However, when I use this library in a project and compile the project, I get an error indicating that the SysTime data type is not recognized. This happens even though the SysTime library is visible as a dependency under my library. Does anyone know how to correctly include a library within another library so that the project recognizes the sub‑library without causing compilation errors?
Last updated: 2026-04-23

Post by polo on 1 Wire und i2c zeitgleich in Betrieb ^{CODESYS Forge talk (Post)}
Hallo zusammen, ich habe schon einige Zeit 16 DS18B20 am 1 Wire laufen ... auch die ganze Zeit stabil ... jetzt habe ich ein PWM Signal über i2c für eine Pumpenansteuerung zusätzlich in Betrieb genommen.. nur das Signal für die Pumpe geht über i2C ... 100Hz 10ms. Es läuft auch alles soweit ... nur fallen mir jetzt die Temperaturen in Abständen aus ... Vertragen sich die beiden Systeme zeitlich evtl. nicht so gut ... 1 wire extra task mit 200ms Prio 0 i2c task 10ms ... damit die 100Hz auch übertragen werden Prio 1 (Adafruit_PWM) Main Task 20ms Prio 5 Oder jetzt besser beides über i2c abrufen ... ist aber dann evtl. für die DS18B20 zu schnell ? Oder sind die 5V vom Pi jetzt zu schwach für beide Signale? Vielen Dank euch
Last updated: 2026-04-27

Post by kurt9 on ReadWriteEEprom FB question ^{CODESYS Forge talk (Post)}
I want to programmatically write the alias address to a new EtherCAT slave when I plug it into my IPC EtherCAT network. I am looking at the ReadWriteEEprom FB and see that one of the elements is "pbyData". which is the pointer to byte that is usually set to 2048 bytes. Since I am setting the alias address to the EEprom only (EEprom address 16#0012), I would assume that what I am writing is 2 bytes only. Does the pbyData have to be specified as ADR(myArray) where "myArray" is the 2 bytes of the alias address? How is the best way to set this element of the function block? Thanks in advance
Last updated: 2026-05-18

Post by alex-n on Problem with keeping up the distance between two axes ^{CODESYS Forge talk (Post)}
Hello. I have a task to synchronize the movement of two axes and maintain the distance between them. First axe makes equal steps by trigger using MC_MoveRelative function. The second one is standstill and after another signal should catch up the first one from its position to a specified distance and keep it. I've tried to use MC_Phasing and mostly it works. Second axis catches up the first and starts make step with it. But in one moment this axis can crash into the first and there is no clear connection as to why this is happening. It can work correct for a day or for a week.
Last updated: 2026-06-04

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 thejesh on WebVisu: switch-frame destroys and rebuilds referenced visualization - is retention configurable? ^{CODESYS Forge talk (Post)}
Hi, HTML5 Conrtrol elements on CODESYS V3.5 SP22 Patch 2, WebVisu only (no TargetVisu). The client is Chromium 147 in kiosk mode on a Raspberry Pi CM5 panel; the runtime is CODESYS Control Win V3 x64/CODESYS Control RTE V3 x64 on a separate IPC. I have measured that changing a Frame element's switch-frame variable destroys the currently referenced visualization and fully rebuilds it on return, including all embedded HTML5 controls. We would like to know whether this lifecycle is configurable. Measurement 1: Curently, our production page contains a good number of custom HTML5 controls and will only increase , each of which the WebVisu client instantiates as a separate about:srcdoc iframe. I counted live targets via the Chromium remote debugging endpoint (curl http://localhost:9222/json/list) before and after switching. Production displayed (index 0) 108 iframes Switched to a light page (index 1) 46 iframes Switched back to Production 108 iframes 62 controls are destroyed on leaving the page and re-instantiated on return. Observed latency was approximately 2.5 -5s away from the heavy page and approximately 4.0 -5 s back to it. This was measured with the panel otherwise idle: 2.8% system CPU, 97.1% idle, 2 h 56 min uptime, no remote-desktop session running, hardware acceleration confirmed active in chrome://gpu. I had previously measured the same behaviour under a much higher CPU load and have since resolved that load separately (VISU_TASK cycle period), so I am confident the rebuild is the frame lifecycle itself and not CPU starvation. Measurement 2 — frame offset instead of switch index I then displayed the same overlay page by a different mechanism. Instead of using a switch-frame index, I placed the page in a fixed Frame parked off-screen below the visible canvas, and drive its Y offset from an INT in Structured Text to move it into view. With this approach the overlay appears immediately, the production page underneath is never torn down and keeps updating, and no visualization is destroyed or rebuilt in either direction. The iframe count does not change at any point. This is the same visualization, containing the same HTML5 controls, as in Measurement 1 — the only difference is how it is brought on screen. So the rebuild appears to be a property of the switch-frame mechanism specifically, not of the page or its control count. Questions: Is the destroy-and-rebuild behavior on switch-frame the intended and documented lifecycle for WebVisu? Is there any setting, property or client option that causes a referenced visualization to remain instantiated when it is not the active index — the equivalent of keeping it mounted but not displayed? Does the runtime or client offer any form of caching or pre-instantiation for referenced visualizations, so that a return switch does not pay the full construction cost? Is the cost specific to HTML5 controls, or would the same rebuild occur with an equivalent number of native visualization elements? We ask because it would inform whether reducing our HTML5 control count is a viable solution. Is there a recommended pattern for showing a full-screen page over a live production screen without tearing the production screen down? My current workaround is to keep every page permanently instantiated and move it on and off screen by driving a frame offset variable, which avoids the rebuild entirely but means every page stays live and consumes client resources for the life of the session. This works, but I would prefer to use the supported mechanism if one exists. Any help on this is greatly appreciated. Thank you!
Last updated: 2026-08-07

Post by thommy54 on CODESYSControl_User cfg richtig konfigurieren ^{CODESYS Forge talk (Post)}
Hallo, nach Erwerb eines neueren Raspberry pi 4 (V1.5) musste ich zwangsläufig von Codesys 3.5.16 hochwechseln - ich habe auf 3.5.20.1 geupdated. Da schlugen mir plötzlich ne Menge Einschränkungen entgegen, deren Behebung einige Zeit dauerte. Eine davon ist, das ein SysFile.SysFileOpen nicht mehr funktioniert. Ich habe das Problem mit Einträgen in der /etc/CODESYSControl.cfg behoben: [SysFile] FilePath.1=/etc/, 3S.dat IecFilePath.1=/proc/, cpuinfo IecFilePath.2=/proc/, iomem PlaceholderFilePath.1=/sys/devices/w1_bus_master1, $OneWire$ PlcLogicPrefix=1 ; ; ---------------------- ; selbst eingefügt PlaceholderFilePath.2=/home/root, $my_home_root$ PlaceholderFilePath.3=/etc/init.d, $my_conf$ PlaceholderFilePath.4=/var/lib/mpd, $my_music$ PlaceholderFilePath.5=/root/Rasp_SPS_Filesystem, $my_Rasp$ Ob die Einträge sich etwas überlappen, kann mir gern jemand sagen, das ist aber nicht das Problem. Ich habe bei den vielen Versuchen, das Teil zum Laufen zu bringen, bemerkt, daß die Einträge auch ganz schnell mal verschwinden. Das ist ja auch so beschrieben, wenn die nächste Version kommt, sind meine Einträge weg. Da ich ähnliche Probleme mit dem Funktionieren von "SysProcessExecuteCommand2()" hatte, die ich ebenfalls mit Einträgen in die /etc/CODESYSControl.cfg hätte beheben können, habe ich gelesen, das man "private" Einträge lieber in die Datei /etc/CODESYSControl_User.cfg machen soll. Gesagt getan und "SysProcessExecuteCommand2()" lief: [SysProcess] Command=AllowAll Command.0=shutdown Aber auch irgendwo stand, das so ein Beteichner wie [SysFile] oder [SysProcess] nur einmal in den beiden Files /etc/CODESYSControl.cfg oder(!) /etc/CODESYSControl_User.cfg vorkommen darf. Das ist nun die eigentliche Frage! Ist das so ? Bei [SysProcess] ist das kein Problem, das gibt es in /etc/CODESYSControl.cfg nicht. Aber bei [SysFile] sieht das anders aus. Da sind 5 Zeilen schon in /etc/CODESYSControl.cfg drin. Würde ich diese in die User-Datei rüberschieben, könnte beim nächsten Update was fehlen oder, oder... Lasse ich es so wie es ist, sind meine Einträge beim Update weg - das sollte ja verhindert werden. Kann da jemand genaue Auskunft geben ?? Vielen Dank Thomas
Last updated: 2024-06-28

Post by thommy54 on Raspi-Cam: CameraStream.project nicht zum Laufen zu bringen ^{CODESYS Forge talk (Post)}
Hallo, Ich bringe das CameraStream.project nicht zum Laufen. Ich sehe die Ursache darin, das das Beispielprogramm sehr sparsam mit Programm-Kommentaren umgeht (von der Hilfe gar nicht zu reden). Ich habe beide Varianten bei der zu ändernden Zielvariable getestet: //copy video.htm to the webserver; //the location of the webserver depends on the used Apache version as mentioned in online help hDirHtmlTest:=SysDirOpen( szDir:='/var/www', pDirInfo:= ADR(dirInfo), diMaxDirEntry:=iMaxDirEntry, szDirEntry:=szDirEntry, pResult:=ADR(iDirHtmlError)); IF (iDirHtmlError = 0) THEN SysDirClose(hDir:=hDirHtmlTest); SysFileCopy('/var/www/video.htm', '$$PlcLogic$$/Application/video.htm', ADR(dwCopySize)); ELSE .... als auch hDirHtmlTest:=SysDirOpen( szDir:='/var/www/html', pDirInfo:= ADR(dirInfo), diMaxDirEntry:=iMaxDirEntry, szDirEntry:=szDirEntry, pResult:=ADR(iDirHtmlError)); IF (iDirHtmlError = 0) THEN SysDirClose(hDir:=hDirHtmlTest); SysFileCopy('/var/www/html/video.htm', '$$PlcLogic$$/Application/video.htm', ADR(dwCopySize)); ELSE .... Die Url-Streams habe ich gelassen wie sie vorgegeben waren: urlStream := CONCAT('http://', CONCAT(sIPAddress, '/video.htm')); urlPicture := CONCAT('http://', CONCAT(sIPAddress, '/cam_pic.php')); In der Webvisu im Browser komme ich maximal dahin wie im Screeshot Video_Visu_1 zu sehen. Also scheint der Link zu video.htm zu klappen. Das der zu cam_pic.php nicht klappt, wundert mich nicht, denn es existiert nicht und wird auch nicht evtl. am rechten Ort angelegt. Ich bin mir vollkommen im Unklaren: muss da was auf dem Raspberry Pi im Hintergrund laufen , z.B. raspivid . Welcher Programmteil bedient die Cam ? Ich erkenne auch nicht, wo ein einzelnes picture entstehen soll. Wäre dankbar, wenn ich hier etwas Hilfe bekommen könnte. Evtl. gibt es Probleme mit der von mir verwendeten Codesys-Version 3.5.20.1 ? Ich benutze einen Raspberry 4 Rev.1.2. Grüße Thomas
Last updated: 2024-07-04

Post by paulpotat on cm4 runtime problem ^{CODESYS Forge talk (Post)}
Hello, I have exactly the same issue, with the following configuration : Hardware version >>> cat /proc/cpuinfo processor : 0 model name : ARMv7 Processor rev 3 (v7l) BogoMIPS : 108.00 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xd08 CPU revision : 3 processor : 1 model name : ARMv7 Processor rev 3 (v7l) BogoMIPS : 108.00 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xd08 CPU revision : 3 processor : 2 model name : ARMv7 Processor rev 3 (v7l) BogoMIPS : 108.00 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xd08 CPU revision : 3 processor : 3 model name : ARMv7 Processor rev 3 (v7l) BogoMIPS : 108.00 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xd08 CPU revision : 3 Hardware : BCM2711 Revision : a03141 Serial : 10000000d5be5b5f Model : Raspberry Pi Compute Module 4 Rev 1.1 Kernel version >>> uname -a Linux raspberrypi 6.1.21-v7l+ #1642 SMP Mon Apr 3 17:22:30 BST 2023 armv7l GNU/Linux OS Version >>> cat /etc/os-release PRETTY_NAME="Raspbian GNU/Linux 11 (bullseye)" NAME="Raspbian GNU/Linux" VERSION_ID="11" VERSION="11 (bullseye)" VERSION_CODENAME=bullseye ID=raspbian ID_LIKE=debian HOME_URL="http://www.raspbian.org/" SUPPORT_URL="http://www.raspbian.org/RaspbianForums" BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs" /boot/config.txt I added the following line : arm_64bit=0 CodeSys runtime version 4.10 Were you able to solve the issue @michelebianchi ? Any help with this would be appreciated... BR
Last updated: 2024-08-28

Post by otbeka on CAA File Handling: "Read only" error ^{CODESYS Forge talk (Post)}
Hi, On CODESYS V3.5.19.50 I am using the latest 3S File Access library (CAA File & CAA Types) to save and retrieve configuration data from the User Data section of an SD card, via file called config.txt. The application reads the file to memory once upon initialisation, and then the only other operation is overwriting the file with the updated configuration whenever the user changes the settings. An issue is ocurring, seemingly randomly, where the config.txt file, and all surrounding directories, cannot be written to by the unit, returning a READ_ONLY_CAA error upon file open. This sometimes does not clear even after power-cycling the PLC several times, yet checking the file permissions with ls -l shows normal read, write, and execute access. I am wondering if this is caused by the PLC itself or by an issue in my application. I have included my CAA File handler function block (SD_Card_Bin(FB).txt) and any associated types/calls below: TYPE ConfigData : STRUCT Config : ARRAY[0..256] OF STRING(64); NumberOfStrings : UDINT; END_STRUCT END_TYPE TYPE Buffer : STRUCT Data : ARRAY[0..SIZEOF(ConfigData)] OF BYTE; DataLength : UDINT; END_STRUCT END_TYPE A case within my MAIN PRG: mode.WriteConfigDataToFile: VisuElems.CURRENTVISU := 'Screen_Write'; IF xModeHasChanged THEN iErrorCount := 0; iRoute := 0; END_IF CASE iRoute OF 0: inBuffer := ConfigData_To_Buffer(GVL.UnitData); xConfigError := FALSE; xDataConfigured := FALSE; iRoute := 1; 1 : //Read Data from Card SD_Card_Bin.strFileName :=FileName; SD_Card_Bin.iFileOperation := 2; SD_Card_Bin(xExecute :=TRUE, WriteBuffer := inBuffer, xDone =>xDataConfigured, xError=>xConfigError, strErrorCodes=>strError); IF xDataConfigured THEN SD_Card_Bin(xExecute :=FALSE); IF xConfigError THEN iRoute := 32767; ELSE iRoute :=100; END_IF END_IF 100: // The end bCurMode := mode.DisplayProcessVariables; 32767: // Config error iErrorCount := iErrorCount + 1; IF iErrorCount > 2 THEN // Repeats 3 times, if no progress abandons and returns error bCurMode := mode.WriteError; ELSE iRoute := 0; // Try again END_IF END_CASE I'd like to rule out my application as the cause of this bug - help via comments or criticism would be greatly appreciated.
Last updated: 2025-03-19

Post by dnordenberg on BOOL variable in OPC UA and modbus simultaneously ^{CODESYS Forge talk (Post)}
How can I have an BOOL variable that is read/write in both modbus TCP server and from OPC UA at the same time? Variables with %MX.n %QX.n addressing which is used for BOOL/coils in modbus server is not allowed in OPC UA symbol list on Schneider M251 controllers. I have already asked on Schneiders forum but there are not a lot of codesys experts over there :( So OPC symbols can't have a address and the modbus TCP server needs a address. So how should I do it then? It seems like an impossible combination. Since I want read/write access from both ways I can't just simply make a second variable and assign it the value of another since it would be a one way assignment. I also tried using VAR_CONFIG which then makes the address syntax %Q or %M in my main variable list and that fools OPC UA Symbol Configuration to allow it and then I add the complete %MX.n address of it in the VAR_CONFIG list. This semi works, I can toggle the BOOL from modbus but the OPC UA symbol seems to be read only. It displays symbol status but nothing happens when I toogle it. I think I need another way to have the variables and symbols pointing to the same bits in memory... My plan B is to write a BOOL array compare FB that saves a history bit from previous cycle and if that does not match current status at next cycle for either the OPC symbol or the modbus variable then it copies the new status over to the other. Maybe ugly but it's like my last alternative. Kind regards David
Last updated: 2025-07-14

Post by full0pullpolen on Device User Logon ^{CODESYS Forge talk (Post)}
The following guide describes how you can adapt the user management for the first time in a project. It deals with the definition of a user and a group to which he belongs. Requirement: the project for which the user management is to be set up is opened. There is no adapted user configuration yet. Select Project Settings ‣ Users and Groups and then the Users tab. The user Owner is already created by default. Click on Add. ⇒ The dialog box Add User appears. Enter a login name, for example ‘Dev1’, and a password. Leave the option Activated activated. Click on OK. ⇒ On creating a group for the first time, CODESYS now requests you to authenticate yourself to perform this action. In this case, enter ‘Owner’ as the current user. Do not enter a password, just click on OK. The user Dev1 appears in the list and is automatically a member of the group 'Everyone'. Change to the tab Groups, in order to add the user to a new group. ⇒ The groups Everyone and Owner have already been created. Click on Add in order to open the dialog box Add Group. Specify at least one name for the new group, for example ‘Developers’. Activate the checkbox next to the entry User ‘Dev1’ in the field Members. Click on OK. ⇒ The group Developers now appears with has user member 'Dev1'. Switch to the Users tab. ⇒ The user Dev1 now appears as a member of the groups ‘Everyone’ and ‘Developers’.
Last updated: 2024-01-24

Post by full0pullpolen on Device User Logon ^{CODESYS Forge talk (Post)}
The following guide describes how you can adapt the user management for the first time in a project. It deals with the definition of a user and a group to which he belongs. Requirement: the project for which the user management is to be set up is opened. There is no adapted user configuration yet. Select Project Settings ‣ Users and Groups and then the Users tab. The user Owner is already created by default. Click on Add. ⇒ The dialog box Add User appears. Enter a login name, for example ‘Dev1’, and a password. Leave the option Activated activated. Click on OK. ⇒ On creating a group for the first time, CODESYS now requests you to authenticate yourself to perform this action. In this case, enter ‘Owner’ as the current user. Do not enter a password, just click on OK. The user Dev1 appears in the list and is automatically a member of the group 'Everyone'. Change to the tab Groups, in order to add the user to a new group. ⇒ The groups Everyone and Owner have already been created. Click on Add in order to open the dialog box Add Group. Specify at least one name for the new group, for example ‘Developers’. Activate the checkbox next to the entry User ‘Dev1’ in the field Members. Click on OK. ⇒ The group Developers now appears with has user member 'Dev1'. Switch to the Users tab. ⇒ The user Dev1 now appears as a member of the groups ‘Everyone’ and ‘Developers’.
Last updated: 2024-01-24

Post by full0pullpolen on Device User Logon ^{CODESYS Forge talk (Post)}
The following guide describes how you can adapt the user management for the first time in a project. It deals with the definition of a user and a group to which he belongs. Requirement: the project for which the user management is to be set up is opened. There is no adapted user configuration yet. Select Project Settings ‣ Users and Groups and then the Users tab. The user Owner is already created by default. Click on Add. ⇒ The dialog box Add User appears. Enter a login name, for example ‘Dev1’, and a password. Leave the option Activated activated. Click on OK. ⇒ On creating a group for the first time, CODESYS now requests you to authenticate yourself to perform this action. In this case, enter ‘Owner’ as the current user. Do not enter a password, just click on OK. The user Dev1 appears in the list and is automatically a member of the group 'Everyone'. Change to the tab Groups, in order to add the user to a new group. ⇒ The groups Everyone and Owner have already been created. Click on Add in order to open the dialog box Add Group. Specify at least one name for the new group, for example ‘Developers’. Activate the checkbox next to the entry User ‘Dev1’ in the field Members. Click on OK. ⇒ The group Developers now appears with has user member 'Dev1'. Switch to the Users tab. ⇒ The user Dev1 now appears as a member of the groups ‘Everyone’ and ‘Developers’.
Last updated: 2024-01-24

Post by mp9876 on Device logon problem following fresh install ^{CODESYS Forge talk (Post)}
All screenshots are enclosed in MS Word document. NOTE; 4 questions features at the end. Any assistance would be greatly appreciated! Hi everyone, I am still having device logon problem following a fresh install Here are the STEPS I went through following a FRESH CODESYS Win 64 3.5.19.60 install on a different computer. ‘Gateway not configured properly’ when attempting to REFRESH from the Users and Groups. Then did Gateway manage and confirmed it was ok: This message popped out as it was a fresh install: YES then: Initially went with Administrator twice (user & password) but it did not like it. No device is responding to …: Continued by setting a new user Pressed OK and obtained the following message: Stopped and Restarted PLC at that point: Obtained the following: Attempted to login a 2nd time without success. Then I scanned the network to see if matching device can be detected: Only way to get it detected was to remove the tick in the ‘Hide non-matching devices…’ Attempted a WINK but got a return like this one: REFRESH either @ Users and Groups or @ Access Rights returns: Then created user ‘mp’ at Project level ang logged in: Understandably device user mp9876 was not valid for the Project. Device information A few questions comes to my mind following these connection attempts: 1- Gateway not configured properly message pops out because of a non-compatible device ? 2- Why would the device not be compatible ? 3- Any way to make the device compatible ? 4- Any ideas on how to get this connectivity problem to the device solved ?
Last updated: 2024-03-17

Post by umdee on Error when monitoring LAD programs ^{CODESYS Forge talk (Post)}
I get the following error when monitoring my program (see attached screenshots): "Unhandled exception has occured in your application. If you click Continue, the application will ignore this error and attempt to continue. If you click Quit, the application will close immediately. Value cannot be null. Parameter name: source. And the details say: See the end of this message for details on invoking just-in-time (JIT) debugging instead of this dialog box. ** Exception Text ** System.ArgumentNullException: Value cannot be null. Parameter name: source at System.Linq.Enumerable.Any[TSource] (IEnumerable1 source, Func2 predicate) at _3S.CoDeSys.NWLEditor.NWLTextCell.OnPaintCellLayer(PaintEventArgs e) at _3S.CoDeSys.Controls.Controls.GfxEdControl.PaintCellCellLayer(PaintEventArgs e, GfxCell cell) at _3S.CoDeSys.Controls.Controls.GfxEdControl.PaintCellCellLayer(PaintEventArgs e, GfxCell cell) at _3S.CoDeSys.Controls.Controls.GfxEdControl.PaintCellCellLayer(PaintEventArgs e, GfxCell cell) at _3S.CoDeSys.Controls.Controls.GfxEdControl.OnPaint(PaintEventArgs e) at System.Windows.Forms.Control.PaintWithErrorHandling(PaintEventArgs e, Int16 layer) at System.Windows.Forms.Control.WmPaint(Message& m) at System.Windows.Forms.Control.WndProc(Message& m) at System.Windows.Forms.UserControl.WndProc(Message& m) at _3S.CoDeSys.Controls.Controls.GfxEdControl.WndProc(Message& m) at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam) ** Loaded Assemblies ** (3000 lines of assemblies) ** JIT Debugging ** To enable just-in-time (JIT) debugging, the .config file for this application or computer (machine.config) must have the jitDebugging value set in the system.windows.forms section. The application must also be compiled with debugging enabled. For example: <configuration> <system.windows.forms jitdebugging="true"> </system.windows.forms></configuration> When JIT debugging is enabled, any unhandled exception will be sent to the JIT debugger registered on the computer rather than be handled by this dialog box The windows show red X's where the networks should be. Any advice on how to fix this? Additional Information PLC used: Wago 750-8212, Firmware FW26 Startup profile: CODESYS V3.5 SP19 Patch 5 OS version: Microsoft Windows NT 10.0.22631.0 .NET version: 4.0.30319.42000 Full Version info attached as .txt
Last updated: 2024-03-17

Post by tk096 on High Cycle Times for SoftMotion_PlanningTask when using AxisGroup ^{CODESYS Forge talk (Post)}
Hi, under this circumstances the performance of a Raspberry Pi 4 should be sufficient to run a Softmotion robotics application. A closer look at the project would be required. Maybe you could contact the codesys support? Usually it is recommended to run the planning task cyclically every 2ms with task priority of 0 on a dedicated core. In the task configuration you can have a look at the average and maximum execution time of the planning task. You could use the function block SMC_TuneCPKernel (https://content.helpme-codesys.com/en/libs/SM3_Robotics/Current/SM3_Robotics/POUs/AdministrativeConfiguration/Computation/SMC_TuneCPKernel.html) to define suitable values for the parameters 'fSyncBufferDuration' and 'fPlanningInterval'. However, as previously mentioned, the performance of a Raspberry Pi 4 with realtime patch should be sufficient. The 'fPlanningInterval' parameter specifies the maximum planning step width in seconds. The cycle time of the planning task should not permanently exceed this value. A higher value reduces the computational effort, but can lead to a violation or no full utilization of the set limit values for velocity, acceleration and jerk. From a starting value of 0.016 seconds, the value should be increased gradually until the performance is acceptable. The parameter 'fSyncBufferDuration' specifies the size (in seconds) of the buffer between the planning and fieldbus task. The cycle time of the planning task must not exceed this value at peak times (this will lead to the error SMC_CP_QUEUE_UNDERRUN). A higher value can compensate for peaks in the cycle time of the planning task. At the same time, however, this also increases the latency for executing interrupts and aborting movements.
Last updated: 2024-03-22

Post by manuknecht on Maximum dynamic limits of MC_MoveLinearAbsolute and MC_MoveLinearRelative ^{CODESYS Forge talk (Post)}
Hello all I use an axis group with two linear axes in a kinematic system. Using MC_MoveLinearAbsolute and MC_MoveLinearRelative, I am trying to realise dynamic movements (set velocity: 1 m/s, set acceleration: 30 m/s^2) with the highest possible jerk, as I want to compare this with a movement with a trapezoidal velocity profile. However, my measurements show that the axes accelerate with a maximum jerk of approx. 800 m/s^3, even if the value in the function block was set to 10,000 m/s^3. I have already increased the dynamic limits of the two axes accordingly (Velocity: 5000 u/s, Acc-/Deceleration: 250'000 u/s^2, Jerk: 100'000'000 u/s^3, where 1 u = 1 mm), but this had no effect. I have checked the input parameters of the function blocks and the VelFactor, AccFactor and JerkFactor factors are all set to the maximum (value 1). Reducing the cycle time has resulted in a higher jerk, but as we are already working with a cycle time of 1 ms, there is nothing more that can be done here. The axes themselves are still a long way from drawing the maximum current, which is why I assume that this should not be a problem either. Are there other factors or parameters that influence the dynamic limits and therefore allow faster movements? The PLC I am using is a Raspberry Pi 4 and Codesys V3.5 SP20 with all libraries up to date. Thanks in advance Manuel
Last updated: 2024-05-08

Post by xcqt on Oop best practice ^{CODESYS Forge talk (Post)}
Hi all, I’m currently trying to improve my OOP structure in CODESYS and I’m looking for some input on how others approach this. I understand the basics like inheritance, interfaces, abstract FBs, methods, and properties, but I still struggle a bit with the overall architecture and what’s considered clean or scalable in bigger projects. As an example, I’m working on two different energy meter function blocks: FB_EnergyMeter_MQTT reads data from MQTT (strings) FB_EnergyMeter_Modbus reads data from Modbus (words) Both have their own Update() method and implement the same interface (something like IF_EnergyMeter). Later on, I’ll probably add more meter types, but they should all behave the same from the controller’s point of view. Now, there’s a FB_GridControl block that needs power data from these meters. I see two options here: Define the meter blocks inside FB_GridControl and call them directly (for example fbModbusMeter.UpdateModbus()). Keep the meter blocks outside and pass them into FB_GridControl as interface references, so the control block doesn’t know which specific type of meter it’s dealing with. Option 2 feels cleaner and more flexible to me, but I’m not entirely sure how to handle the data flow in that case. Should I pass the meter instance through an interface reference (REFERENCE TO IF_EnergyMeter)? Or is there a better way to link the external FBs to the control block? I’d like to hear how you structure this kind of setup or see an example from someone who has done something similar. EDIT: I think i need to do something like this fbModbusUpdateInput(wInput:= wWordValue); fbMqttUpdateInput(strInput:= strStringValue); IF bUseMqtt THEN Meter REF = fbMqttUpdateInput; ELSE Meter REF = fbModbusUpdateInput; END_IF fbControl.SetMeter(UsedMeter := Meter); Or am i thinking wrong? Thanks, Thomas
Last updated: 2025-10-16

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 bschraud on runtime received SIGABRT ^{CODESYS Forge talk (Post)}
Ich konnte den Fehler leider nicht wirklich finden. Hier mein bisheriger Fortschritt: Um nähere Informationen zu bekommen, habe ich einen strace erstellt: PID ermitteln: $ ps aux | grep codesyscontrol | grep -v grep --> 560 sudo strace -tt -f -p 560 -o /tmp/codesys_strace.log (Die Logdatei wird schnell einige hundert MB groß.) Mit grep -B 100 'si_signo=SIGABRT' /tmp/codesys_strace.log konnte ich die relevanten Einträge finden: (Die PID hat sich inzwischen wegen einem Reboot geändert) 1023 15:33:49.497136 writev(2, [{iov_base="Unexpected error 9 on netlink de"..., iov_len=45}], 1 <unfinished ...=""> .. 1023 15:33:49.498352 tgkill(545, 1023, SIGABRT <unfinished ...=""> 1023 15:33:49.498440 <... tgkill resumed> ) = 0 .. 1023 15:33:49.498730 --- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=545, si_uid=0}</unfinished></unfinished> Der Codesys Log zeigt zu diesem Zeitpunkt: Exception: HANDLED EXCPT <excpt>NonContinuable</excpt> in CH_COMM_CYCLE Mit sudo lsof -p 545 habe ich die Anzahl der geöffneten Dateien überprüft ohne Auffälligkeiten Mit sudo netstat -tunaep | grep codesys habe ich die offenen Netzwerkverbindungen der codesys Prozesse überprüft Hier sieht es so aus, dass codesyscontrol und codesysedge über die externen Netzwerkschnittstelle anstatt über den localhost kommunizieren: udp 0 0 172.19.11.127:1740 0.0.0.0: 0 17882 549/codesyscontrol. udp 0 0 172.19.11.255:1740 0.0.0.0: 0 17883 549/codesyscontrol. udp 0 0 172.19.11.255:1743 0.0.0.0: 0 16993 529/codesysedge.bin udp 0 0 172.19.11.127:1743 0.0.0.0: 0 16992 529/codesysedge.bin Leider kann ich keine Konfiguration mit einer anderen Schnittstelle einstellen.. Als nächstes habe ich die udp Kommunikation der beiden Prozesse aufgezeichnet: SPID des BlkDrvUdp Threads ermitteln: $ ps aux | grep codesyscontrol | grep -v grep --> 548 $ ps -T -p 548 | grep BlkDrvUdp --> 1200 Damit kann man den strace starten: sudo strace -p 1020 -f -tt -o /tmp/udp_control_trace.log -e trace=socket,connect,bind,sendto,recvfrom,close $ ps aux | grep codesysedge | grep -v grep --> 528 $ ps -T -p 528 | grep BlkDrvUdp --> 789 sudo strace -p 789 -f -tt -o /tmp/udp_edge_trace.log -e trace=socket,connect,bind,sendto,recvfrom,close Beim Aufzeichnen des Traces kamen wiederholte Fehlereinträge im codesyscontrol.log (diesmal ohne SIGABRT) nach folgendem Muster: tail -f /var/opt/codesys/codesyscontrol.log (mit UTC Zeit) 2025-04-17T11:23:43.147Z, 0x00000071, 1, 0, 0, Host : PAC4 2025-04-17T11:23:43.147Z, 0x00000071, 1, 0, 0, HTTP port : 8080 2025-04-17T11:23:43.147Z, 0x00000071, 1, 0, 0, HTTPS port : 443 2025-04-17T11:23:43.147Z, 0x00000071, 1, 0, 0, Connection type : HTTP 2025-04-17T11:23:43.147Z, 0x00000071, 1, 0, 0, ********** 2025-04-17T11:23:46.318Z, 0x00000061, 1, 0, 0, Create asymmetric key done! 2025-04-17T11:23:53.464Z, 0x00000071, 1, 404, 0, File $PlcLogic$/$visu$/favicon.ico not found on this server 2025-04-17T11:23:55.208Z, 0x0000100c, 1, 0, 0, Visu_PRG: Creating Client for Extern-ID: 2025487823 2025-04-17T11:23:55.216Z, 0x0000100c, 1, 0, 0, Visu_PRG: Creating Client successful for Extern-ID: 2025487823 Returned IEC-ID: 0 2025-04-17T11:40:43.471Z, 0x00000114, 4, 1, 0, ** ERROR: SysTaskCreate [CheckLicense0]: pthread_setname_np: Bad file descriptor Hier der dazu passende trace auszug von grep -B 100 '13:40:43' /tmp/udp_edge_trace.log: 798 13:40:42.592535 socket(AF_NETLINK, SOCK_RAW|SOCK_CLOEXEC, NETLINK_ROUTE) = 9 798 13:40:42.592794 bind(9, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, 12) = 0 798 13:40:42.593049 sendto(9, {{len=20, type=0x12 / NLMSG_??? /, flags=NLM_F_REQUEST|0x300, seq=1744890042, pid=0}, "\x00\x00\x00\x00"}, 20, 0, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, 12) = 20 798 13:40:42.602995 sendto(9, {{len=20, type=0x16 / NLMSG_??? /, flags=NLM_F_REQUEST|0x300, seq=1744890043, pid=0}, "\x00\x00\x00\x00"}, 20, 0, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, 12) = 20 798 13:40:42.614794 close(9) = 0 798 13:40:42.615065 socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 9 798 13:40:42.615331 close(9) = 0 798 13:40:42.616159 close(9) = 0 798 13:40:42.616318 socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 9 798 13:40:42.616555 close(9) = 0 798 13:40:42.617209 close(9) = 0 798 13:40:42.617355 socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 9 798 13:40:42.617590 close(9) = 0 798 13:40:42.618497 close(9) = 0 798 13:40:42.618712 socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 9 798 13:40:42.618995 close(9) = 0 798 13:40:42.619568 close(9) = 0 798 13:40:42.620247 close(9) = 0 798 13:40:42.620441 socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 9 798 13:40:42.620690 close(9) = 0 798 13:40:42.621181 close(9) = 0 798 13:40:42.621823 close(9) = 0 798 13:40:43.520036 close(9) = 0 798 13:40:43.520406 close(9) = 0 und grep -B 100 '13:40:43' /tmp/udp_control_trace.log 1035 13:40:43.389785 socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 20 1035 13:40:43.390043 close(20) = 0 1035 13:40:43.390681 close(20) = 0 1035 13:40:43.393690 close(20) = 0 22586 13:40:43.450945 close(0) = 0 22586 13:40:43.451230 close(0) = -1 EBADF (Ungültiger Dateideskriptor) 22586 13:40:43.451689 close(20) = 0 22586 13:40:43.452104 close(1) = 0 22586 13:40:43.452481 close(21) = 0 22586 13:40:43.452679 close(2) = 0 22586 13:40:43.452860 close(2) = -1 EBADF (Ungültiger Dateideskriptor) 1009 13:40:43.454112 close(21) = 0 22586 13:40:43.454522 close(8) = 0 22586 13:40:43.455428 close(8) = 0 22586 13:40:43.455976 close(8) = 0 22586 13:40:43.456852 close(8) = 0 22587 13:40:43.463115 close(8) = 0 22587 13:40:43.464074 close(8) = 0 22587 13:40:43.464682 close(8) = 0 22587 13:40:43.465463 close(8) = 0 22587 13:40:43.468229 close(8) = 0 22587 13:40:43.468737 close(1 <unfinished ...=""> 1009 13:40:43.468805 close(20 <unfinished ...=""> 22587 13:40:43.468849 <... close resumed> ) = 0 1009 13:40:43.468896 <... close resumed> ) = 0 22587 13:40:43.468942 close(2) = 0 22587 13:40:43.469504 +++ exited with 0 +++ 22586 13:40:43.469670 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=22587, si_uid=0, si_status=0, si_utime=0, si_stime=1} --- 22586 13:40:43.470175 +++ exited with 0 +++ 1009 13:40:43.470265 close(20) = 0 546 13:40:43.470577 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=22586, si_uid=0, si_status=0, si_utime=0, si_stime=2} --- 1035 13:40:43.470913 close(20) = -1 EBADF (Ungültiger Dateideskriptor) 22588 13:40:43.480352 --- SIGRT_7 {si_signo=SIGRT_7, si_code=SI_TKILL, si_pid=546, si_uid=0} --- 22588 13:40:43.481675 --- SIGRT_6 {si_signo=SIGRT_6, si_code=SI_TKILL, si_pid=546, si_uid=0} --- 22588 13:40:43.482410 +++ exited with 0 +++</unfinished></unfinished> Die Zeile 2025-04-17T11:40:43.471Z, 0x00000114, 4, 1, 0, **** ERROR: SysTaskCreate [CheckLicense0]: pthread_setname_np: Bad file descriptor zeigt, dass der EBADF-Fehler beim Versuch auftritt, einen neuen Thread namens "CheckLicense0" zu erstellen. Die Funktion pthread_setname_np() erhält einen EBADF-Fehler. Ich weiß leider nicht, ob das eine heiße Spur ist. Parallel dazu habe ich die Aufrufe von Systemfunktionen über SysProcess_Implementation.SysProcessExecuteCommand2 auskommentiert ohne den Fehler damit abzustellen. An diesem Punkt habe ich wegen Termindruck den alten Stand der Runtime (4.11.0.0) mit der Codesys Version 3.5 SP20 wiederhergestellt und die geänderten Programme und Visualisierungen manuell getauscht mit dem Ergebnis, dass der Fehler in den letzten 2 Stunden nicht mehr aufgetreten ist. Wenn jemand das Problem kennt, wäre ich für einen Austausch dankbar. Frohe Ostern!
Last updated: 2025-04-17

Post by imdatatas on MC_CamIn did not work properly with SMC_FreeEncoder on SoftMotion 4.17.0.0 ^{CODESYS Forge talk (Post)}
Hello, I am facing a problem with the new Softmotion 4.17.0.0 version. Has anyone encountered a similar problem, what is the solution? I would be happy if you could share it. Problem description: -- "SMC_FreeEncoder" encoder axis is the master, -- The motor of the servo driver on the EtherCAT bus is the slave axis. -- When the MC_CamIn block executed, the InSync output is activated. However, although the master encoder axis position value changes, there is no movement in the slave servo axis! Test steps: 1-) EtherCAT servo axis installed, configured and motion test was performed with MC_Jog. No problem. 2-) Softmotion general axis pool > SMC_FreeEncoder was added and pulse amount configuration was performed. No problem. 3-) Incremental encoder actual count value was transferred to the "SMC_FreeEncoder.diEncoderPosition" variable as DINT under the ethercat task in every cycle and the encoder axis position value was observed. No problem. 4-) A simple CAM table with a 1:1 ratio was created under the project tree. (For example: Simply, when the encoder rotates 1 turn, the motor will rotate 1 turn.) 5-) The SMC_FreeEncoder axis enabled with MC_Power and brought to the StandStill state. 6-) The MC_CamTableSelect block was run with default input values ​​(all absolute) and only the Cam table name was specified. The Done output was seen successfully. No problem. 7-) The MC_CamIn block was activated with default input values ​​(absolute) and only the master encoder axis name, slave servo axis name, CamTableID input pins was specified and then "Execute" input set to TRUE. 8-) The InSync output information of the MC_CamIn block observed as TRUE. However, although the encoder axis value changed, the position value of the slave axis did not change at all, it did not move. It always remained at 0.0mm. 9-) When I repeated the same steps above, only changing the master axis to SM_Drive_Virtual instead of FreeEncoder and gave movement to the virtual axis, this time the slave axis moved successfully. However, when the same steps and operations are performed with the same IDE just downgrade SoftMotion version from 4.17.0.0 to 4.10.0.0, everything works normally and without problems as expected in MC_CamIn block with FreeEncoder master. (By the way, The used IDE version is Codesys V3.5 SP20patch3.) Best Regards Imdat
Last updated: 2024-11-11

Post by jonasz on Device diagnosis ( EtherCAT IO card ) ^{CODESYS Forge talk (Post)}
Hi, I'll link to the topic not wanting to start a new one. In the application I am building, I wanted to use the diagnostics described in the CAA Device Diagnosis library. In principle, everything is ok, except for the elements related to ModbusTCP. Despite the fact that ModbusTCP is taken into account in the documentation, it is not recognised via the interfaces. FUNCTION_BLOCK NET_HW_DIAG VAR_INPUT END_VAR VAR_OUTPUT END_VAR VAR (* Referencja do struktury z danymi dla HMI ASTRAADA.*) Visu: REFERENCE TO VISU; (* Wskaźnik na mastera EtherCAT.*) pEtherCATMaster : POINTER TO IoDrvEtherCAT; (* Wskaźnik na slave EtherCAT.*) pEtherCATSlave : POINTER TO EtcSlave; (* Interfejs dla węzła w drzewie urządzeń.*) _itfNode: DED.INode; (* Ogólny interfejs magistrali. Zapewnia podstawowe informacje o magistrali polowej.*) _itfBus: DED.IBus; (* Interfejs urządzenia. Zapewnia rozszerzone informacje o urządzeniu (magistralowym).*) _itfDevice2: DED.IDevice2; (* Ogólny interfejs magistrali. Zapewnia podstawowe informacje o magistrali polowej.*) _itfStack: DED.IStack; (* Numer węzła w drzewie urządzeń.*) uiNodes: UINT; (* Operator jest rozszerzeniem normy IEC 61131-3. W czasie wykonywania operator wykonuje konwersję typu odwołania do interfejsu na inny typ. Operator zwraca wynik BOOL. Wartość TRUE oznacza, że CODESYS pomyślnie wykonał konwersję. *) xQueryResultBus: BOOL; xQueryResultDevice2: BOOL; xQueryResultStack: BOOL; (* Struktura danych dotyczących węzłów w drzewie urządzeń.*) NetHwDiag: NW_HW_STAT; ModbusTcpClientDeviceInfo: IoDrvModbusTCP.DED.DEVICE_INFO; ModbusTcpClientDeviceState: IoDrvModbusTCP.DED.DEVICE_STATE; ModbusTcpDeviceInfo: IoDrvModbusTCP.DED.DEVICE_INFO; ModbusTcpDeviceState: IoDrvModbusTCP.DED.DEVICE_STATE; END_VAR (* Pobranie wskaźników dla pierwszego mastera i pierwszego slave w sieci EtherCAT.*) pEtherCATMaster := g_pFirstMaster; pEtherCATSlave := pEtherCATMaster^.FirstSlave; (* Diagnostyka sieci EtherCAT.*) pEtherCATMaster := g_pFirstMaster; pEtherCATSlave := pEtherCATMaster^.FirstSlave; NetHwDiag.xConfigFinished := pEtherCATMaster^.xConfigFinished; NetHwDiag.xDistributedClockInSync := pEtherCATMaster^.xDistributedClockInSync; NetHwDiag.xError := pEtherCATMaster^.xError; NetHwDiag.xSyncInWindow := pEtherCATMaster^.xSyncInWindow; NetHwDiag.sLastMessage := pEtherCATMaster^.LastMessage; NetHwDiag.LastError := pEtherCATMaster^.LastError; (* Diagnostyka drzewa urządzeń.*) uiNodes := 0; _itfNode := DED.GetRoot(); REPEAT NetHwDiag.asDeviceName[uiNodes] := DED.GetDeviceNameString(itfNode := _itfNode); xQueryResultBus := __QUERYINTERFACE(_itfNode,_itfBus); IF xQueryResultBus THEN _itfBus.GetBusInfo(buiInfo := NetHwDiag.aBusInfo[uiNodes]); NetHwDiag.aBusState[uiNodes] := _itfBus.GetBusState(); END_IF xQueryResultDevice2 := __QUERYINTERFACE(_itfNode,_itfDevice2); IF xQueryResultDevice2 THEN _itfDevice2.GetDeviceInfo(deiInfo := NetHwDiag.aDeviceInfo[uiNodes]); NetHwDiag.aDeviceState[uiNodes] := _itfDevice2.GetDeviceState(); IF pEtherCATSlave <>0 THEN pEtherCATSlave^(); IF pEtherCATSlave^.SlaveAddr = NetHwDiag.aDeviceInfo[uiNodes].idSystem THEN NetHwDiag.aAlStatus[uiNodes] := pEtherCATSlave^.ALStatus; pEtherCATSlave := pEtherCATSlave^.NextInstance; END_IF END_IF ELSE xQueryResultStack := __QUERYINTERFACE(_itfNode,_itfStack); IF xQueryResultStack THEN _itfStack.GetDeviceInfo(deiInfo := NetHwDiag.aDeviceInfo[uiNodes]); NetHwDiag.aDeviceState[uiNodes] := _itfStack.GetDeviceState(); END_IF END_IF uiNodes := uiNodes + 1; _itfNode := DED.GetNextNode(_itfNode); UNTIL _itfNode = 0 END_REPEAT (* Diagnostyka Modbus.*) Modbus_TCP_Client.GetDeviceInfo(deiInfo := ModbusTcpClientDeviceInfo); ModbusTcpClientDeviceState := Modbus_TCP_Client.GetDeviceState(); PAC_3200T.GetDeviceInfo(deiInfo := ModbusTcpDeviceInfo); ModbusTcpDeviceState := PAC_3200T.GetDeviceState(); Of course, you can take the easy way out and refer directly to the devices, but I wanted a reusable component. Any constructive help is very welcome Best regards Jonasz
Last updated: 2025-07-15

Sort by relevance or date