Post by rabaggett on Reading Named Pipes in Linux Is there a better way? ^{CODESYS Forge talk (Post)}
I have a Python program that will handle things in my application such as VISA over IP and Telnet control of instruments. I want the main control and HMI in Codesys. My problem is communication between the two. I have looked at several ways to accomplish this, and settled on having the Python program create two named pipes, one to send information to Codesys, and one for Codesys to send information to Python. The information would be packetized with \n for end of packet.. Seems simple. I think the named pipes method should work, but file reading in Codesys using the CAA file library starts to get difficult when the file is never ending, as in this case. Before I spend too much time making something that may be fundamentally flawed I want to ask. Is there a better way? Is there a way to read the file 'one line at a time' which might solve my never ending file problem? Thanks!
Last updated: 2024-05-09

Post by bertcom on STRING conversions to DWORD ^{CODESYS Forge talk (Post)}
Good afternoon. I want to communicate with a Domino Industrial Printer using its Codenet protocol. The printer wants a series of Hexadecimal characters with no spaces or '00' characters. Because of that i chose the option to make the prefix and subfix for my code in a string. I have variable data in another string. With a complete program of a lot of CONCAT functions i eventually get the format of code that the printer accepts ( tested it with the hercules tool). Hercules String : 1B4F513030311B7532626C61636B04 The problem is : Codesys adds automatically 'code' to the code to show it is a string. Codesys string : '1B4F513030311B7532626C61636B04' The printer does not understand this. My idea is to convert the string datatype to an LWORD. I have no idea how to do this. I random types in STRING_TO_DWORD, as return i get 0. That didn't worked. Also on internet the explenations around string converting in codesys are very limited. If there in anyone who can explain me how to do it, i would appreciate it a lot ! Thank you!
Last updated: 2025-01-29

Post by mubeta on Profibus DP master with EL6731 and automatic restart of slaves ^{CODESYS Forge talk (Post)}
WHEREAS, I have already searched various posts and forums, where mostly there are few references and mostly geared toward integration in TwinCAT. I am looking for how to properly configure the EL6731 board as a DP master, (where I have its 3S license), with CoDeSys 3.5.19.x. I have three types of slaves, all integrated with their GSD descriptors. In the tab for the various slaves, I don't see options related to node restart on 'station return'. On the card manual, I read that for each slave I should be able to configure parameter 8000:2C: “8000:2C Restart behavior after DP fault Reserve, must be 0 BIT1 RW 0x00 (0dec)” However, in the project I see no way to configure this parameter, in any of the boards; and the arrays do not always have such an extensive size; most of the time they are only two or three words in size. The problem is that, after the hot reset of CoDeSys, the master restarts by starting all slave nodes, but if one or more get lost and go offline, there is then no automatic restart upon their return. I would need to figure out any solution, even via software, how to figure out that this one is back available and restart it.
Last updated: 2025-02-02

Post by pernockham on Inheritence of struct, ^{CODESYS Forge talk (Post)}
Im looking for a way to define predefined version of the same structures through "extends"/inheritance. What I want to do is best shown with an example: TYPE log_item_val_type : ( BOOL_ := 0, INT_, REAL_, STRING_ ); END_TYPE TYPE LOG_DATA_BASE STRUCT val_type : log_item_val_type; (* value, name etc *) ENDSTRUCT ENDTYPE (* this/below is not possible as I understand from the compiler?? *) TYPE LOG_DATA_BOOL extends LOG_DATA_BASE : STRUCT val_type : log_item_val_type := log_item_val_type.BOOL_; END_STRUCT END_TYPE TYPE LOG_DATA_INT extends LOG_DATA_BASE : STRUCT val_type : log_item_val_type := log_item_val_type.INT_; END_STRUCT END_TYPE etc. for LOG_DATA_REAL and ..STRING. The system will not allow me to "re-define" "val_type" however. Instead I must do the work-around of defining four different types with all fields individually defined. The benefit if I could extend the base item would be that Im (more) sure the structures are identical. In usage I can call in a specific type rather use the base type and assign which type. Usage by pointer/ref to log_data_base would also be easier.. (* Usage: *) log_data : log_data_int := (name, value etc.) (* Instead of: *) log_data : log_data_base := (name, value, val_type).. Is this possible to achieve in some way that I have missed?
Last updated: 2025-03-05

Post by antonz on CoDeSys v3.5: creating libraries for both 32-bit and 64-bit controllers ^{CODESYS Forge talk (Post)}
Looking for thoughts on creating libraries that can be used on both 32-bit and 64-bit controllers. We are currently writing software in CoDeSys for both target types and will continu to do so for the near future. Projects are always unique, no straight forward copy/paste, yet there is enough similarity between them to use libraries for recurring logic. I do not want to create and maintain twice for both platforms if this is not absolutely necessary. I am aware of useful datatypes like __XWORD, __XINT, __UXINT. Still looking for more information and/or sample code for portable pointer arithmetic. In addition to that: how should one go about when creating and working with compiled libraries? Would I need to compile the same lib twice, once for 32-bit targets once for 64-bit targets? I would end up with two different libs with the same namespace, which does not sound elegant to me. Note: I did not intentionally make the previous paragraph bold. The forge forum software seems to do this automatically upon insertion of a word which starts with two underscores, e.g. __XWORD (yeah, here we go again :) )
Last updated: 2025-08-25

Post by duvanmoreno24 on Modbus writing on value change ^{CODESYS Forge talk (Post)}
Yes, I tried to do what you put in the first code. However, I have a problem with that and that is that the inputs must be declared with the type. I have many data types running in my code (real, int, uint, bool) and I can't put them in the same function, another thing is that I need to instantiate that function for everything I want to write to the slave. You put a for to 200 but it means that it has to be the same data type and inside the array, but I want to get them individually. I'm struggling to do it in a good and efficient way like wago's E-cockpit does. in the first screenshot you can see, you simply type in value, change the package of things you want to write in value change and it does everything by itself automatically, without comparing any old and new values and even less having the need to activate a bool. , it is perfect.
Last updated: 2024-04-03

Post by r-niedermayer on OPC UA subscriber not operational ^{CODESYS Forge talk (Post)}
Hi. As far as projects in "old version"s are concerned, these can be upgraded to newer versions at any time. To do this, the device must be updated accordingly and the copilers and library versions must be adapted. You can find instructions on how to proceed in the online help/FAQ: https://content.helpme-codesys.com/en/CODESYS%20Development%20System/_cds_changing_compiler_version.html https://content.helpme-codesys.com/en/CODESYS%20Development%20System/_cds_cmd_update_device.html See also 4.3.22.4 "How to open an Example Project" within the following pdf for more details on the single steps: https://forge.codesys.com/lib/counit/tickets/_discuss/thread/3e991befbc/ca97/attachment/Public%20FAQ-v13-20240610_075228.pdf Regaring your OPCUA connection state always showing just "DISABLED", without knowing both sides of the assembly in detail, one can only approach the problem theoretically. We can give a chekclist on how to proceed: Fist, please recheck the communication settings in the OPC UA connection function block to ensure that the server URL, endpoint URL, and other settings are correct and match the configuration of the OPC UA server. Verify that the OPC UA server is running and accessible. -You can try to connect to the OPC UA server using a separate client, such as UAExpert, to ensure that the issue is not related to the OPC UA server itself. Test the security settings in the OPC UA connection function block to ensure that the correct security policy and certificate are selected. If you are using a dynamic connection to the OPC UA server, probe that the connection settings are correctly configured and that the OPC UA client is able to establish a connection to the OPC UA server. Also, please loock into the log files for any errors related to the OPC UA connection function block, these should be listet there. The log files may also provide additional information about the issue and help you to further troubleshoot the problem. FYI - Please see https://content.helpme-codesys.com/en/CODESYS%20Communication/_cds_obj_data_source_communication_opc_ua_server.html: Her you can finde the Communication settings via OPC UA Server -> layout Browse Live Server: The client connects to the server and detects the existing variables and types. From Information Model The client reads the data structure (layout) of the OPC UA Server from the information model set here and as a result receives the information about available variables and types. A connection to the server is not required. The list contains the information models installed in the OPC UA Information Model Repository. "Read Connection" Settings from IEC Variable (option set): - The connection settings used by the device are not read here from the dialog, but at runtime from the IEC variable specified here. - For this possibility, please see the Using a Dynamic Connection to an OPC UA Server (https://content.helpme-codesys.com/en/CODESYS%20Communication/_comm_use_dynamic_opc_ua_server_comm_settings.html) The settings for the communication of a Client-data source to an OPC UA Server can also be dynamically configured from the IEC code and can also be changed at runtime. For such a purpose, a structure is available in the DatasourceOpcUAServer library (For a description of the OPC UA Server, there is one included in the standard installation of CODESYS, https://content.helpme-codesys.com/en/CODESYS%20Communication/_cds_encrypt_communication_data_sources_opc_ua_client.html)
Last updated: 2024-11-04

Post by jami on Reading multiple lines from csv file ^{CODESYS Forge talk (Post)}
Hello, i am trying to read multiple lines from csv file with caa file library and oscat. I have wrote 7 lines in the csv with separation '$R$L'. In my "extracting values" part I check line feeds and chars. After that I convert my buffer to string with oscat but I'm only able to read the first line from the csv. No matter if I even change start position where I start converting the buffer, I only get the first line. Here's my code for the reading and extracting value parts: 4: (*Reading the file*) fileread.hFile := filehandle; fileread.pBuffer := ADR(buffer); filesize1:=SIZEOF (buffer); fileread.szbuffer:=filesize1; fileread.udiTimeOut := 100000; fileread(xExecute := TRUE); IF fileRead.xDone THEN iFilesize:=TO_INT(fileread.szSize); writestate:=3; fileRead.xExecute := FALSE; END_IF 5: (*Extracting values*) //here i check the number of line feeds and chars. It works WHILE i < ifilesize DO c:=buffer[i]; IF c= 10 THEN IF lineindex<=99 THEN lineIndex := lineIndex + 1; END_IF ELSIF c <> 13 THEN IF charIndex <= 1000 THEN charIndex := charIndex + 1; END_IF END_IF i := i + 1; END_WHILE // Here i convert the buffer to string and transfer it to filelines:ARRAY[0..99] of string[254]. trig(CLK:=BUTTON); IF trig.Q THEN fileLines[i2]:=oscat_basic.BUFFER_TO_STRING(PT:=ADR(buffer), Size:=TO_UINT(fileread.szBuffer), start:=TO_UINT(bufferStart), stop:=TO_UINT(filesize1)); i2:=i2+1; bufferstart:=bufferstart+80; END_IF If anyone has idea how to read multiple lines, it would be nice. Even if you have example codes that work, that would help a lot.
Last updated: 2025-07-18

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

Post by gilbert-mh on CAA net base TCP client cause PLC to crash - Kernel message : N0HZ_local_softirq_pending 80 ^{CODESYS Forge talk (Post)}
Hello all, I have been trying to implement a TCP client on a Festo PLC (CPX-E-CEC-M1) and it looks like it works well except that after some time (greatly varies between a few hours to more than 100h) my PLC crash. When I look into the log file the only thing I see is that before the crash happens a few kernel warnings : N0HZ_local_softirq_pending 80 and then the crash. I've looked into this warning and from what I could find on the net it seems that this is warning is triggered when the ethernet link is down. I've tried to correct this bug for quite some time and what I know is that : - The crash is caused by my TCP client, when I remove it from my code I see no crash - The crash happens more quickly the more the TCP client is used. - The time before the crash is not directly proportional to the number of communications or their size. But it looks like it is just more likely to happen if the client connect to the server at a higher frequency. - The precedent observation makes it seem unlikely that the crash is caused by some memory overflow because then the crash speed would be more proportional to the amount of data exchanged. SO from these observations, I believe that the crash could be caused by the PLC trying to connect to a server while there is some kind of issue with the ethernet link resulting in the PLC getting stuck in some indefinite state and making it crash. This still seems a bit unlikely to me because if the ethernet is down it simply shouldn't be able to contact the server and the communication would just fail which doesn't cause my PLC to crash. Has anyone encountered the same kind of problem (with the same kernel message) ? I am pretty sure the warning is not the direct cause of the crash but just an indicator that something is wrong with my PLC. Thanks in advance
Last updated: 2024-01-12

Post by critcho on WebVisu Numpad dialog - Dialogtitle not accepting string variable ^{CODESYS Forge talk (Post)}
I have a WebVisu page which is re-used for multiple types of gas; it displays the alarm thresholds etc. for one gas at a time. I have an array of structures holding the set-points for each of the gasses. I'm trying to change the dialog title for the value input pop-up (VisuDialogs.Numpad). The Dialogtitle is set to Gas_Alarms.HighAlarmActivationLevelDialog, which is a string(50): When the gas type is changed (page first loaded, or prev/next buttons), METHOD Gas_Alarms.Update_Display_Variables is called, to update the strings used for the dialog titles so it shows GasName High Alarm Activation Level (EngineeringUnits), e.g. CO2 High Alarm Activation Level (PPM): HighAlarmActivationLevelDialog := Insert(' High Alarm Activation Level ()', EngineeringUnits, 30); HighAlarmActivationLevelDialog := Insert(HighAlarmActivationLevelDialog, GasName, 0); (That's not where the problem is, I'm just explaining why I'm using a variable dialogue title.) The variables used are definitely strings, but i'm always getting the error: "The type of the dialog title must be either STRING or WSTRING". I've tried moving HighAlarmActivationLevelDialog etc. to the GVL and also changing them to WSTRING, I even tried adding them to the structure array, but I always get the same error. Clearing the dialog title for that element removes the error - so I'm confident it's not a phantom error caused by something else. But I should be able to add these titles, can't just nuke them all to make it work. The MinVal and MaxVal for the Numpad are called from the array, e.g. GVL.Gas_Alarm_Configs[0].ScaledValueMIN, they are not getting an error. I am using array indexes 1 - 5 for the gasses, when I load the form or change gas, I copy the selected index to index 0 of the array, and values from Gas_Alarm_Configs[0].[ALL] are displayed on the page. When they hit save, I copy Gas_Alarm_Configs[0].[ALL] to Gas_Alarm_Configs[CurrentGasIndex].[ALL]. (ALL just means every element, I can't figure out how to display an asterix in this question... :) ) I've searched online for variable title dialog, but not found anything to help. Thanks for your help!
Last updated: 2025-05-29

Post by paulg on RasPi CAA Serial example - unexpected behavior during debug ^{CODESYS Forge talk (Post)}
I've trimmed down the CAA Serial Codesys example to only listen on one port but, when stepping through the Case structure in debug mode, it jumps out of the structure during a specific point in every scan (I'll point it out below after describing the setup and listing the code). I'm using a Pi 4 Model B, and I have an Arduino Nano Every plugged in via USB which is streaming the following serial message at 1 Hz: Time since opening connection: 1 s Time since opening connection: 2 s ...and so on. The Pi shows the Nano at /dev/ttyACM0 so I edited CODESYSControl_User.cfg to read: Linux.Devicefile=/dev/ttyACM The code in my PLC_PRG is (ignore some of the comments, I hadn't deleted them out from the original example): PROGRAM PLC_PRG VAR xStartTest : BOOL:= TRUE; iState : INT; xTestDone : BOOL;(* True, when the test was done succesfully *) (* Settings to communicate with the COM Port *) aCom1Params : ARRAY [1..7] OF COM.PARAMETER; como1 : COM.Open; comc1 : COM.Close; comw1 : COM.Write; comr1 : COM.Read; //sWrite : STRING := 'Test String!'; sRead : STRING(25); szRead : CAA.SIZE; xCom1OpenError : BOOL; xCom1CloseError : BOOL; xCom1WriteError : BOOL; xCom1ReadError : BOOL; END_VAR //This example shows the communication of two COM Ports with each other. //The first one writes a string of characters, which is read by the second one. //After successful execution, the two COM Ports are closed and the test is done. IF xStartTest THEN CASE iState OF 0: //The parameters are set for the COM Port aCom1Params[1].udiParameterId := COM.CAA_Parameter_Constants.udiPort; aCom1Params[1].udiValue := 1; // the correct Port should be adapted aCom1Params[2].udiParameterId := COM.CAA_Parameter_Constants.udiBaudrate; aCom1Params[2].udiValue := 115200; aCom1Params[3].udiParameterId := COM.CAA_Parameter_Constants.udiParity; aCom1Params[3].udiValue := INT_TO_UDINT(COM.PARITY.NONE); aCom1Params[4].udiParameterId := COM.CAA_Parameter_Constants.udiStopBits; aCom1Params[4].udiValue := INT_TO_UDINT(COM.STOPBIT.ONESTOPBIT); aCom1Params[5].udiParameterId := COM.CAA_Parameter_Constants.udiTimeout; aCom1Params[5].udiValue := 0; aCom1Params[6].udiParameterId := COM.CAA_Parameter_Constants.udiByteSize; aCom1Params[6].udiValue := 8; aCom1Params[7].udiParameterId := COM.CAA_Parameter_Constants.udiBinary; aCom1Params[7].udiValue := 0; //The first Port is opened with the given parameters como1(xExecute := TRUE, usiListLength:=SIZEOF(aCom1Params)/SIZEOF(COM.PARAMETER),pParameterList:= ADR(aCom1Params)); IF como1.xError THEN xCom1OpenError := TRUE; iState := 1000; END_IF //After a successful opening, the next state is reached IF como1.xDone THEN iState := 15; END_IF 15: // the reading process is started comr1(xExecute := TRUE,hCom:= como1.hCom, pBuffer:= ADR(sRead), szBuffer:= SIZEOF(sRead)); IF comr1.xError THEN xCom1ReadError := TRUE; END_IF //After completion the size of the written bytes are saved IF comr1.xDone OR comr1.xError THEN szRead := comr1.szSize; iState := 20; END_IF 20: // If everything was successful the ports are closed and the handles are released comc1(xExecute := TRUE,hCom:= como1.hCom); IF comc1.xError THEN xCom1CloseError := TRUE; END_IF IF comc1.xDone OR comc1.xError THEN iState := 25; END_IF 25: // The first port is closed and the used handle released xTestDone := TRUE; xStartTest := FALSE; iState := 0; como1(xExecute := FALSE); comw1(xExecute := FALSE); comc1(xExecute := FALSE); ELSE iState := 0; END_CASE END_IF I realize as I write this that the .udiPort should be 0 and not 1, but that shouldn't be causing the issue I'm seeing. I'm forcing xStartTest:=TRUE every scan so that I can step into each line and observe what's happening. What I see is that the port parameters are set and the port is opened with no errors, but the code jumps out of the case structure to the last line every time it reaches (and I step into) the iState:=15 line (at the end of the iState:=0 block). So every scan cycle it goes through the block for iState=0 and jumps out at the same spot. I'm a little new to PLC programming so I may be misunderstanding the flow, but shouldn't this case structure keep moving down in the same scan? If it only handles one case per scan, why doesn't the value of iState persist? Thanks! Update: I restarted the Codesys control today and I was then able to see an error for como1.eError of "WRONG_PARAMETER". I tried doing some digging and another post made me think I should add another line to CODESYSControl_User.cfg, so I now have: [SysCom] Linux.Devicefile=/dev/ttyACM portnum := COM.SysCom.SYS_COMPORT1 So now when I set .udiPort to 1, I get "NO_ERROR" but I also don't read anything from the port (i.e. szRead = 0 always). If I try setting the port to 0 (which I'm confused about, because I added a COMPORT1 line but the device shows on the Pi as ACM0), I get the "WRONG_PARAMETER" error again. Is there an easier way to troubleshoot the Pi and view what ports the Codesys runtime is actually able to see while the Pi is running?
Last updated: 2024-06-06

Post by struccc on Inheritence of struct, ^{CODESYS Forge talk (Post)}
Strangely reminds me to my struggles... Want to do something "Elegant", reusable, universal, practical... In CODESYS??? 🙃 First of all, before you get too deep into this: If you could find a way, to make a "universal" log entry object, containing the variable length data itself, you wouldn't be able to store them in an array, or access them like an array, or pass them by value as a type. (please correct me, if I'm wrong, incorrect, or not precise). Because... Basically you can't declare a type with variable memory footprint. This is a very deeply embedded characteristic of CODESYS, and all IEC 61131-3 systems, and it has many reasons behind. And yes, it is a very common trap / mistake, to forget about. So, with a log entry - I guess - it's pretty much the purpose: store data and metadata together, and then handle it in a uniform way. There are ways to handle this, really depends on what is the purpose. For example: 1. Entries with fixed length (Maybe it is not as evil as it looks for the first time. Depends on the situation, but definitely the fastest and easiest code) You can have your base object, with an internal, fixed length string or byte array variable. I would go with a string, and call it _Data.; And then you can make properties, like As_Bool, As_Int, As_Real... In the 'set' accessors, you can do like: pReal := ADR(_Data); // POINTER TO REAL As_Real := pReal^; In the 'get' accessors, evidently: pReal := ADR(_Data); // POINTER TO REAL pReal^ := AS_Real; Or, can use ANY type, if you are not obsessed with variable / property like access: 2. Fixed length, but nicer First, some disadvantage to any values: - You can only assign values with write access. No literals, constants, etc... - Can only be used as input variable of function or function_block - Therefore, stg you could reach: LogEntry.Initialize (stVariable|rVariable|iVariable|xVariable); Just a quick example (it's funny to play with ANY): Be careful it was not tested. I'm sure can be done better, please feel free to comment FUNCTION_BLOCK FB_LogEntry VAR_INPUT MsgClass : UDINT; // Like DEBUG, WARN, ERR... MsgCode : UDINT; // Like Errors.ERR_FAILED MsgTS : DT; // The timestamp END_VAR VAR _Data : STRING(80); // Our data container... _Descr : __SYSTEM.AnyType; // A standard descriptor for our data, containing TYPE_CLASS, address and size END_VAR METHOD SET_Value : BOOL VAR_INPUT anyValue : ANY; END_VAR VAR I : DINT; diSize : DINT; pStr : POINTER TO STRING; END_VAR // Check what did we receive in anyValue. diSize := anyValue.diSize; // We use constant __SYSTEM.TYPE_CLASS to identify the received data type CASE anyValue.TypeClass OF // Maybe we don't want to store references, pointers... and who knows what else... __SYSTEM.TYPE_CLASS.TYPE_REFERENCE, __SYSTEM.TYPE_CLASS.TYPE_POINTER : SET_Value := FALSE; // For the planned types we will be just fine. TYPE_CLASS.TYPE_BOOL, TYPE_CLASS.TYPE_INT, TYPE_CLASS.TYPE_REAL : SET_Value := TRUE; // Optionally string can be handled separately, maybe we have received STRING(255), but practically it is shorter than 80 bytes... TYPE_CLASS.TYPE_STRING : pStr := anyValue.pValue; diSize := MIN(anyValue.diSize, LEN(pStr^) + 1); // Get the actual size, and rewrite the received structure member diSize := MIN(SIZEOF(_Data), diSize); // Can chop down the received string to our length... SET_Value := TRUE; // Maybe want to play a little bit more here, to narrow down or convert datatypes, etc... // Or just reject any other datatype ELSE SET_Value := FALSE; RETURN; END_CASE // Fail, if the received value is still larger than our container... IF diSize > SIZEOF(_Data) THEN SET_Value := FALSE; END_IF // Here we should be ok, just set up the _DataType structure, and copy store the data IF SET_Value THEN THIS^._Descr.TypeClass := anyValue.TypeClass; // The typeclass is already filtered THIS^._Descr.diSize := diSize; // Set the (adjusted) size THIS^._Descr.pValue := ADR(_Data); // This will not change, just to be sure {IF defined (pou:SysMem.SysMemCpy)} SysMem.SysMemCpy(_DataType.pValue, anyValue.pValue, TO_UDINT(anyValue.diSize)); {ELSE} // An ugly replacement MemCpy FOR I:=0 TO diSize - 1 DO _Descr.pValue[I] := anyValue.pValue[i]; END_FOR {END_IF} // Otherwise, in case of failure maybe better set an empty value (overwrite the former data descriptor) ELSE THIS^._Descr.TypeClass := TYPE_CLASS.TYPE_NONE; THIS^._Descr.pValue := ADR(_Data); THIS^._Descr.diSize := 0; END_IF METHOD GET_Value : BOOL VAR_INPUT anyValue : ANY; END_VAR VAR I : DINT; END_VAR // We just have to serve the data, using the __System.AnyType structure received // Roughly we can say: IF anyValue.TypeClass = _Descr.TypeClass AND anyValue.pValue <> 0 // This should not be possible, already taken care of by Codesys (?) THEN {IF defined (pou:SysMem.SysMemCpy)} SysMem.SysMemCpy(anyValue.pValue, _DataType.pValue, TO_UDINT(MIN(anyValue.diSize, _Descr.diSize))); {ELSE} // An ugly replacement MemCpy FOR I:=0 TO MIN(anyValue.diSize -1, _Descr.diSize - 1) DO anyValue.pValue[I] := _Descr.pValue[I]; END_FOR {END_IF} // Just to make sure, that our string is terminated... IF anyValue.TypeClass = TYPE_CLASS.TYPE_STRING THEN anyValue.pValue[anyValue.diSize -1] := 0; END_IF GET_Value := TRUE; RETURN; END_IF // ... But can play more CASE anyValue.TypeClass OF TYPE_CLASS.TYPE_WSTRING : ; // Could do conversion TYPE_CLASS.TYPE_XSTRING : ; // Wow, I have to figure this out TYPE_CLASS.TYPE_PARAMS : ; // BTW, what is this, how to use? TYPE_CLASS.TYPE_ANYNUM : ; // ... END_CASE Be careful it was not tested. I'm sure can be done better, please feel free to comment 3. If you really want to do entries with variable size In a standard environment, it would be similar to the previous, except you dont have the container variable _Data, just use a pointer, practically _Descr.pValue At Initialize (SET_Value), you have to allocate the memory, would be easy with SysMem.SysMemAlloc - nowadays with SysMem.SysMemAllocData -, and you make sure to release it after use with SysMem.SysMemFreeData... SysMemAlloc was already hidden. The problem with this, that sooner or later your application will totally fragment the dynamic memory, and fail... So should look for some form of dynMaybe MemUtils.MemoryManager (I am not sure what is the status and the future of it). 4. You will end up by a LogEntry Factory ... 5. You could still have a look at this IEC Snippets BTW, Standard Codesys Logger is not a bad choice either. If you are really interested, I share some more code / library.
Last updated: 2025-03-09

Sort by relevance or date