Post by gilad on CODESYS SoftMotion Generic DSP402 on WAGO PFC200 + Festo CMMT-AS: MC_Power stays Busy, Controlword remains 0 ^{CODESYS Forge talk (Post)}
Hello, I am trying to connect a Festo CMMT-AS-C4-3A-MP-S1 servo drive to a WAGO PFC200 (750-8210) using EtherCAT and CODESYS SoftMotion. Hardware PLC: WAGO PFC200 750-8210 Drive: Festo CMMT-AS-C4-3A-MP-S1 Communication: EtherCAT CODESYS version: Device description version 6.3.1.1 Drive firmware: 36.10.3 Current Status EtherCAT communication is working correctly: EtherCAT master = Running Drive detected and operational PDO input and output mapping is active Statusword, position and velocity are updating correctly Current PDO mapping: Outputs: 6040 Controlword -> %QW0 6060 Modes of operation -> %QB2 607A Target position -> %QD1 60FF Target velocity -> %QD3 Inputs: 6041 Statusword -> %IW2 6061 Modes of operation display -> %IB6 6064 Position actual value -> %ID2 606C Velocity actual value -> %ID3 SoftMotion Axis I added a SoftMotion CiA402 axis under the EtherCAT slave: Axis type: SM_Drive_GenericDSP402 Axis communication state: operational (100) No SoftMotion mapping errors anymore Problem MC_Power is executed with: Enable = TRUE bRegulatorOn = TRUE bDriveStart = TRUE but: Status = FALSE Busy = TRUE Error = FALSE ErrorID = SMC_NO_ERROR The axis remains in: SMC_AXIS_STATE.power_off DSP402 state = SWITCH_ON_DISABLED The most important observation: Statusword = 32784 (0x8010) Controlword (%QW0) remains 0 all the time SoftMotion never writes 6, 7, or 15 to the Controlword. Additional Information The axis status page reports: "The license is missing or invalid. The PLC runs in demo mode." I am not sure whether: The missing SoftMotion license prevents Controlword generation completely. The axis is still not correctly connected to the EtherCAT slave despite operational communication. There is an additional CiA402 configuration step required for the Festo CMMT-AS drive. Has anyone successfully used a Festo CMMT-AS MP drive with CODESYS SoftMotion Generic DSP402 on a WAGO PFC200? Any suggestions on what should be checked next would be greatly appreciated.
Last updated: 2026-06-24

Post by rmarco on Generic Variables and FDB ^{CODESYS Forge talk (Post)}
Hello everyone, I am running into a highly frustrating issue in the FBD editor regarding a Function Block with generic constants (VAR_GENERIC CONSTANT). I created a FB using ST, with a generic var, useful for having a variable sized array, as follows: FUNCTION_BLOCK Coil VAR_GENERIC CONSTANT maxEvents: USINT := 5; END_VAR VAR events: ARRAY[0..maxEvents-1] OF IEvent; END_VAR These FBs have also several methods. I declare them as follows in code: VAR coil1: CDL.Coil<(maxEvents:=1)>; END_VAR and when using them in ST, I have no problems. However, when trying to use them in FDB, I do not know how to do that, as some strange misalignment happens. Here's what happens: When I add the block to my FBD canvas and assign coil1 as the instance name, the compiler throws this error: 'coil1' is not an instance of 'CDL.Coil<(maxEvents:=1)>'. Same occurs when I try to instantiate blocks such as 'coil1.turnOn' or similar. Here is what I have already tried, none of which worked: - Deleting the <(maxEvents:=1)> parameter from the text inside the FBD box. - Deleting the block entirely, dropping an "Empty Box", and typing coil1 above it to let the IDE auto-complete and format the block. - Running a full "Clean All" and rebuilding the code. I am aware that I could bypass the graphical editor by calling it in Structured Text. However, I need to keep this logic compatible to FBD. Has anyone encountered this specific FBD parsing bug with generic variables? Thanks in advance for any insights. Best regards, Marco
Last updated: 2026-06-29

Post by jzhvymetal77 on IecVarAccessLibrary.IBaseTreeNode methon ^{CODESYS Forge talk (Post)}
I had this code working in a previous version of CoDeSys to read variables from a GVL that were added to the Symbol configuration. The problem now is that when I get the _IBaseTreeNode_Parent, it returns a valid interface, but none of the methods or properties work. If you monitor the _IBaseTreeNode in the watch window, it does show the correct child count. However, it fails at step 30, where the child count incorrectly returns zero. In the image, you can see that the watch window displays the correct value that the property should return. Attached is the full project code. FUNCTION_BLOCK Symbols_TO_STR VAR_INPUT i_sPath : STRING(255); i_diIndexChild : DINT; i_diIndexComponent : DINT; END_VAR VAR_OUTPUT q_diChildCount : DINT; q_diComponentCount : DINT; q_sName : STRING(255); q_sValue : STRING(255); q_sType : STRING(80); q_sErrorResult : STRING(80); END_VAR VAR uiStepCopy : UINT; uiStep : UINT; uiStepProcessCopy : UINT; uiStepProcess : UINT; _IBase : IecVarAccessLibrary.IBase; _pIIecVarAccess5 : POINTER TO IecVarAccessLibrary.IIecVarAccess5; _IIecVarAccess5 : IecVarAccessLibrary.IIecVarAccess5; _RTS_IEC_RESULT : IecVarAccessLibrary.RTS_IEC_RESULT; _udiResult : UDINT; _VariableInformationStruct : IecVarAccessLibrary.VariableInformationStruct; _IBaseTreeNode_Parent : IecVarAccessLibrary.IBaseTreeNode; _IBaseTreeNode_Child : IecVarAccessLibrary.IBaseTreeNode; _ITypeDesc_Child : IecVarAccessLibrary.ITypeDesc; _TypeDescAsUnion_Child : IecVarAccessLibrary.TypeDescAsUnion; _arIBaseTreeNode_Child : ARRAY[0..20] OF IecVarAccessLibrary.IBaseTreeNode; _TypeClass_Child : IecVarAccessLibrary.IBaseLibrary.TypeClass; _psSymbolName_Child : POINTER TO STRING; _sSymbolName_Child : STRING(255); _IBaseTreeNode_Component : REFERENCE TO IecVarAccessLibrary.IBaseTreeNode; _TypeClass_Component : IecVarAccessLibrary.IBaseLibrary.TypeClass; _ByteAddress_Component : __XWORD; _ByteOffset_Component : __XWORD; _sArrayIndexName_Component : STRING(20); _diArrayIndexCalc_Component : DINT; _diArrayIndexValue_Component: DINT; _psSymbolName_Component : POINTER TO STRING; _sSymbolName_Component : STRING(255); END_VAR uiStepCopy:=uiStep; uiStepProcessCopy:=uiStepProcess; CASE uiStep OF 10: // GET IBASE FROM CURRENT APP _IBase:= IecVarAccessLibrary.IecVarAccGetFirstInterface2(0); IF _IBase<>0 THEN uiStep:=20; ELSE q_sErrorResult:=CONCAT(UINT_TO_STRING(uiStep), ': IecVarAccGetFirstInterface2'); uiStep:=9000; END_IF 20: //QueryInterface IIecVarAccess5 from IBASE _pIIecVarAccess5 := _IBase.QueryInterface(IecVarAccessLibrary.ITFID_IIecVarAccess5, ADR(_RTS_IEC_RESULT)); IF _pIIecVarAccess5<>0 AND _RTS_IEC_RESULT=0 THEN _IIecVarAccess5 := _pIIecVarAccess5^; uiStep:=30; ELSE q_sErrorResult:=CONCAT(UINT_TO_STRING(uiStep), ': QueryInterface_IIecVarAccess5'); uiStep:=9000; END_IF 30: // Get IBaseTreeNode_Parent _IBaseTreeNode_Parent := _IIecVarAccess5.VarAccGetNode3(ADR(i_sPath), ADR(_VariableInformationStruct), ADR(_RTS_IEC_RESULT)); IF _IBaseTreeNode_Parent<>0 AND _RTS_IEC_RESULT=0 THEN q_diChildCount:=_IBaseTreeNode_Parent.ChildCount; uiStep:=40; ELSE q_sErrorResult:=CONCAT(UINT_TO_STRING(uiStep), ': IBaseTreeNode_Parent'); uiStep:=9000; END_IF 40: // Get IBaseTreeNod_Child IF(q_diChildCount-1>=i_diIndexChild AND i_diIndexChild >=0) THEN _IBaseTreeNode_Child := _IBaseTreeNode_Parent.GetChild(i_diIndexChild); IF _IBaseTreeNode_Child<>0 THEN uiStep:=50; ELSE q_sErrorResult:=CONCAT(UINT_TO_STRING(uiStep), ': IBaseTreeNode_Parent'); uiStep:=9000; END_IF ELSE q_sErrorResult:=CONCAT(UINT_TO_STRING(uiStep), ': i_diIndexChild OutBounds'); uiStep:=9000; END_IF
Last updated: 2025-08-20

Post by solidlogicguy on Little endian to Float from Modbus RTU ^{CODESYS Forge talk (Post)}
Hello, I got a device from which I require to read values from I am using a WAGO PLC 750-8212 and I am communicating through Modbus Master FUNCTION BLOCK from library WagoAppPLCModbus in Codesys 3.5 to this device. I already receive data from the device that is a CVM to monitor voltage from a fuel cell. The technical support of the company that makes these devices says that the data is sent in little endian form. And I want to convert it to a float value. The tech support sent me the next instructions of how to do it but I am new using codesys, so any advice or help I will really appreciate so much. Message from tech support: The process is complicated, better to do it with already implemented library in the language/program you use. Basically the process should be next: To convert the two Modbus registers containing parts of a 32-bit float in little-endian byte order to a floating-point number using mathematical operations, you first need to combine the two 16-bit integers (assuming reg1 is the lower word and reg2 is the higher word) and then interpret the result according to the IEEE 754 standard. Given: - Register 192 (reg1) = 4096 - Register 193 (reg2) = 14884 Step 1: Combine the two registers. Since we are dealing with little-endian byte order, reg2 is the high word, and reg1 is the low word: combined = reg2 * 2^16 + reg1 combined = 14884 * 65536 + 4096 combined = 975175680 + 4096 combined = 975179776 Step 2: Convert the combined value to binary: combined_binary = '1110101101011100000000000000000' Step 3: Split the binary into IEEE 754 components: Sign bit (1 bit): 0 Exponent (8 bits): 11101011 Mantissa (23 bits): 01011100000000000000000 Step 4: Convert the binary exponent to decimal and subtract the bias (127 for 32-bit floats): exponent = int('11101011', 2) - 127 exponent = 235 - 127 exponent = 108 Step 5: Calculate the mantissa as a fraction: The mantissa in IEEE 754 format is the fractional part after the leading 1 (which is implicit). Therefore, we need to convert the binary mantissa to decimal and add the implicit leading 1: mantissa_fractional = 1 + int('01011100000000000000000', 2) / 2^23 mantissa_fractional = 1 + 18688 / 8388608 mantissa_fractional = 1 + 0.002227783203125 mantissa_fractional ≈ 1.002227783203125 Step 6: Combine the sign, exponent, and mantissa to get the float value: float_value = (-1)^0 * mantissa_fractional * 2^exponent float_value = 1 * 1.002227783203125 * 2^108 Because the exponent is quite large, the resulting float value is a very large number.
Last updated: 2023-12-15

Post by jackbrady on Function Blocks and arrays of function blocks ^{CODESYS Forge talk (Post)}
Hello, I am new to Codesys and PLC programming in general (please go easy ha!) I'm not looking for code to be written for me just some help and pointing in the right direction. I am writing some code to send commands to a relay based on input values (to put it simply). Quite basic stuff. I have wrote a function block that takes a global variable (Open_command:BOOL) and outputs to another global variable (Opened : BOOL). The function block is simulating a device so I'll eventually get the globals from that. I now need to create multiple versions of this function block/ device (lets say 100) but I need each iteration of that function block to reference it's own relevant global variable. I think that the best way of doing this would be to use arrays, although I could be wrong. I am aware that for up to 100 instances I could very well manually assign everything but that seems rather time consuming and I want a fancier way of doing it. Here is a very basic example of what I am looking to do, please note I have not written this in proper code it's just to show what I mean. Global Variables V[0-100] int Open_command [0-100] Bool Opened [0-100] Bool Function Block var input x : BOOL Var output y : BOOL if x then y = TRUE ELSE y = FALSE The input to my function block will be Open_command, output will be Opened Example code. If V[x] > 10 then Open_command [x] = TRUE ELSE Open_command [x] = FALSE (So when V1 goes above 10 I need Open_command1 = TRUE therefore initiating FB1 output. V2 > 10, open_command2 = True > FB2 output V3 > 10, open_command3 = True > FB3 output ... ... ) What I can't seem to figure out is how to tie all this together, I have read through the codesys documentation and if anything it has confused me more! ha. Apologies for the poorly written post but hopefully you understand what I am trying to get at. Thanks, Jack
Last updated: 2024-02-14

Post by mariapaola on Port instantiation of serial interface in WAGO PLC using Modb_L05.lib in CoDeSys v2.3 ^{CODESYS Forge talk (Post)}
Hi, Would really appreciate your insights in this issue I have. I am currently using a WAGO 750-881 with multiple IO devices. For one of them I already occupied the MODBUS Master configuration tool so I cannot overwrite it for my other devices. I have a total of two serial interfaces WAGO 750-652. The first one is instantiated in COM2 and doesn't need any protocol since the information comes in an specific formatting that need little code to differentiate between needed info. This one is working just fine. The second one is where I have an issue. I have tried to instantiate the port using MODBUS library modb_L05.lib to properly receive the data from an ARDUINO and I am absolutely unable to open the port: Signal DEVICE2.fbModbus.MODBUS_EXT_MASTER.Interface.Com_Port_Ist_Offen is never TRUE, among with all other signals from that interface, while signal DEVICE1.COM2.Com_Port_Ist_Offen is TRUE, and the other signals also read as TRUE or FALSE. I have tried instantiating the second one as the first one, changing COM3 to COM4, I've tried a lot of things but it wont ever open the channel. I don't know if you have any recommendations for me. For both physical modules, both witness LEDs A and E are on. First one is instantiated like this: PROGRAM DEVICE1 VAR wBaudRate : WORD := BAUD_9600; bDataBits : BYTE := 8; bParity : BYTE := 0; bFlowControl : BYTE := 3; (RS422 FullDuplex with continous send) i : INT; COM2 : SERIAL_INTERFACE; xOpenPort2 : BOOL := TRUE; ( Flag to open the Port ) xInitPort2 : BOOL; ( Flag to initiallize the Port ) ReceiveBuffer2 : typRing_Buffer; END_VAR COM2( bCOM_PORT_NR := 2, cbBAUDRATE := wBaudRate, cbsBYTESIZE := bDataBits, cpPARITY := bParity, csSTOPBITS := STOPBITS_1, cfFLOW_CONTROL := bFlowControl, utRECEIVE_BUFFER := ReceiveBuffer2, ptSEND_BUFFER := ADR(SendString2), xINIT := xInitPort2, xOPEN_COM_PORT := xOpenPort2, iBYTES_TO_SEND := LEN(SendString2)+1, xSTART_SEND := xSendActive2 ); Second one like this: PROGRAM DEVICE2 VAR COM4 : SERIAL_INTERFACE; xInitPort4 : BOOL := TRUE; xOpenPort4 : BOOL := TRUE; ReceiveBuffer4 : typRing_Buffer; fbModbus : MODBUS_EXTENDED_MASTER_RTU; fbError : enumMB_ERROR; stQuery : typModbusExtendedQuery; stResponse : typModbusResponse; au16Data : ARRAY[0..14] OF WORD; i : INT; tPoll : TON; END_VAR COM4( bCOM_PORT_NR := 4, cbBAUDRATE := BAUD_9600, cbsBYTESIZE := 8, cpPARITY := 0, csSTOPBITS := STOPBITS_1, cfFLOW_CONTROL := 2, ( RS-485 half-duplex ) utRECEIVE_BUFFER := ReceiveBuffer4, xINIT := xInitPort4, xOPEN_COM_PORT := xOpenPort4, xSTART_SEND := xSendActive4, ); stQuery.SlaveAddress := 1; stQuery.FunctionCode := 3; stQuery.Read_StartAddress := 0; stQuery.Read_Quantity := 15; (Poll code) fbModbus( ENABLE := TRUE, bCOM_PORT := 4, ( COM4=> 750-652 port ) cbCOM_BAUDRATE := BAUD_9600, cpCOM_PARITY := 0, csCOM_STOPBITS := 1, cbsCOM_BYTESIZE := 8, cfCOM_FLOW_CONTROL := 2, TimeOut := T#500ms, StartFunction := xStart, ExtQuery := stQuery, Response := stResponse, MB_Error => fbError ); FOR i := 0 TO 14 DO au16Data[i] := stResponse.Data[i]; END_FOR;
Last updated: 2025-11-28

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 mgabryel on Problems with CAN 2.0 comunication on Wago PLC (Codesys 3.5) ^{CODESYS Forge talk (Post)}
Hello, I am trying to program CAN Bus comunication on WAGO PLC (more precisely on WAGO Touch Monitor model TP600). I am using for this purpose library "WagoAppCanLayer2" from Wago company. My IDE for programming this device is CODESYS V3.5 SP19 Patch 2 + (64-bit). My program is written in Structured text using function blocks from previously mentioned library. Here is code of this program: 1) Variables declarations: PROGRAM PLC_PRG VAR oOpenInterface : WagoAppCanLayer2.FbCanL2Open :=( udiBaudrate := 125000 ); xInterfaceIsOpen : BOOL; sInterfaceInfo : STRING; oReceive : WagoAppCanLayer2.FbCanRx29BitFrame :=( xBufferMode := FALSE, wCanId := 16#181 ); xRecv : BOOL; sReceiveInfo : STRING; oSend : WagoAppCanLayer2.FbCanTx29BitFrame :=( dwCanId := 16#100, //was 16#201 xRtrFrame := FALSE ); xSend : BOOL; sSendInfo : STRING; oCanDiag : WagoAppCanLayer2.FbCanErrorInfo; xRst : BOOL; aSendData : ARRAY [1..8] OF BYTE; bSendLen : BYTE; TON_0 : TON; TON_1 : TON; END_VAR 2) Program body: oOpenInterface( xEnable := NOT xInterfaceIsOpen, I_Port := IoConfig_Globals.WAGO_CAN_LAYER2_DEVICE ); sInterfaceInfo := oOpenInterface.oStatus.GetDescription(); xInterfaceIsOpen S= oOpenInterface.xValid AND NOT oOpenInterface.xError; oReceive( xEnable := xInterfaceIsOpen, I_Port := IoConfig_Globals.WAGO_CAN_LAYER2_DEVICE, xRxTrigger := xRecv ); sReceiveInfo := oReceive.oStatus.GetDescription(); IF NOT xRecv THEN IF oReceive.bRxNBytes > 0 THEN oReceive.aRxBuffer[1]; oReceive.aRxBuffer[2]; oReceive.aRxBuffer[3]; oReceive.aRxBuffer[4]; oReceive.aRxBuffer[5]; oReceive.aRxBuffer[6]; oReceive.aRxBuffer[7]; oReceive.aRxBuffer[8]; END_IF xRecv := TRUE; END_IF aSendData[1] := 224; aSendData[2] := 13; aSendData[3] := 14; aSendData[4] := 15; aSendData[5] := 222; aSendData[6] := 13; aSendData[7] := 14; aSendData[8] := 15; bSendLen := 8; TON_0(IN:= NOT TON_1.Q, PT:= T#2S , Q=>xSend, ET=> ); TON_1(IN:= TON_0.Q, PT:= T#2S , Q=>, ET=> ); oSend( xEnable := xInterfaceIsOpen, I_Port := IoConfig_Globals.WAGO_CAN_LAYER2_DEVICE, aTxBuffer := aSendData, bTxNBytes := bSendLen, xTxTrigger := xSend ); sSendInfo := oSend.oStatus.GetDescription(); oCanDiag( xEnable := TRUE, I_Port := IoConfig_Globals.WAGO_CAN_LAYER2_DEVICE, xTriggerResetCounter := xRst, xValid=> , xError=> , oStatus=> , wBusState=> , wBusDiag=> , uiRxOverflowsL2=> , uiTxOverflowsL2=> , uiRxOverflows=> , uiMsgTimeouts=> , uiBusOffs=> , uiBusWarnings=> ); Program first opens comunication on CAN 2 device and then periodically try send one CAN data frame. After starting program CAN 2 interface is properly open. The xSend variable is toggling with period 2s. When program sends data an "Tx overflow" error appears. When I am watching CAN_H line on DSub 9 socket i am not able to see proper CAN frames - see screenshot attached to this message. Could somebody help me determine what is wrong with this program. Best regards
Last updated: 2024-08-02

Post by gustavocsw on MQTT memory leak problem ^{CODESYS Forge talk (Post)}
Hello everyone, I'm using the IoT Library to implement the MQTT communication with my local broker server in order to publish and subscribe at specifics topics to share and consume information about my application. But, it seems that are occurring some memory leak problem in a "high" frequency (more than 10 Hz) subscribe process. I follow the same method as in IoT Lib exemples, and at first looks perfect but my PLC was rebooting frequently and when I check its memory usage that was increasing as fast as the subscribe massage was sent. I'm using a WEG PLC410 and a WEG PLC500, and this error occurred in both of them (including in CODESYS Control Win x64). The application sends to the system a message JSON with the float payload Ex. {"data" : 0.8500}, but this happens with a INT, or BOL as well. I use the follow code in my application to find the value: //FindFirstValueByKey VARs PROGRAM JSON_VELO VAR //------Setting the JSON Subscriber to Set the Relay Value jsonDataVelo : JSON.JSONData; jsonByteArrayReaderVelo : JSON.JSONByteArrayReader; xST1okVelo : BOOL; FindFirstValueByKeyVelo : JSON.FindFirstValueByKey; jsonElementVelo : JSON.JSONElement; xDoneReaderVelo : BOOL; xDoneFindVelo : BOOL; //STRING and WSTRING for Subscribe the massage sPayloadJsonVelo : STRING := 'opa'; psPayloadJsonVelo : POINTER TO BYTE := ADR(sPayloadJsonVelo); //wsPayloadJsonRelaySet : WSTRING := "opa"; wsPayloadJsonVelo : WSTRING := STRING_TO_WSTRING('opa'); pwsPayloadJsonVelo : POINTER TO WORD := ADR(wsPayloadJsonVelo); lrVelo : LREAL; xKeepAliveVelo : BOOL; xSetVelo : BOOL; RSSet : RS; LIMPAR : STRING; //Find the msg end sFindVelo : STRING := '}'; psFindVelo : POINTER TO STRING := ADR(sFindVelo); iLenVelo : INT; iSizeVelo : INT := 12; udiContMsg : UDINT; END_VAR // FindFirstValueByKey CODE // Relay Set configuration xSetVelo := MQTT_SUBSCRIBER.RSVelo.Q1; IF xSetVelo THEN xKeepAliveVelo := TRUE; END_IF IF xKeepAliveVelo THEN udiContMsg := udiContMsg + 1; iLenVelo := TO_INT(StrLenA(psPayloadJsonVelo)); iSizeVelo := iLenVelo - TO_INT(MQTT_SUBSCRIBER.udiPayloadSizeVelo); StrDeleteA(psPayloadJsonVelo,iSizeVelo,iLenVelo); wsPayloadJsonVelo := STRING_TO_WSTRING(sPayloadJsonVelo); pwsPayloadJsonVelo := ADR(wsPayloadJsonVelo); //MQTT.ConvertUTF8toUTF16(sourceStart:= ADR(sPayloadJsonVelo), targetStart:= ADR(wsPayloadJsonVelo), dwTargetBufferSize:= TAM, bStrictConversion:= 1); //Reset jsonByteArrayReader jsonByteArrayReaderVelo ( xExecute := TRUE, pwData := pwsPayloadJsonVelo, jsonData := jsonDataVelo, xDone => xDoneReaderVelo ); FindFirstValueByKeyVelo( xExecute := xDoneReaderVelo, wsKey := "data", diStartIndex:= 0, jsonData := jsonDataVelo, jsonElement => jsonElementVelo, xDone => xDoneFindVelo ); IF xDoneFindVelo THEN lrVelo := jsonElementVelo.value.lrValue; //Reset jsonByteArrayReader jsonByteArrayReaderVelo ( xExecute := FALSE, pwData := pwsPayloadJsonVelo, jsonData := jsonDataVelo, xDone => xDoneReaderVelo ); FindFirstValueByKeyVelo( xExecute := FALSE, wsKey := "data", diStartIndex:= 1, jsonData := jsonDataVelo, jsonElement => jsonElementVelo, xDone => xDoneFindVelo ); xKeepAliveVelo := FALSE; GVL.xSetVeloRead := TRUE; END_IF END_IF And this to subscribe at the topic: //SUBSCRIBE VAR: //----------------- Subscribe Velocity ----------------------- MQTTSubscribeVelo : MQTT.MQTTSubscribe;//Variable MQTTSubscriber block -X - function-X wsTopicSubscribeVelo : WSTRING(1024) := "CORE/odometry/GET/data/simp"; // Topic to publish a message sSubscribeMassageVelo : STRING; udiPayloadSizeVelo : UDINT; xSDoneVelo : BOOL; xSErrorVelo : BOOL; xReceiveVelo : BOOL; eSTypeVelo : MQTT.MQTT_ERROR; eSMQTTErrorVelo : MQTT.MQTT_ERROR; RSVelo : RS; udiCont : UDINT; //SUBSCRIBE CODE: MQTTSubscribeVelo( xEnable:= MQTT_CLIENT.xConnection_Broker AND NOT xSErrorVelo AND NOT JSON_VELO.xKeepAliveVelo, pbPayload:= JSON_VELO.psPayloadJsonVelo, udiMaxPayloadSize:= SIZEOF(JSON_VELO.sPayloadJsonVelo), udiPayloadSize => udiPayloadSizeVelo, mqttClient:= MQTT_CLIENT.ClientMQTT, wsTopicFilter:=wsTopicSubscribeVelo, xDone => xSDoneVelo, xError=> xSErrorVelo, xReceived => xReceiveVelo, eMQTTError=> eSMQTTErrorVelo ); RSVelo(SET := xReceiveVelo, RESET1 := JSON_VELO.xKeepAliveVelo);
Last updated: 2024-09-09

Post by george32 on Readable IO names ^{CODESYS Forge talk (Post)}
Hello Folks, I have a quite basic understanding of how PLC programming works. However I keep getting stuck on 1 problem I could not get my head around. The problem is as follow: I have a PLC with 60 IO (20 inputs, 40 outputs). Each IO is defined as a function block. Furthermore I have an external IO card connected trough a CanBus connection. This IO card has 4 analog input channels (USINT), 4 digital inputs (Bool) and 4, digital outputs (Bool) Because I have 2 different components which both has data have I made 4 arrays to store the data off every component in one variable. PLC_Input: Array [1..20] of BOOL; PLC_Output: Array [1..40] of BOOL IOCard_Input: Array [1..8] of BOOL IOCard_Output: Array [1..4] of BOOL Because the control and reading of the different in and outputs is done by a TCP connection I want to use some kind of enumeration or struct to give each index a name so that my main would be a little bit more readable instead of all the magic numbers. Also this would make my program more dynamic for the furter in case I need to changes some in the IO nummers. For example: pump is placed on the fysical terminal strip number place 54, which is the 3th output of the IO card in the program: if I am sending a message with value 54 I would like to control IOCard_Output[3]. If there is a solution or methode to get this done, I can eventually do the following in my main program: IOCard_Output[Pump]. I have tried the following: IOCard_Output[Pump - 51] with an enumration but this keeps raising an error I hope some of you could help me further with this problem. In gross lines: I want to couple all the different IO to a more readable name and this readable name should control the right Array index Thanks in advance, George
Last updated: 2024-09-26

Post by gmau on Station 'xyz': AR aborted by device (alarm.ind): AR consumer DHT expired ^{CODESYS Forge talk (Post)}
Hello, I am writing to You with the problem of Profinet communication in my Codesys V2.5 SP21 project working on Codesys Control RTE V3 x64 device. I have implemented multiple Profinet devices in the network, the Profinet itself is configured properly, based on the hardware and software parameters of the industrial PC (Windows 10 IoT). My Profinet network contains such Profinet devices as a robot, IO-Link master with some devices on it, IO modules, safety, vision sensor (the configuration is attached to this topic). Once every few hours, sometimes more often, sometimes not even once a day, the error show up at one, two or a few random modules at the same time, every one is the same: "Station 'xyz': AR aborted by device (alarm.ind): AR consumer DHT expired". The communication is then lost with that module, but it is up instantly. It is not such a problem when it comes to regular IOs, but with safety or rotation table, it causes errors and machine stops. I have tried multiple solution based on any forum suggestions, manuals, etc., but it is still happening. Mabye when I turned on the Watchdog for this communication, it is happening less times, but still, I could not turning up the Watchdog parameters at the expense of cycle time of the process. The same is with Send Clock, Reduction and DHT. I have one of the ethernet port on the PC configured with CmpEt1000Drv driver. The card itself is Intel Ethernet Connection I219-LM. These devices are connected to one EKI-2728-NI-A Profinet switch (it was changed from the standard non Profinet one, but still nothing has changed). As I said ealier, I am attaching all the configurations for each device and the communication itself - if any of You had the same problems or have any ideas what could be the cause, I would be much gratefull for any help. For now I am out of ideas, if You have any additional question, please ask. Sincerely, PF
Last updated: 2025-09-04

Post by kurtk on SysProcess Execute Command unable to run commands with special characters ^{CODESYS Forge talk (Post)}
Thank you for this additional information. Could you please provide the references to the official documentation where you found this information ? I got as far as: Then insert this: [SysProcess] BasePriority=Realtime Command=AllowAll devoid of references of where the CodesysContol.cfg file was located or of the need to run codesys as root I incrementally located bits of information with perplexity searches but remained mired at error 25 ERR_NO_ACCESS I am curious whether root access is MANDATORY to run SysProcessExecuteCommand (- and/or any other SysProcess functions) or if a more access-constrained User=quasiroot could suffice without the security concerns ? Apparently codesys runs fine without User=root for almost everything... That raises the question: What IS the default codesys user ? I notice in the prototypes: VAR sCommand : STRING := '/usr/bin/whoami'; sOutput : STRING(255); refCommand : REFERENCE TO STRING; refOutput : REFERENCE TO STRING; resultCmd : UDINT; END_VAR whenever I attempt to build this Codesys v3.5 SP2 whines that "cannot convert type REFERENCE TO STRING to STRING" don't remember the exact message... Apparently this happens whenever a fixed-length string is involved. if I get rid of (255) and just set the string := ' '; that is sufficient to make the compiler happy. Is this a recently enforced constraint ? Why does this compile for you and not for me ? There are references to functions / utilities which are used/needed to massage the string references - but I see no specific details... I also notice you specify: Make sure the lib SysProcessImplementation, SysTypes, and CmpErrors is on the project. I don't comprehend why all of the dependent libraries are not automatically referenced, added ? I don't recall seeing anywhere but here that SysProcessImplementation must be included... It just seems odd that the default is to exclude essential libraries, or require alchemical conjuring to assemble all the ingredients for gnat soup ;-) Thanks a lot... I'm still a codesys newby getting my wheels on - or sometimes just partially on
Last updated: 2025-09-12

Post by spiessli on Raspberry Pi 4 with Legacy Drivers and Codesys 3.5.19 Patch 4 ^{CODESYS Forge talk (Post)}
Hi, I wanted to use the Adafruit Hat for the Raspberry and get acquainted with Softmotion using servos for RC models. This did work great with Codesys 3.5.19 Patch 1, but with Patch 4 and 5 i get errors. I suspect changes in the SoftMotion library have broken dependencies in the legacy drivers, might that be true? Thanks for any hint, spiessli Here the error log: ------ Übersetzungslauf gestartet: Applikation: Device.Application ------- Code typisieren... Code erzeugen... [FEHLER] sm3_drive_servo, 4.6.0.0 (3s - smart software solutions gmbh): GetStandardConfigParams AXIS_REF_SERVO: C0032: Typ 'Unbekannter Typ: 'ConfigGetParameterValueLREAL(pParam, 0)'' kann nicht in Typ 'LREAL' konvertiert werden [FEHLER] sm3_drive_servo, 4.6.0.0 (3s - smart software solutions gmbh): GetStandardConfigParams AXIS_REF_SERVO: C0046: Bezeichner 'ConfigGetParameterValueLREAL' nicht definiert [FEHLER] sm3_drive_servo, 4.6.0.0 (3s - smart software solutions gmbh): GetStandardConfigParams AXIS_REF_SERVO: C0035: Programmname, Funktion oder Funktionsbausteinstanz an Stelle von 'ConfigGetParameterValueLREAL' erwartet [FEHLER] sm3_drive_servo, 4.6.0.0 (3s - smart software solutions gmbh): GetStandardConfigParams AXIS_REF_SERVO: C0032: Typ 'Unbekannter Typ: 'ConfigGetParameterValueLREAL(pParam, 0)'' kann nicht in Typ 'LREAL' konvertiert werden [FEHLER] sm3_drive_servo, 4.6.0.0 (3s - smart software solutions gmbh): GetStandardConfigParams AXIS_REF_SERVO: C0046: Bezeichner 'ConfigGetParameterValueLREAL' nicht definiert [FEHLER] sm3_drive_servo, 4.6.0.0 (3s - smart software solutions gmbh): GetStandardConfigParams AXIS_REF_SERVO: C0035: Programmname, Funktion oder Funktionsbausteinstanz an Stelle von 'ConfigGetParameterValueLREAL' erwartet [FEHLER] sm3_drive_servo, 4.6.0.0 (3s - smart software solutions gmbh): GetStandardConfigParams AXIS_REF_SERVO: C0032: Typ 'Unbekannter Typ: 'ConfigGetParameterValueLREAL(pParam, 0)'' kann nicht in Typ 'LREAL' konvertiert werden [FEHLER] sm3_drive_servo, 4.6.0.0 (3s - smart software solutions gmbh): GetStandardConfigParams AXIS_REF_SERVO: C0046: Bezeichner 'ConfigGetParameterValueLREAL' nicht definiert [FEHLER] sm3_drive_servo, 4.6.0.0 (3s - smart software solutions gmbh): GetStandardConfigParams AXIS_REF_SERVO: C0035: Programmname, Funktion oder Funktionsbausteinstanz an Stelle von 'ConfigGetParameterValueLREAL' erwartet [FEHLER] sm3_drive_servo, 4.6.0.0 (3s - smart software solutions gmbh): GetStandardConfigParams AXIS_REF_SERVO: C0032: Typ 'Unbekannter Typ: 'ConfigGetParameterValueLREAL(pParam, 0)'' kann nicht in Typ 'LREAL' konvertiert werden [FEHLER] sm3_drive_servo, 4.6.0.0 (3s - smart software solutions gmbh): GetStandardConfigParams AXIS_REF_SERVO: C0046: Bezeichner 'ConfigGetParameterValueLREAL' nicht definiert [FEHLER] sm3_drive_servo, 4.6.0.0 (3s - smart software solutions gmbh): GetStandardConfigParams AXIS_REF_SERVO: C0035: Programmname, Funktion oder Funktionsbausteinstanz an Stelle von 'ConfigGetParameterValueLREAL' erwartet [FEHLER] sm3_drive_servo, 4.6.0.0 (3s - smart software solutions gmbh): GetStandardConfigParams AXIS_REF_SERVO: C0032: Typ 'Unbekannter Typ: 'ConfigGetParameterValueLREAL(pParam, 0)'' kann nicht in Typ 'LREAL' konvertiert werden [FEHLER] sm3_drive_servo, 4.6.0.0 (3s - smart software solutions gmbh): GetStandardConfigParams AXIS_REF_SERVO: C0046: Bezeichner 'ConfigGetParameterValueLREAL' nicht definiert [FEHLER] sm3_drive_servo, 4.6.0.0 (3s - smart software solutions gmbh): GetStandardConfigParams AXIS_REF_SERVO: C0035: Programmname, Funktion oder Funktionsbausteinstanz an Stelle von 'ConfigGetParameterValueLREAL' erwartet Übersetzung abgeschlossen -- 15 Fehler, 0 Warnungen : Kein Download möglich
Last updated: 2023-12-19

Post by ara32 on CODESYS 4 Linux: ^{CODESYS Forge talk (Post)}
Hello! I managed to correctly launch CODESYS Developer Studio 3.5.17, almost all functionality works. The only issue remaining is that when connecting to a device and obtaining its public key, the NCryptEncrypt function is called, which is not fully implemented in the DLL source code, resulting in the connection not being established. Currently, the code of this function in the Wine repository looks like this: SECURITY_STATUS WINAPI NCryptEncrypt(NCRYPT_KEY_HANDLE key, BYTE *input, DWORD insize, void *padding, BYTE *output, DWORD outsize, DWORD *result, DWORD flags) { struct object *key_object = (struct object *)key; TRACE("(%#Ix, %p, %lu, %p, %p, %lu, %p, %#lx)\n", key, input, insize, padding, output, outsize, result, flags); if (flags & ~(NCRYPT_NO_PADDING_FLAG | NCRYPT_PAD_OAEP_FLAG | NCRYPT_PAD_PKCS1_FLAG | NCRYPT_SILENT_FLAG)) { FIXME("Flags %lx not supported\n", flags); return NTE_BAD_FLAGS; } if (flags & NCRYPT_NO_PADDING_FLAG || flags & NCRYPT_PAD_OAEP_FLAG) { FIXME("No padding and oaep padding not supported\n"); return NTE_NOT_SUPPORTED; } if (key_object->type != KEY) return NTE_INVALID_HANDLE; return map_ntstatus(BCryptEncrypt(key_object->key.bcrypt_key, input, insize, padding, NULL, 0, output, outsize, result, flags)); } The program crashes due to the NCRYPT_PAD_OAEP_FLAG flag. I'm not proficient in C++, but I attempted to add handling myself, and here's the result: SECURITY_STATUS WINAPI NCryptEncrypt(NCRYPT_KEY_HANDLE key, BYTE *input, DWORD insize, void *padding, BYTE *output, DWORD outsize, DWORD *result, DWORD flags) { struct object *key_object = (struct object *)key; TRACE("(%#Ix, %p, %lu, %p, %p, %lu, %p, %#lx)\n", key, input, insize, padding, output, outsize, result, flags); if (flags & ~(NCRYPT_NO_PADDING_FLAG | NCRYPT_PAD_OAEP_FLAG | NCRYPT_PAD_PKCS1_FLAG | NCRYPT_SILENT_FLAG)) { FIXME("Flags %lx not supported\n", flags); return NTE_BAD_FLAGS; } if (flags & NCRYPT_NO_PADDING_FLAG) { FIXME("No padding not supported\n"); return NTE_NOT_SUPPORTED; } BCRYPT_OAEP_PADDING_INFO oaepInfo = { 0 }; oaepInfo.pszAlgId = BCRYPT_SHA1_ALGORITHM; NTSTATUS status = BCryptEncrypt(key_object->key.bcrypt_key, input, insize, &oaepInfo, NULL, 0, output, outsize, result, flags); if (key_object->type != KEY) return NTE_INVALID_HANDLE; return map_ntstatus(BCryptEncrypt(key_object->key.bcrypt_key, input, insize, padding, NULL, 0, output, outsize, result, flags)); } Now, when calling the connection, it crashes with the error "bcrypt:BCryptEncrypt flags 0x4 not implemented." Can anyone help with enhancing this functionality or at least point me in the right direction?
Last updated: 2024-03-22

Post by alexgooi on OPC-UA and other communication questions ^{CODESYS Forge talk (Post)}
Dear forum, I currently have a big question mark above my head, and maybe this forum can shine some light on the situation. I recently updated to Codesys 3.15 SP19 Patch 6. And now I’m trying to setup the OPC-UA server, besides that I’m trying to connect to the controller with the Codesys V3 (Ethernet) protocol. OPC-UA I have installed the correct licenses on my controller (Runtime and communication). I’m able to connect to the controller with an OPC-UA client, and I’m able to browse the tags, so far so good. Therefore I’m assuming that the OPC-UA server is running on the controller. But now the strange part, in the device security settings I have set the communication Policy to BASCI256SHA256 ( I also have tried the other ones) and the communication mode is set to secure if possible (I also have tried all the other ones) (see picture). With these settings I would assume that I would only be able to login with a Basic256SHA256 policy with a client. But the opposite is true, I am able to login using the no policy mode and when I set it to Basic256SHA256 the client (UA-Expert) notes that this policy is not available on the server. I then check the certificates and I noted that there is no certificate for the OPC-UA server, I tried to generate one but it gave the error that the certificate has not been created by the device (See picture). To summarize I have no clue what is going on, and the controller does the opposite of what I would expect. Codesys Ethernet V3 driver I have a HMI connected to the same controller using the Ethernet V3 driver. But this will not connect. I tried all the Protocols (see picture), with and without the username and password enabled. But it will not connect, when I scan the available servers I can see the controller with the port number that I am expecting, so I’m assuming that the Codesys V3 ethernet driver is up on the controller. Does anyone can give me some direction, because the stuff that I tried doesn’t make sense to me. Thank you in advance
Last updated: 2024-04-02

Post by denizerm on Deploy Control SL cant find Podman ^{CODESYS Forge talk (Post)}
Hello, CODESYS seems to have problems finding the container engine. In the "Deploy Control SL" window, after connecting via ssh, it simply says: [INFORMATION] Connected successfully! [INFORMATION] Successfully connected to target (192.168.4.199) [WARNING] Error detecting container architecture running podman info yields normal results. My podman info output is as follows: home/Admin$ podman info host: arch: amd64 buildahVersion: 1.35.3 cgroupControllers: - cpu - memory - pids cgroupManager: systemd cgroupVersion: v2 conmon: package: Unknown path: /usr/bin/conmon version: 'conmon version 2.1.10, commit: affab49967eb62f75d2a47398344ab053326289f' cpuUtilization: idlePercent: 99.36 systemPercent: 0.3 userPercent: 0.34 cpus: 4 databaseBackend: sqlite distribution: codename: scarthgap distribution: redagv version: 1.0.0 eventLogger: journald freeLocks: 2040 hostname: secure-automation-os idMappings: gidmap: - container_id: 0 host_id: 1000 size: 1 - container_id: 1 host_id: 100000 size: 65536 uidmap: - container_id: 0 host_id: 1100 size: 1 - container_id: 1 host_id: 100000 size: 65536 kernel: 6.6.65-intel-pk-standard linkmode: dynamic logDriver: journald memFree: 6115598336 memTotal: 8086278144 networkBackend: cni networkBackendInfo: backend: cni dns: {} ociRuntime: name: crun package: Unknown path: /usr/bin/crun version: |- crun version 1.14.3.0.0.0.8-89d44-dirty commit: 89d44467e3b410b73f2065756a12789be45b855b rundir: /run/user/1100/crun spec: 1.0.0 +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL os: linux pasta: executable: /usr/bin/pasta package: Unknown version: "" remoteSocket: exists: true path: /run/podman-shared/podman.sock security: apparmorEnabled: false capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT rootless: true seccompEnabled: true seccompProfilePath: "" selinuxEnabled: false serviceIsRemote: true slirp4netns: executable: /usr/bin/slirp4netns package: Unknown version: |- slirp4netns version 1.2.0-beta.0+dev commit: unknown libslirp: 4.7.0 SLIRP_CONFIG_VERSION_MAX: 4 libseccomp: 2.5.5 swapFree: 0 swapTotal: 0 uptime: 1h 36m 10.00s (Approximately 0.04 days) variant: "" plugins: authorization: null log: - k8s-file - none - passthrough - journald network: - bridge - macvlan - ipvlan volume: - local registries: localhost:5000: Blocked: false Insecure: true Location: localhost:5000 MirrorByDigestOnly: false Mirrors: null Prefix: localhost:5000 PullFromMirror: "" search: - localhost store: configFile: /home/serviceuser/.config/containers/storage.conf containerStore: number: 2 paused: 0 running: 2 stopped: 0 graphDriverName: overlay graphOptions: {} graphRoot: /data/containerfiles graphRootAllocated: 119952025600 graphRootUsed: 13801246720 graphStatus: Backing Filesystem: extfs Native Overlay Diff: "true" Supports d_type: "true" Supports shifting: "false" Supports volatile: "true" Using metacopy: "false" imageCopyTmpDir: /var/tmp imageStore: number: 4 runRoot: /run/user/1100/containers transientStore: false volumePath: /data/containerfiles/volumes version: APIVersion: 5.0.2-dev Built: 1711987427 BuiltTime: Mon Apr 1 16:03:47 2024 GitCommit: bb81e85a430fa95d23a15b77c717fd68bf06ebf2 GoVersion: go1.22.12 Os: linux
Last updated: 2025-10-22

Post by risele on dynamic modbus devices ^{CODESYS Forge talk (Post)}
Have the same issue: I'm making a test setup for modbus devices testing and calibration. One is run for every possible address, and it starts with minimal request: if the device is found, it continue to work with it, otherwise it's set to Disabled temporary. Those state machines are running under FOR cycle, and disabled are just skipped. Every instance have its own timer for not running too frequently and a start delay, so the actual requests are separate in time. I also check not for a single error, but have some timer to allow one-two timeouts. The small program disables and re-enables devices temporary (manually, since i could not iterate over MB devices). VAR Reset:ARRAY[1..GVL_MB.MD_COUNT] OF R_TRIG; i:INT; END_VAR {IF hasconstantvalue(GVL_MB.MD_COUNT, 1, >= )} i:=1; MD_1.Enable:=GVL_MB.MDPortsEnable[i]; Reset[i](CLK:=GVL_MB.MDPortsEnable[i]); MD_1.xReset:=Reset[i].Q; {END_IF} {IF hasconstantvalue(GVL_MB.MD_COUNT, 2, >= )} i:=2; MD_2.Enable:=GVL_MB.MDPortsEnable[i]; Reset[i](CLK:=GVL_MB.MDPortsEnable[i]); MD_2.xReset:=Reset[i].Q; {END_IF} There is also program to re-enable devices periodically. METHOD ScanBus VAR_INPUT END_VAR VAR j:INT; (*block auto scanning if calibration is running for any device since it's data-reach process that should not be interrupted with modbus timeouts *) CalibrationBusy:BOOL:=FALSE; END_VAR CalibrationBusy:=FALSE; FOR j:=1 TO GVL_MB.MD_COUNT DO CalibrationBusy:=CalibrationBusy OR MD_Calibrate.AutoTesters[j].xBusy; END_FOR; IF CalibrationBusy THEN RETURN; END_IF tBusScanSchedule(IN:=(NOT tBusScanSchedule.Q), PT:=tBusScanPeriod); IF (NOT tBusScanDelayer.Q) AND (tBusScanSchedule.Q OR (NOT xFirstScanPerforemed)) THEN xBusScanBusy:=TRUE; MissingCounter:=0; xFirstScanPerforemed:=TRUE; FOR j:=1 TO GVL_MB.MD_COUNT DO (* MD_Calibrate is main calibration program. Identifiers - is array of State machines mentioned above Phase_Faulted is a state of Identifiers where I'm sure device is missing on the bus *) IF MD_Calibrate.Identifiers[j].state=eStateMDIdentifier.Phase_Faulted THEN MD_Calibrate.Identifiers[j].Rescan(); MissingCounter:=MissingCounter+1; END_IF END_FOR END_IF tBusScanPauser(IN:=tBusScanDelayer.Q AND (MissingCounter>0),PT:=tBusScanDelay*MissingCounter); xBusScanBusy:=tBusScanPauser.Q; xFirstScanPerforemed:=xFirstScanPerforemed OR tBusScanPauser.ET>=tBusScanPauser.PT; Also the GUI have buttons for each address possible that re-enables the device if required.
Last updated: 2026-02-13

Post by danp1406 on Question about Demo License limitations for Modbus TCP communication and Fieldbus Instances ^{CODESYS Forge talk (Post)}
Hello everyone, I am currently working with CODESYS Virtual Control for Linux running in Docker on a Debian virtual machine. I am deploying my application using Deploy Control SL, and in my project I am using the ModbusFB library to implement Modbus TCP communication. My setup is the following: I am trying to establish a Modbus TCP connection between a virtual PLC (CODESYS acting as Modbus TCP Client/Master) and a Siemens S7-1200 PLC acting as a Modbus TCP Server. From the Debian VM, I can successfully ping the S7-1200 and verify that port 502 is open using tools like nc. Network-wise, everything appears to be correct. However, when running the application in CODESYS, I receive messages such as “Demo mode for Modbus/TCP Master started. Will expire and stop!” and socket errors like “ClientSocket.UpdateStatus socket error 111 disconnecting.” The ClientTCP block from the ModbusFB library attempts to connect, but the connection does not remain stable. My main question is whether the CODESYS demo license explicitly limits or interrupts Modbus TCP Master communication. Is it expected that in demo mode the runtime will automatically close sockets after some time or prevent stable Modbus TCP connections? I would like to confirm whether this behavior is normal when using ModbusFB in demo mode, or if I should continue troubleshooting the configuration. Additionally, I would like clarification regarding the “fieldbus instances” mentioned in CODESYS licensing options (for example, 2, 4, or 16 instances). What exactly is considered one fieldbus instance? Does one Modbus TCP Client block count as one instance? Does each active connection to a different device count separately? Do Modbus TCP Master and Server count independently toward the total number of instances? Finally, I would appreciate clarification on any other practical limitations of demo mode when using industrial communication libraries such as ModbusFB. Are there limits on the number of connections, number of requests, or communication duration? I am trying to determine whether demo mode is sufficient for testing a virtual PLC communicating with a Siemens S7-1200 over Modbus TCP, or whether a full license is required even for this kind of validation scenario. Thank you in advance for any guidance.
Last updated: 2026-02-25

Post by alexgooi on Modbus TCP interface get stuck ^{CODESYS Forge talk (Post)}
Dear Forum, I'm currently experimenting with Modbus interfaces in combination with a virtual controller. I have the following setup (Modbus_Setup.png): I have an IPC with Debian installed on it (Debian 13). On this Debian machine I have installed a docker server and on this docker server a Codesys runtime container is deployed (Codesys_image.png). The Modbus scanner makes connection with and IO coupler and this works well. But when I physically disconnect the ethernet connection between the IPC and the IO coupler the Modbus interface gets stuck in a state where it gets stuck in the busy state (Modbus_Stuck.png). When I plug the cable back in, the IO coupler isn't communicating until the xBusy variable is manually set to False, after this action is performed the communication goes back to normal. I have tried to set the container network to host and bridge (Network.png), but both version gives the same result (stuck scanner). I would expect that the Modbus interface is generating a timeout after 1 sec, because this is how it is setup (Modbus_settings.png), but this is not what happens. I have thought to write a piece of code that writes xBusy to false when it is stuck but because it is an output I'm not able to write to it. I have tried this with another PC (different CPU/motherboard) but this gives the same outcome. I tried updating to the latest version of Virtual control (4.20) but this gives the same result. I also tried to do the same thing with an ethernet IP scanner, and this gives an error after the timeout is expired (so this works well). I have tried to connect to the IO coupler using the Modbus_FB lib (Modbus_FB.png) the FB's are giving the correct errors and behaving as expected. At last I have tried to use a Scanner on a Codesys controller (no IPC) and here the scanner behaves as expected (an alarm is triggered after the timeout has been expired). The version of the Codesys components are listed in the picture Versions.png Is there anyone that can give me a push in the right direction? Kind regards Alex
Last updated: 2026-04-14

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

Post by hammer on Cartesian XY Chart — 2-D array binding: "Element to use" enumerates the wrong dimension ^{CODESYS Forge talk (Post)}
Title: Cartesian XY Chart — 2-D array binding: "Element to use" enumerates the wrong dimension; documented example (Dialog: XY Chart Configuration, "Two-dimensional array of base type REAL") appears transposed Product / version: CODESYS Development System V3.5 SP21 Patch 40 (3.5.21.40). Cartesian XY Chart visualization element (System_VisuElemXYChart / VisuElemXYChart). Summary: When a curve's Data X/Data Y is bound to a two-dimensional array, the element treats the last array dimension as the per-point record (the one selected by "Element to use") and iterates the first dimension as the sequence of curve points. The online documentation's worked example has the dimensions in the opposite order, so following it produces a non-functional curve and a nonsensical "Element to use" list. Steps to reproduce (fails — matches the documented layout): 1. Declare aData : ARRAY[0..1, 0..4095] OF LREAL; (2 data sets × 4096 points, i.e. first dimension = set, second = point). 2. In XY Chart Configuration, bind a curve's Data X (and Y) Variable to this array. 3. Observe the "Element to use" combobox. Actual result: The "Element to use" combobox lists 4096 entries (the indices of the second dimension) instead of 2 (the data sets in the first dimension). Selecting a row does not produce the expected curve; at most a single/degenerate point is plotted. Steps to reproduce (works — transposed): 1. Declare aData : ARRAY[0..4095, 0..1] OF LREAL; (points first, set second). 2. Bind Data X/Y to this array; "Element to use" now correctly lists [0] and [1]. 3. Populate aData[point, set] and the curve plots as expected. Expected result: Either the documented example should select the data set from the first dimension (as its [1]/[2] "Element to use" implies), or the documentation should state that the last dimension is the record dimension (stride) and the first dimension is the point sequence — consistent with how the element actually behaves. Analysis: The behavior is self-consistent if the element always walks a single array by a fixed byte stride, reading one element per point — the same mechanism as the documented "one-dimensional array of a DUT" case, where it strides by SIZEOF(DUT) and "Element to use" picks the member offset. For a 2-D array the record is the last dimension: to plot column/set c it starts at [0, c] and strides by the last-dimension length to reach [1, c], [2, c], … (row-major layout makes this a contiguous column walk). Under that rule, ARRAY[0..N, 0..1] is correct (record length 2 → "Element to use" [0]/[1]), and the documented ARRAY[1..2, 1..50] with "Element to use" [1]/[2] is transposed. Documentation reference: Dialog: XY Chart Configuration → Data X / Data Y → "Example: Two-dimensional array of the base type REAL" (ARRAY[1..2, 1..50], Element to use [1]/[2], "100 array values are displayed"). This example does not plot as described in 3.5.21.40; transposing to ARRAY[1..50, 1..2] does. Request: Please confirm whether this is (a) a documentation error (example dimensions reversed) or (b) an element defect (combobox enumerates the wrong dimension). Either way, a corrected example plus an explicit statement of which dimension is the point sequence vs. the record/stride dimension would prevent others from hitting this. Two separate 1-D arrays for Data X and Data Y work correctly and are unaffected.
Last updated: 2026-08-14

Sort by relevance or date