CODESYS Forge - CODESYS Forge / Talk / Search

<< < 1 .. 60 61 62 63 > >> (Page 62 of 63)

Post by anonymous on Hi, I try to send and receive data using a UDP connection via SysSocket 3.5.17.0. While sending data works fine, I have problems with the receiving part. I am able to capture the received data of client side in wireshark But unable to capture it on the codesys ^{CODESYS Forge} ^talk ^(Post)
Hi, I try to send and receive data using a UDP connection via SysSocket 3.5.17.0. While sending data works fine, I have problems with the receiving part.I am able to capture the data of client side in wireshark but i am unable to capture it in the codesys. Heres the below part of code of client side. PROGRAM POU_udpclient_program VAR istep : INT := 1;//step variable for state machine xStart: BOOL;// Flag to start the UDP protocol iecSocketId: syssocket_interfaces.RTS_IEC_HANDLE;//socket handle for receiving iecCreateResult: syssocket_interfaces.RTS_IEC_RESULT; ipAddr: syssocket.SOCKADDRESS;//Socket address structure for receiving sIpAddress : STRING := '192.168.0.2'; wPort: WORD:= 12346; iecConnectResult : syssocket_interfaces.RTS_IEC_RESULT;//connect paramters sDataRec : STRING[255];//Buffer for received data xiRecBytes : __XINT;//number of bytes received iecRecResult : syssocket_interfaces.RTS_IEC_RESULT;//receive data parameters iecCloseResult : syssocket_interfaces.RTS_IEC_RESULT; END_VAR syssocket.SysSockInetAddr(sIpAddress,ADR(ipAddr.sin_addr)); ipAddr.sin_family := syssocket.SOCKET_AF_INET; ipAddr.sin_port := syssocket.SysSockHtons(wPort); CASE istep OF 1: //create socket IF xStart THEN iecSocketId:= syssocket.SysSockCreate(syssocket.SOCKET_AF_INET,syssocket.SOCKET_DGRAM,syssocket.SOCKET_IPPROTO_IP,ADR(iecCreateResult)); IF iecSocketId = syssocket_interfaces.RTS_INVALID_HANDLE THEN xStart := FALSE; istep := 1; ELSE istep := 2; END_IF END_IF 2: //connect to socket server using setoption iecConnectResult := syssocket.SysSockSetOption(iecSocketId,syssocket.SOCKET_SOL,syssocket.SOCKET_SO_REUSEADDR,ADR(ipAddr),SIZEOF(ipAddr)); istep := 3; 3: //receive data xiRecBytes := syssocket.SysSockRecvFrom(iecSocketId,ADR(sDataRec),SIZEOF(sDataRec),0,ADR(ipAddr),SIZEOF(ipAddr),ADR(iecRecResult)); istep := 4; 4: //close socket iecCloseResult:= syssocket.SysSockClose(iecSocketId); xStart := FALSE; istep := 1; END_CASE
Last updated: 2024-06-03

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 clesio on CAA.File.Write – Unexpected characters when writing a CSV file ^{CODESYS Forge} ^talk ^(Post)
Hello everyone, I am trying to create a routine in CODESYS to export a report to a CSV file using the CAA.File library. The file is created successfully, but I am getting some unexpected/unknown characters in the generated CSV. The problem seems to be related to the SIZEOF() function. I am using it for the szSize parameter of File.Write, as recommended in the CODESYS documentation. However, when I use SIZEOF(), the CSV contains extra characters and parts of previous strings. I also tried using LEN(), but in my application the file is created empty, even though the string and the calculated length appear to be correct. Here is the relevant part of my code: PROGRAM Relatorio VAR // Bool b_Executa_fb_Cria_Arquivo : BOOL; b_Executa_fb_Fecha_Arquivo : BOOL; b_Escreve_dados : BOOL; b_Erro_fb_Escreve : BOOL; //STR s_Nome_Arquivo : STRING; s_Palavra : STRING; s_Palavra_Anterior : STRING; s_Data_Atualizada_Formatada : STRING; s_Dia : STRING; s_Mes : STRING; s_Ano : STRING; s_Hora_Atualizada_Formatada : STRING; s_Hora : STRING; s_Minu : STRING; s_Segu : STRING; //INT i_modo_fb_Cria_Arquivo : INT; i_ErroID_fb_Escreve : INT; //UINT i_Tamanho_Palavra : UINT; // Blocos de Funcao fb_Cria_Arquivo : FILE.Open; fb_Fecha_Arquivo : FILE.Close; fb_Escreve : FILE.Write; // DATA E HORA sc_DataTime : SysTimeRtc.RTS_SYSTIMEDATE; // STRUCT = sc uidResultRtcGet : UDINT; //stGetDate : SysTimeRtc.RTS_SYSTIMEDATE; uidResultConvertToDate : UDINT; uidResult : RTS_IEC_RESULT; END_VAR VAR_INPUT //BOOL b_SET_Executa_fb_Cria_Arquivo : BOOL; b_RES_Executa_fb_Cria_Arquivo : BOOL; b_Executa_fb_Escrita : BOOL; // INT i_Linhas_Cabecalho : INT; i_Linhas_Cabecalho_Anterior : INT; END_VAR // Para Testes s_Nome_Arquivo := 'relatorio/Teste1M.CSV'; i_modo_fb_Cria_Arquivo := 0; // TRATAMENTO DE DATOS DATA e HORA uidResultRtcGet := SysTimeRtcGet(uidResult); uidResultConvertToDate := SysTimeRtcConvertUtcToDate(dwTimestampUtc := uidResultRtcGet, pDate := sc_DataTime); // FORMATA DATA EM UMA STRING s_Dia := UINT_TO_STRING(sc_DataTime.wDay); s_Mes := UINT_TO_STRING(sc_DataTime.wMonth); s_Ano := UINT_TO_STRING(sc_DataTime.wYear); s_Data_Atualizada_Formatada := CONCAT(s_Dia, CONCAT('/', CONCAT(s_Mes, CONCAT('/', s_Ano)))); // FORMATA HORA EM UMA STRING s_Hora := UINT_TO_STRING(sc_DataTime.wHour); s_Minu := UINT_TO_STRING(sc_DataTime.wMinute); s_Segu := UINT_TO_STRING(sc_DataTime.wSecond); s_Hora_Atualizada_Formatada := CONCAT(s_Hora, CONCAT(':', CONCAT(s_Minu, CONCAT(':', s_Segu)))); // ABRE e CRIA ARQUIVO IF (b_SET_Executa_fb_Cria_Arquivo OR b_Executa_fb_Cria_Arquivo) AND NOT(b_RES_Executa_fb_Cria_Arquivo) THEN b_Executa_fb_Cria_Arquivo := TRUE; ELSE b_Executa_fb_Cria_Arquivo := FALSE; END_IF fb_Cria_Arquivo( xExecute := b_Executa_fb_Cria_Arquivo, sFileName := s_Nome_Arquivo, eFileMode := i_modo_fb_Cria_Arquivo, xExclusive := FALSE, ); //i_Tamanho_Palavra := SizeOf(s_Palavra); // ESCREVE NO ARQUIVO fb_Escreve( xExecute := b_Executa_fb_Escrita, hFile := fb_Cria_arquivo.hFile, szSize := SIZEOF(s_Palavra), pBuffer := ADR(s_palavra) ); // FECHA ARQUIVO fb_Fecha_Arquivo( xExecute := b_Executa_fb_Fecha_Arquivo, hFile := fb_Cria_arquivo.hFile ); IF Criacao_Edicao_Arquivos.b_Escreve_Cabecalho THEN CASE i_Linhas_Cabecalho OF 1 : s_palavra := 'ESTERILIZADOR'; 2: s_palavra := 'MAQ4; $R$L'; 3: s_palavra := CONCAT(CONCAT('CLIENTE: ',GVL.sReceitaAtual), '$R$L'); 4: s_palavra := CONCAT(CONCAT('NUMERO LOTE: ',DINT_TO_STRING(GVL.Lote)), '$R$L'); 5: s_palavra := CONCAT(CONCAT('OPERADOR: ', DINT_TO_STRING(GVL.Operador)), '$R$L'); 6: s_palavra := CONCAT(CONCAT('DATA: ', s_Data_Atualizada_Formatada), '$R$L'); 7: s_palavra := CONCAT(CONCAT('HORA: ', s_Hora_Atualizada_Formatada), '$R$L'); 8: s_palavra := '$R$L'; 9: s_palavra := 'PARAMETROS AJUSTADOS $R$L'; 10: s_palavra := CONCAT('TEMPO PRE COND.: ', CONCAT(INT_TO_STRING(GVL.rc_T_PreCondicionamento), ' min $R$L')); 11: s_palavra := CONCAT('PULSOS INERTIZACAO 1: ', CONCAT(INT_TO_STRING(GVL.rc_PulsosInertizacao_1), ' PULSOS $R$L')); 12: s_palavra := CONCAT('PULSOS INERTIZACAO 2: ', CONCAT(INT_TO_STRING(GVL.rc_PulsosInertizacao_2), ' PULSOS $R$L')); 13: s_palavra := CONCAT('PULSOS AERACAO: ', CONCAT(INT_TO_STRING(GVL.rc_PulsosAeracao_2), ' PULSOS $R$L')); 14: s_palavra := CONCAT('PRESSAO DE VACUO 1: ', CONCAT(REAL_TO_STRING(GVL.rc_PV1_max), ' bar $R$L')); 15: s_palavra := CONCAT('PRESSAO DE VACUO 2: ', CONCAT(REAL_TO_STRING(GVL.rc_PV2), ' bar $R$L')); 16: s_palavra := CONCAT('PRESSAO INERTIZACAO 1: ', CONCAT(REAL_TO_STRING(GVL.rc_PN1), ' bar $R$L')); 17: s_palavra := CONCAT('PRESSAO INERTIZACAO 2: ', CONCAT(REAL_TO_STRING(GVL.rc_PN2), ' bar $R$L')); 18: s_palavra := CONCAT('PRESSAO AERACAO: ', CONCAT(REAL_TO_STRING(GVL.rc_PAR), ' bar $R$L')); 19: s_palavra := CONCAT('PRESSAO ETO: ', CONCAT(REAL_TO_STRING(GVL.rc_PressaoETO), ' bar $R$L')); 20: s_palavra := CONCAT('PRESSAO Compl.: ', CONCAT(REAL_TO_STRING(GVL.rc_PressaoETO_2), ' bar $R$L')); 21: s_palavra := CONCAT('MASSA ETO: ', CONCAT(REAL_TO_STRING(GVL.rc_QuantidadeETO), ' Kg $R$L')); 22: s_palavra := CONCAT('TEMPO PRE COND. Vacuo/Vapor: ', CONCAT(INT_TO_STRING(GVL.rc_T_Vapor_1), ' min $R$L')); 23: s_palavra := CONCAT('SET-POINT: ', CONCAT(REAL_TO_STRING(GVL.ihm_SPTemperatura), ' °C $R$L')); 24: s_palavra := CONCAT('TEMPO ESTERILIZACAO: ', CONCAT(INT_TO_STRING(GVL.rc_TempoEsterilizacao), ' min $R$L')); 25: s_palavra := CONCAT('TEMPO PARADA: ', CONCAT(INT_TO_STRING(GVL.rc_T_PressaoParada), ' min $R$L')); 26: s_palavra := CONCAT('UMIDADE: ', CONCAT(REAL_TO_STRING(GVL.rc_UmidadeRelativa), ' % $R$L')); 27: s_palavra := '$R$L'; END_CASE END_IF Note: The code I am attaching does not include the execution/sequence management of the function blocks. I have omitted this part to keep the example focused on the CSV writing routine. The function blocks are triggered and managed by a separate state machine. I am not sure what the correct approach is in this case, especially since the official documentation recommends using SIZEOF() for szSize. I will attach my code and a screenshot of the generated CSV showing the issue. Has anyone experienced something similar or could suggest the correct way to write a changing STRING to a CSV file using CAA.File.Write?
Last updated: 2026-09-08

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 alex-at-xana on EThercat Dynamic configuration ^{CODESYS Forge} ^talk ^(Post)
Hi Everyone, For a fast monitoring system I am using Ethercat oversampling and timestamping inputs. As the customers has a lot of different configurations out in the field, we went for a dynamic Ethercat configuration. Already got the whole detection chain working but now I am stuck since two days in debugging the configuration. Here are my quesitons: I extended the dynamic config example for the EL3632 16#0E303052: //EL3632 pSlave^.SetDCSettings(TRUE,TRUE,80,80,TRUE,4000,0,0); pSlave^.AddSyncManager(16#1000,128,16#26,TRUE,3); pSlave^.AddSyncManager(16#1080,128,16#22,TRUE,2); pSlave^.AddSyncManager(16#1100,0,16#4,TRUE,1); pSlave^.AddSyncManager(16#1110,214,16#20,TRUE,0); pSlave^.AddFMMU(0,214,0,7,16#1110,0,1,1); pSlave^.AddFMMU(0,1,0,0,16#80D,0,1,1); xKnown := TRUE; This leads to a PLL Error for these devices. I double and triple checked the configuraton, but cannot find the issue. There seems to be one difference: the config dialog creates a startup parameter: 16#10F3:16#05, Name: Command_0, Value:0. Bitlen: 16, Stop on fault: false, jumpt at fault: false: next line: 0 a) I do not find information on how to set this in my code. Can you help me there? b) Without trying to set the value, I get a PLL error for these devices in the master log. Is the config wrong? c) Do I need to set the Master to Autoconfigure or Manual? I used autoconfigure for my tests. The stack creates input data addresses for the slaves input data range (pSlaves[i].InputData) which are different from those created when I use the Engineering tools dialogs to configure Ethercat. Specifically, the addresses seem to be aligned at 16 byte boundaries when they are created using the engineering tool, but may appear at uneven addresses when I use the script in dynamic config. I did not try to access ULINT at uneven addresses yet, but I am suspecting this may be a problem. Do I need to manually align the addresses ? Any help is appreciated...
Last updated: 2024-09-10

Post by thn-power on Updating OPC UA Core Nodeset on PLS ^{CODESYS Forge} ^talk ^(Post)
Hi After much trail and error I think I found the root cause to my OPC UA problem. The problem is that I cannot manage to build and download a program with a a custom OPC UA Information model. We use a Weidmueller WL2000 PLS, but the problem also exsist on the Win V3 PLC. Our custom information model is based on the latest versions of the OPC UA Core Nodeset v 1.05.03 (2023-09-20) and UA/DI nodeset 1.04.0 (2022-11-03) Those nodesets are installed in the Codesys Information Model Repository (3.5.19.6) However, when trying to build I get the following error. [ERROR] Untitled1: Communication Manager [Device: PLC Logic: Application]: The information model http://opcfoundation.org/UA/ is required by http://bos.org/ with a minimal publication date from 15.12.2023 but the device has only a model from 15.09.2021 installed. Probably the information model from 15.09.2021 is missing in the information model repository. [ERROR] Untitled1: Communication Manager [Device: PLC Logic: Application]: The information model http://opcfoundation.org/UA/DI/ is required by http://bos.org/ with a minimal publication date from 03.11.2022 but the device has only a model from 09.03.2021 installed. Probably the information model from 09.03.2021 is missing in the information model repository. Build complete -- 2 errors, 1 warnings : No download possible I think the problem is that the UA Core nodeset is implemented in the PLC firmware (at least that in Siemens S7), and that only includes the "old" nodeset from 2021-09-21 etc. So the question is, how (or if?) can I transfer the new nodeset to the PLS? I have created separate Information models under Communication manager with the newer code nodesets (UA and DI). But it seems that the compiler does not recognize them being excising, neither in the Codesys IDE or on the PLC. Would have guessed that this is a common issue, sine many manufacturers use the latest versions of the OPC UA standard, and that it would be a solution to the problem.
Last updated: 2024-09-20

Post by mondinmr on Frustration-Fueled Feedback on Project File Management and Git Integration ^{CODESYS Forge} ^talk ^(Post)
Good day, I’m writing this message out of frustration regarding the current way project files are saved as encrypted XML and single-file format in CODESYS. I find this approach to be quite tedious for several reasons: Limited Access to Structured Text: Not being able to access Structured Text (ST) externally makes it impossible to work with alternative editors like VSCode. Tools like VSCode are incredibly responsive and feature advanced systems such as GitHub Copilot, which would be a real game-changer when working with ST IEC. While CODESYS works well for small code snippets or debugging, when the codebase grows, switching to VSCode to boost productivity becomes essential, and copy-pasting between environments is a cumbersome workaround. Poor Integration with Git: This file format also makes it very difficult to integrate effectively with Git. I have tested the internal demo, but for advanced merges, it is unusable. Without properly formatted plain text, it’s impossible to leverage the vast ecosystem of external tools around Git that allow smooth merges in heterogeneous teams. File Corruption on Network Drives: I often work from multiple locations with shared network drives. When the development environment saves a file and something goes wrong midway (which can occasionally happen when using VPNs and network drives), the entire project becomes irrecoverable. There’s no way to cancel the save process, and the development environment freezes. This has happened to me at least four times over the past two weeks, and one of those incidents cost me an entire day of work. All of this is particularly disappointing because I truly believe that the libraries, runtime, and overall work done by CODESYS are exceptional. I find it fantastic that there is a platform allowing development of PLCs and control systems using OOP, which is a huge advantage in modern control engineering. I apologize for the rant, but this issue has been extremely frustrating. Best regards.
Last updated: 2024-10-15

Post by patrik on Wish: CODESYSControl.cfg - again ^{CODESYS Forge} ^talk ^(Post)
Really good post. I hope that it gets seen by CoDeSys staff. I often find the documentation lacking when it comes to using CoDeSys in more complex ways. If using standard "basic PLC functionality", then it's fine and functions are documented in a sufficient way. Once you go outside of that bubble then I find the documentation not enough. CODESYSControl.cfg is a good example of this. And why isn't more of this integrated in the IDE. like changing port of the webserver. Why is it hidden in this file and not accessible through the IDE. It feels like a layer of complexity purposely left in so you don't change it if you don't know what you are doing. Like the argument is if you have the know-how to find the file you have the know-how to edit it. I find the documentation lacking when it comes to more complex libraries too. Like the element collections library. there is parameters I still don't quite know what they do. I can't find any documentation about them. There is an example project to download from CoDeSys so you can see how you are supposed to set your factories up. I leave some parameters like it is in the example. Should I? I don't know. Does it work. Yes. But I could perhaps create memory leaks if I get something wrong and I don't see that until way later. In the create method of your element factory you have a function called __vfinit and you just have to accept that it works. Why can't I get insight in what it does through documentation? Don't CoDeSys want us to know how these work so we can't use them to accidentally break something? I find the error logging lacking too. I've had the CoDeSys service crash but it doesn't say why. I've seen windows noticing the crash but no error code was sent or error message. Also in my current issue where the application fails to start after power outage. I can see in the log that it fails to load retain in the application as one log entry and application failing to start as another. But why? Why does loading the retain fail? give me more information! Is it just a skill issue with me? I don't know. If it is then I'd still want CoDeSys to step up their game when it comes to documentation. I'm sorry if a lot of frustration comes though in this post. I really like the product and what I can do with it compared to other PLC brands.
Last updated: 2024-11-21

Post by clarenced on ERROR: Calling the program "AlarmStorage_Prg" is not allowed from multiple tasks ^{CODESYS Forge} ^talk ^(Post)
Using codesys v3.5 SP21 Patch 1. We are using Visualization to display alarms. Other then the automatically created AlarmManagerTask, there is no code written to call AlarmStorage_Prg. Any ideas why we would be seeing this error in the log? The runtime actually shutdown. Not sure if that was caused by this error or not. 2025-08-03T02:45:35.444Z, 0x00001012, 4, 0, 0, * ERROR: Calling the program "AlarmStorage_Prg" is not allowed from multiple tasks. 2025-08-03T03:48:15.294Z, 0x00001012, 4, 0, 0, * ERROR: Calling the program "AlarmStorage_Prg" is not allowed from multiple tasks. 2025-08-03T04:38:11.557Z, 0x00000103, 65544, 1, 0, runtime received SIGABRT - system may be in an inconsistent state * We recommend a reboot of the controller now! * 2025-08-03T04:38:11.576Z, 0x0000010f, 8, 1, 0, #### Exception: SysSemEnter - Semaphore deadlock detected - owner thread died [tid:726740] - system may be in an inconsistent state. 2025-08-03T04:38:11.576Z, 0x00000103, 65544, 1, 0, runtime received SIGABRT - system may be in an inconsistent state * We recommend a reboot of the controller now! 2025-08-03T04:38:11.576Z, 0x00000001, 8, 260, 3, #### Exception: HANDLED EXCPT* <excpt>NonContinuable</excpt> in CH_COMM_CYCLE 2025-08-03T04:40:12.308Z, 0x00000001, 1, 0, 35, CODESYS Control shutdown... 2025-08-03T04:40:13.436Z, 0x00000071, 1, 0, 13, Webserver stopped 2025-08-03T04:40:13.437Z, 0x00000114, 2, 1, 0, !!!! Warning: task_signalhandler_exit [MainTask] lost cycles: 14809 2025-08-03T04:40:13.497Z, 0x00000001, 1, 0, 10, [UNLOADED] IEC|Dynamic: <cmp>IecVarAccess</cmp>, <id>0x00001007</id> <ver>3.5.3.64</ver> 2025-08-03T04:40:13.506Z, 0x00000001, 1, 0, 10, [UNLOADED] IEC|Dynamic: <cmp>AlarmMgr</cmp>, <id>0x00001012</id> <ver>4.7.0.0</ver> 2025-08-03T04:40:13.513Z, 0x00000071, 2, 0, 14, !!!! Warning: Unbalanced calls to WebServerRequestRunning/WebServerReleaseRunning 2025-08-03T04:40:13.513Z, 0x00000001, 1, 0, 10, [UNLOADED] IEC|Dynamic: <cmp>IECVisualization</cmp>, <id>0x0000100c</id> <ver>4.7.0.0</ver> 2025-08-03T04:40:13.611Z, 0x00000124, 1, 0, 0, Provider 'AddressSpaceFragment Provider' (version 0x3051500) unregisterd at the OPC UA server. 2025-08-03T04:40:13.611Z, 0x00000124, 1, 0, 0, Provider 'OPC UA for IEC-61131-3' (version 0x3051500) unregisterd at the OPC UA server. 2025-08-03T04:50:17.708Z, 0x00000001, 1, 0, 36, CODESYS Control shutdown done
Last updated: 2025-08-04

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 axberry on CODESYS Control for Raspberry Pi 5 - "Hardware version or firmware version not supported" on Rev 1.1, persists across multiple runtime versions and OS images ^{CODESYS Forge} ^talk ^(Post)
Hi, I'm trying to run CODESYS Control for Raspberry Pi SL on a Raspberry Pi 5, and the runtime consistently fails to start with the following error when launched manually: ooops... this runtime was built for RASPBERRYPI. Hardware version or firmware version not supported! (-18, 0x00000BB8, 0xFFFFFFFB) Hardware: Raspberry Pi 5 Model B Rev 1.1 Revision code: d04171 CPU: aarch64, BCM2712 Serial number is correctly exposed via /proc/cpuinfo and /proc/device-tree/serial-number /proc/device-tree/model correctly reports "Raspberry Pi 5 Model B" What I've tried (all resulting in the same error): CODESYS Control for Raspberry Pi SL 4.11.0.0 (SDK 3.5.19.61) — the version that introduced Pi 5 support CODESYS Control for Raspberry Pi SL 4.21.0.0 (SDK 3.5.22.20) — latest available Raspberry Pi OS Bookworm (64-bit) with kernel 6.12.93+rpt-rpi-2712 (June 2026 build) Fresh install on Raspberry Pi OS Bookworm (64-bit) with an older image from November 24, 2025 — same error, ruling out a kernel-version regression Bootloader/EEPROM confirmed up to date (rpi-eeprom-update reports "up to date") Clean purge and reinstall of the codesyscontrol package each time (verified via dpkg -l, no leftover files) Verified /etc/codesyscontrol/3S.dat correctly symlinks to /etc/codesyscontrol/3S_aarch64.dat The service starts (systemctl status briefly shows active (running) with a real PID under /opt/codesys/bin/codesyscontrol.bin), but crashes shortly after and the process disappears — port 11740 never opens. Since this happens identically across two different runtime versions and two different OS images (5+ months apart), it doesn't seem to be a kernel/firmware timing issue. Could this be specific to the Rev 1.1 board revision, or is there a known issue with the hardware detection logic in the SL runtime that I should be aware of? Happy to provide full debug logs (-d flag output) or journalctl output if useful. Thanks in advance!
Last updated: 2026-08-10

Post by baltzer on ICertificateVerifier.VerifyCertificate doesn't appear to override an ERR_CERT_HAS_EXPIRED rejection in TCP_Client.Upgrade() ^{CODESYS Forge} ^talk ^(Post)
Follow-up: working workaround found (routing TLS outside CODESYS) For anyone finding this thread later with the same problem (a third-party device presenting a self-signed and/or expired certificate that ICertificateVerifier/udiVerificationMode won't let you connect through) - we never got a working fix within NBS itself, but found a practical workaround worth sharing. Approach: run a local TLS-terminating proxy on the same host as the CODESYS runtime, and have CODESYS talk plain, unencrypted TCP to it instead of connecting to the remote device directly over TLS: CODESYS --plain TCP--> 127.0.0.1:<port> --stunnel/TLS--> <remote device>:<port> We used stunnel (client mode), with certificate verification explicitly disabled at that layer (verifyChain = no, verifyPeer = no) - a simple, well-documented one-line option, unlike anything we could get working inside NBS. Running it as a systemd service with Restart=always means it survives reboots and recovers automatically if the proxy or the remote device drops. On the CODESYS side, this required no changes beyond pointing TCP_Client at 127.0.0.1 instead of the device's real IP, and removing the TLSContext/ICertificateVerifier code entirely - the rest of our application-layer logic (framing, checksums, etc.) was completely unaffected, since none of that ever depended on where the TLS termination happened. Confirmed working end-to-end against a real device with an expired self-signed certificate, running on CODESYS Control for Raspberry Pi SL (Linux). We haven't yet set this up on Windows - stunnel does have Windows builds available, so the same general approach should be possible there too, but that combination isn't tested or confirmed by us at this point. Caveat: this only makes sense when the proxy and the CODESYS runtime are on the same trusted host (in our case, both on the same Raspberry Pi) - don't expose the proxy's plaintext side on a reachable network interface, since that would create an unauthenticated plaintext path to the device. The original question - whether there's a supported way to override an ERR_CERT_HAS_EXPIRED/self-signed rejection from within NBS's own TLSContext/ICertificateVerifier - remains open as far as we know. Still happy to hear from anyone who's solved that particular piece, since the workaround above is a practical detour rather than an actual answer to the original question.
Last updated: 2026-08-06

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 alexschooneveld on OPC UA PubSub SL 1.3 — UADP WriterGroup with assigned PSS.SecurityGroup still publishes plaintext ^{CODESYS Forge} ^talk ^(Post)
I am currently investigating an OPC UA PubSub connection over UDP. When I don't use encryption, the publish and subscribe are working correctly. But with encryption it does not. Environment OPC UA PubSub SL 1.3.0.0 (namespace UADP) OPC UA PubSub Security 1.3.0.0 (namespace PSS) OPC UA PubSub Base 1.3.0.0 (namespace PSB, incl. PSS.SecurityGroup / PSS.CONFIG) Programmatic PubSub in a CFC: UADP.Configuration → UADP.Connection → UADP.writerGroup → UADP.writer → writerDataSet, plus a CyclicCall gated by xEnable. Goal: publish secured UADP, SignAndEncrypt, policy PubSub-Aes256-CTR. What I do (one-shot, before xEnable := TRUE): fbSecurityGroup.SetInitialValue( 'http://opcfoundation.org/UA/SecurityPolicy#PubSub-Aes256-CTR', PSB.SECURITY.SIGNING_AND_ENCRYPTION); stSecurityCfg := fbSecurityGroup.GetConfig(eErrorID => eError); // eError=NO_ERROR, udiEncryptionKeySize=32 eError := fbSecurityGroup.SetSecurityKeys(udiTokenId, ADR(abyKey), SIZEOF(abyKey), 2436001000); // eError=NO_ERROR, SIZEOF=68 // writerGroup.itfSecurityGroup := fbSecurityGroup -- set in the WriterGroup block's Parameters (a per-scan code write got overwritten) What I verified eError = NO_ERROR after both GetConfig and SetSecurityKeys; udiEncryptionKeySize = 32. Key length = 68 bytes (signing 32 ‖ encrypt 32 ‖ nonce 4). itfSecurityGroup is set via the WriterGroup's Parameters (so it isn't clobbered each scan). Init runs before xEnable (the writer doesn't run with xEnable=FALSE). The UADP.writerGroup FB exposes only itfSecurityGroup for security — no SecurityMode/MessageSecurityMode property. Result: the published datagrams are still plaintext — ExtendedFlags1 = 0x01 (security bit 0x10 clear), no security header: b1 01 29 00 0f 16 00 … (PublisherId 41, WriterGroupId 22, RawData, no security) Questions With UADP.writerGroup, is assigning a configured + keyed PSS.SecurityGroup to itfSecurityGroup sufficient to enable message security, or is there an additional step/property/method to switch the WriterGroup to SignAndEncrypt? At what point in the WriterGroup lifecycle is itfSecurityGroup read? Must it be assigned/keyed before xActive, and does the group need a stop→start to pick it up? Is there a required call order, and does SetSecurityKeys need to be called once or repeatedly? Should security be configured on the Connection/Configuration level rather than (or in addition to) the WriterGroup? Is there a working example of secured (SignAndEncrypt) programmatic UADP publishing with this library, or a known limitation in 1.3? How can I read back at runtime whether security is actually active (via itfDiagnostics or similar)? Additional information I can confirm that the consumer side works — i.e. a standard subscriber decrypts the same keys fine — so the keys/profile aren't the issue. The Wireshark capture of the published message is: 0000 b1 01 29 00 0f 16 00 df 0d bb 25 01 00 0e 00 1b ..).......%..... 0010 0e 00 00 00 00 00 00 00 ........
Last updated: 2026-06-22

Post by rossanoparis on CAN TX regression in Control for Raspberry Pi 4.21.0.0 with CAN API library (RX works, TX silently fails) ^{CODESYS Forge} ^talk ^(Post)
Environment: Target: Revolution Pi (Kunbus RevPi), armv7l 32-bit OS: Raspbian GNU/Linux 9 (Stretch), kernel 4.19.95-rt38-v7 (SMP PREEMPT RT, built 2022-03-22) CAN: via SocketCAN (can0) Runtime: CODESYS Control for Raspberry Pi SL IDE: CODESYS V3.5 SP22 + patch 3 (previously V3.5 SP22 + patch 2, where everything worked with runtime 4.18.0.0) Library: CANBusAPI from the "CAN API" package, version 1.0.0.3 Summary: The setup worked correctly with V3.5 SP22 + patch 2 and runtime 4.18.0.0. After updating the IDE to SP22 + patch 3 and the runtime to 4.21.0.0, CAN transmission via the CANBusAPI library stopped working. Reception is unaffected. There are no error indications anywhere: the application runs normally and the CAN diagnosis reports a healthy bus. Systematic testing (below) shows the problem follows the runtime version, not the IDE update. Regression isolation: The same application (compiled under SP22 + patch 3, unchanged between tests) was downloaded to the same target with different runtime versions, changing only the runtime each time: 4.18.0.0: TX and RX both work 4.19.0.0: TX and RX both work 4.20.0.0: TX and RX both work 4.21.0.0: RX works, TX does not The behavior is fully reproducible in both directions (downgrading to 4.20 restores TX, upgrading to 4.21 breaks it again). Hardware, wiring, OS, project, and application code are identical across all tests. Diagnostic data (CANBusDiagnosis FB, while the application is transmitting on 4.21): ctSendCounter: incrementing normally ctTxErrorCounter: 0 ctRxErrorCounter: 0 eState: ERROR_FREE xBusAlarm: FALSE So the library accepts and counts the outgoing messages, no TX errors are reported, and the CAN controller state stays error-free, but the messages never reach the other nodes on the bus. Expected behavior: Messages sent via CANBusAPI (CANDriver / SendMessage) are transmitted on the bus, as with runtime versions up to and including 4.20.0.0. Notes: I am aware that the CAN API package (1.0.0.3, from 2016) is old; however, the regression is tied to the runtime version, since the identical binary works on 4.18-4.20. Questions: Is there a known change in CmpSocketCanDrv / CmpCAACanL2 between 4.20.0.0 and 4.21.0.0 that could affect TX via the CAN API library? Is runtime 4.21.0.0 still supported on Debian 9 Stretch (kernel 4.19, RT-patched), or is a newer OS required? If a minimum OS/kernel requirement was introduced with 4.21, is it documented?
Last updated: 2026-08-17

Post by mogam on Internal error:System.NullReferenceException: The object reference was not set to an object instance. ^{CODESYS Forge} ^talk ^(Post)
Hi everyone, I have a my App that reads values from a shared memory than 2 variables x,y were calculated. here as you can see in my code: PROGRAM PLC_PRG VAR szName : STRING := '/SM'; ( Name of the shared memory.) uxiSize : __UXINT := 646 * 2 * SIZEOF(REAL); ( Size of the shared memory. ) hShm : RTS_IEC_HANDLE; ( Handle to the shared memory ) pStart : POINTER TO REAL; ( Pointer to the first element in the memory ) pData : POINTER TO REAL; ( Pointer, which is incremented until the last sign in the memory is reached. ) shared_data :ARRAY[0..645, 0..1] OF REAL; velocity : ARRAY[0..2] OF REAL; ( Velocity array ) position : ARRAY[0..2] OF REAL; ( Position array ) angleDepth : ARRAY[0..645, 0..1] OF REAL; ( Angle and depth array ) xEndOfMemory : BOOL; x : ARRAY[0..645] OF REAL := 1.0; y : ARRAY[0..645] OF REAL := 1.0; (* Result of actions at the memory. *) OpenResult : RTS_IEC_RESULT; ReadResult : RTS_IEC_RESULT; PointerResult : RTS_IEC_RESULT; DeleteResult : RTS_IEC_RESULT; CloseResult : RTS_IEC_RESULT; i : INT; END_VAR ( Open the shared memory ) hShm := SysSharedMemoryOpen2(szName, 0, ADR(uxiSize), ADR(OpenResult)); IF hShm <> RTS_INVALID_HANDLE THEN (* Read the entire shared memory table *) SysSharedMemoryRead(hShm:= hShm, ulOffset:= 0, pbyData:= ADR(shared_data), ulSize:= uxiSize, pResult:= ADR(ReadResult)); (* Fetch the pointer from the shared memory. The pointer is pointing to the first element address *) //pStart := SysSharedMemoryGetPointer(hShm, ADR(PointerResult)); (* Close the shared memory *) //CloseResult := SysSharedMemoryClose(hShm := hShm); (* Read velocity and position data from the shared memory *) FOR i := 0 TO 2 DO velocity[i] := shared_data[i, 0]; position[i] := shared_data[i, 1]; END_FOR; (* Read angle and depth data from the shared memory *) FOR i := 0 TO 645 DO angleDepth[i, 0] := shared_data[(i + 6), 0]; angleDepth[i, 1] := shared_data[(i + 6), 1]; END_FOR; FOR i := 0 TO 645 DO x[i] := angleDepth[i, 1]*COS(angleDepth[i, 0]); y[i] := angleDepth[i, 1]*SIN(angleDepth[i, 0]); END_FOR; END_IF For these values an XY-CHART needs to be done and when i create a visualisation and set the x data and y data when i try to compile, i recieve this error: ------ Übersetzungslauf gestartet: Applikation: Device.Read_App ------- Code typisieren ... [FEHLER] Internal error:System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt. bei _3S.CoDeSys.LanguageModelManager.LDateType.Accept(ITypeVisitor typvis) bei ..(_IVariable , IScope5 , _ICompileContext , _ISignature ) bei ..(_ISignature , IScope5 , _ICompileContext ) bei ..(_ISignature , _IPreCompileContext ) bei ..( ) bei ..(String ) bei ..(String , IVariable[]& , ISignature[]& ) bei ..(String , IVariable[]& , ISignature[]& , IScope& ) bei ..visit(_IVariableExpression , AccessFlag ) bei ..(_IUserdefType ) bei ..(_IVariable , IScope5 , _ICompileContext , _ISignature ) bei ..(_ISignature , IScope5 , _ICompileContext ) bei ..(_ISignature , _IPreCompileContext ) bei ..( ) bei ..(String ) bei ..(String , IVariable[]& , ISignature[]& ) bei ..(String , IVariable[]& , ISignature[]& , IScope& ) bei ..visit(_IVariableExpression , AccessFlag ) bei ..(_IUserdefType ) bei ..(_IVariable , IScope5 , _ICompileContext , _ISignature ) bei ..(_ISignature , IScope5 , _ICompileContext ) bei ..(_ISignature , _IPreCompileContext ) bei ..( ) bei ..(String ) bei ..(String , IVariable[]& , ISignature[]& ) bei ..(String , IVariable[]& , ISignature[]& , IScope& ) bei ..visit(_IVariableExpression , AccessFlag ) bei ..(_IUserdefType ) bei ..(_IVariable , IScope5 , _ICompileContext , _ISignature ) bei ..(_ISignature , IScope5 , _ICompileContext ) bei ..(_ISignature , _IPreCompileContext ) bei ..( ) bei ..(String ) bei ..(String , IVariable[]& , ISignature[]& ) bei ..(String , IVariable[]& , ISignature[]& , IScope& ) bei ..visit(_IVariableExpression , AccessFlag ) bei ..(_IUserdefType ) bei ..(_IArrayType ) bei ..(_IPointerType ) bei ..(_IVariable , IScope5 , _ICompileContext , _ISignature ) bei ..(_ISignature , IScope5 , _ICompileContext ) bei ..(_ISignature , _IPreCompileContext ) bei ..( ) bei ..(String ) bei ..(String , IVariable[]& , ISignature[]& ) bei ..(String , IVariable[]& , ISignature[]& , IScope& ) bei ..visit(_IVariableExpression , AccessFlag ) bei ..(_IUserdefType ) bei ..(_IPointerType ) bei ..(_IVariable , IScope5 , _ICompileContext , _ISignature ) bei ..(_ISignature , IScope5 , _ICompileContext ) bei ..(_ISignature , _IPreCompileContext ) bei ..( ) bei ..(String ) bei ..(String ) bei ..(_ISignature , IScope5 , _ICompileContext ) bei ..(_ISignature , IScope5 , _ICompileContext ) bei ..(_ISignature , _IPreCompileContext ) bei ..( ) bei ..(String ) bei ..(String ) bei ..(_ISignature , IScope5 , _ICompileContext ) bei ..(_ISignature , IScope5 , _ICompileContext ) bei ..(_ISignature , _IPreCompileContext ) bei ..( ) bei ..(String ) bei ..(String ) bei ..(_ISignature , IScope5 , _ICompileContext ) bei ..(_ISignature , _IPreCompileContext ) bei ..( ) bei ..(String ) bei ..(String , IVariable[]& , ISignature[]& ) bei ..(String , IVariable[]& , ISignature[]& , IScope& ) bei ..visit(_IVariableExpression , AccessFlag ) bei ..(_IUserdefType ) bei ..(_IVariable , IScope5 , _ICompileContext , _ISignature ) bei ..(_ISignature , IScope5 , _ICompileContext ) bei ..(_ISignature , _IPreCompileContext ) bei ..( ) bei ..(String ) bei ..(String , IVariable[]& , ISignature[]& ) bei ..(String , IVariable[]& , ISignature[]& , IScope& ) bei ..visit(_IVariableExpression , AccessFlag ) bei ..(_IUserdefType ) bei ..(_IVariable , IScope5 , _ICompileContext , _ISignature ) bei ..(_ISignature , IScope5 , _ICompileContext ) bei ..(_ISignature , _IPreCompileContext ) bei ..( ) bei ..(String ) bei ..(String , IVariable[]& , ISignature[]& ) bei ..(String , IVariable[]& , ISignature[]& , IScope& ) bei ..visit(_IVariableExpression , AccessFlag ) bei ..(_IUserdefType ) bei ..(_IPointerType ) bei ..(_IVariable , IScope5 , _ICompileContext , _ISignature ) bei ..(_ISignature , IScope5 , _ICompileContext ) bei ..(_ISignature , _IPreCompileContext ) bei ..( ) bei ..(String ) bei ..(String ) bei ..(_ISignature , IScope5 , _ICompileContext ) bei ..(_ISignature , IScope5 , _ICompileContext ) bei ..(_ISignature , _IPreCompileContext ) bei ..( ) bei ..(String ) bei ..(String ) bei ..(_ISignature , IScope5 , _ICompileContext ) bei ..(_ISignature , _IPreCompileContext ) bei ..( ) bei ..(String ) bei ..(String , IVariable[]& , ISignature[]& ) bei ..(String , IVariable[]& , ISignature[]& , IScope& ) bei ..visit(_IVariableExpression , AccessFlag ) bei ..(_IUserdefType ) bei ..(_IVariable , IScope5 , _ICompileContext , _ISignature ) bei ..(_ISignature , IScope5 , _ICompileContext ) bei ..(_ISignature , _IPreCompileContext ) bei ..( ) bei ..(String ) bei ..(String , IVariable[]& , ISignature[]& ) bei ..(String , IVariable[]& , ISignature[]& , IScope& ) bei ..visit(_IVariableExpression , AccessFlag ) bei ..(_IUserdefType ) bei ..(_IVariable , IScope5 , _ICompileContext , _ISignature ) bei ..(_ISignature , IScope5 , _ICompileContext ) bei _3S.CoDeSys.Compiler35140.Compiler.(_ICompileContext , _IPreCompileContext , _ICompileContext , IProgressCallback ) bei _3S.CoDeSys.Compiler35140.Compiler.(_ICompileContext , Boolean , Boolean , _IPreCompileContext , _IPreCompileContext , _ICompileContext , Boolean , Boolean& , IProgressCallback ) bei _3S.CoDeSys.Compiler35140.Compiler.(Guid , Boolean , Boolean , Boolean , Boolean& , _ICompileContext& , _ICompileContext& , IProgressCallback , Boolean , Boolean ) Kompilierung abgeschlossen -- 1 Fehler, 0 Warnungen Übersetzung abgeschlossen -- 1 Fehler, 0 Warnungen : Kein Download möglich!
Last updated: 2024-05-24

Post by mubeta on Some 'pathetic' errors in SoftMotion program ^{CODESYS Forge} ^talk ^(Post)
Hello everyone, I have a very simple program for the process, but it's driving me crazy and I can't see the problems I'm left with: Short topological description: Dual Core Berghof controller with softmotion runtime version 3.5.19.30; Two axes with servodrive on canopen bus, clocked distributed from master; Ethercat I/O node; 2 ms ethercat task, 2 ms canopen bus cycle time; I/O objects of the canopen master and canopen drives connected to the ethercat task cycle; Problem 1: Two separate programs each manage their own axis and drive, with separate state machines. A first axis moves primarily in velocity, except having to position itself absolutely at a predetermined point at the end of the job; the second axis, on the other hand, is a paper unwinder that changes, for each job cycle, from actions in absolute, relative, and cam displacement with the master axis. Well, the state machine of both axes was written in such a way as to call running the useful FB and change it on state change in this way: CASE i_stateMachine OF 0: o_Power(Enable := TRUE, bRegulatorOn := FALSE, bDriveStart := FALSE, Axis := o_PaperUnwinderAxis); o_MoveAbs(Execute := FALSE, Axis := o_PaperUnwinderAxis); o_MoveRel(Execute := FALSE, Axis := o_PaperUnwinderAxis); o_CamSelect(Execute := FALSE, Master := o_MachineAxis, Slave := o_PaperUnwinderAxis, CamTable := cam_PaperUnwinder); o_CamIn(Execute := FALSE, Master := MachineEncoder, Slave := o_PaperUnwinderAxis); o_CamOut(Execute := FALSE, Slave := o_PaperUnwinderAxis); o_SetPosition(Execute := FALSE, Axis := o_PaperUnwinderAxis); IF ... THEN i_StateMachine := 10; END_IF; 10: o_Power( Enable := TRUE, bRegulatorOn := TRUE, bDriveStart := TRUE, Axis := o_PaperUnwinderAxis ); IF o_Power.Status THEN i_StateMachine := 20; END_IF; 20: (* Avanzamento carta *) o_MoveAbs( Execute := TRUE, Position := o_Somewhere, Velocity := 25.0, Acceleration := 3666.7, Deceleration := 3666.7, Jerk := 48000.0, Direction := MC_DIRECTION.positive, Axis := o_PaperUnwinderAxis ); IF o_MoveAbs.Done THEN o_MoveAbs(Execute := FALSE, Axis := o_PaperUnwinderAxis); i_StateMachine := 30; END_IF 30: d_HomingPosition := ...; o_SetPosition( Execute := TRUE, Position := d_HomingPosition, Mode := FALSE, Axis := o_PaperUnwinderAxis ); (* ... *) IF o_SetPosition.Done = TRUE THEN o_SetPosition(Execute := FALSE, Axis := o_PaperUnwinderAxis ); o_LogServer.Append(sMessage := '...', lscClass := LOGSERVER_CLASS.ALWAYS, sdt := o_CommonsMgrData.systime.sdtLocal); i_StateMachine := 40; END_IF; 50: ... The code above is a sketchy example of what I wanted to write. But it gives me a spot problem: in some, the state change results in a drive error, which is unrecoverable except with a reinitialization via SM3_ReinitDrive(). Things are improved a little if in the program I always run the call of all softmotion blocks in this way: o_Power(Axis := o_PaperUnwinderAxis); o_Jog(Axis := o_PaperUnwinderAxis); o_Halt(Axis := o_PaperUnwinderAxis); o_MoveAbs(Axis := o_PaperUnwinderAxis); o_MoveRel(Axis := o_PaperUnwinderAxis); o_CamIn(Master := MachineEncoder, Slave := o_PaperUnwinderAxis); o_CamOut(Slave := o_PaperUnwinderAxis); If I don't execute all the calls of all the motion FBs used, when exchanging machine state often (but not always), the axis goes into error with event id THE_FB_WASNT_CALL... Done a little diagnostics it seems that the FBs return the bDone, before they are completely terminated. I tried doing the machine state exchange not with the bDone bit of the FBs, but with the 'standstill' state of the axis. It didn't seem to change anything. Problem 2: During the use SM3_ReinitDrive() I get the erro in the log: "NetID 0: SDO read error for object 16#607C..." Assuming that the device involved it's one of the two servodrive, (no others device are present in the network), I don't found any object 0x607C in the 'possible object list in/out' of the two drive, and I don't understand where this object can be listed. So any ideas and suggestions regarding these two issues will be very, very welcome. If you need the source project, I am willing to send it.
Last updated: 2024-07-17

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 smeitink on Timeout Error in Modbus Communication with WAGO PFC200 and iEM2050 Meter using 750-652 Module ^{CODESYS Forge} ^talk ^(Post)
Hi all, I'm looking for help with an issue I've come across while trying to facilitate Modbus communication between a WAGO PFC200 PLC using a 750-652 communication module and an iEM2050 Series Single Phase Energy Meter. I believe to have everything wired and setup correcty, but I keep running into a "Error time out" message, and by now I don't really know what else to try. My setup is as follows: A PFC200 Wago PLC, which has 2 750-652 Serial Interfaces extension modules connected to its field bus. I'm using one of these to talk to a Schneider iEM2050 - kWh-meter over modbus. I have connected terminal 23 (A) of the iEM2050 to connector 6 (A) on the 750-652. I have connected terminal 24 (B) of the iEM2050 to connector 2 (B) of the 750-652. I'm using 200mm of twisted together wires to connected them both, and I have placed a 120 ohm resistor between A and B at both ends. I've attached relevant pinout images to this post. I then wrote a simple program that configures the Mobus port, as per the datasheet of the iEM2050. You can find an image of the relavent page attached to this post too. This is my program: PROGRAM PLC_PRG VAR Master: FbMbMasterSerial; xIsConnected: BOOL; xError: BOOL; iIndex: INT := 1; xTrigger: BOOL; utQuery : typMbQuery := ( bUnitId := 1, // The Modbus unit or slave address bFunctionCode := 4, // Function code for reading input registers uiReadAddress := 1829, // adress for the Power on off counter uiReadQuantity := 1 // Quantity of registers to read ); iStep: INT; oStatusModbus: WagoSysErrorBase.FbResult; utResponseModbus: typMbResponse; xConnect: BOOL := FALSE; delayTimer: TON; END_VAR Master( xConnect:= xConnect, I_Port:= _750_652_24_1, udiBaudrate:= 9600, usiDataBits:= 8, eParity:= WagoTypesCom.eTTYParity.Even, eStopBits:= WagoTypesCom.eTTYStopBits.One, eHandshake:= WagoTypesCom.eTTYHandshake.None, ePhysical:= WagoTypesCom.eTTYPhysicalLayer.RS485_HalfDuplex, xIsConnected=> xIsConnected, xError=> xError, oStatus=> oStatusModbus, eFrameType:= WagoAppPlcModbus.eMbFrameType.RTU, tTimeOut:= T#5S, utQuery:= utQuery, xTrigger:= xTrigger, utResponse:= utResponseModbus); delayTimer(IN := TRUE, PT := T#3S); // Use the Q output of the timer to set xConnect after the delay IF delayTimer.Q THEN xConnect := TRUE; END_IF CASE iStep OF 0: //Wacht totdat de master de poort geopend heeft IF xIsConnected THEN iStep := 1; END_IF 1: //Stuur request naar de slave xTrigger := TRUE; iStep := 2; 2: //Wacht totdat de master klaar is met het afhandelen van de request IF NOT xTrigger THEN iStep := 3; END_IF END_CASE The TON delay before opening the port is due to a an error I encountered when opening it straight away. This seems to be a bug, as described here. However, the TON solved that particular issue. I tried reading multiple registers, but like I said, I still always end up with the "Error time out". What else can I test or try at this point?
Last updated: 2024-02-24

Post by scoob on ModbusFB - Slow Response Time ^{CODESYS Forge} ^talk ^(Post)
Hello, I have been trying to use the ModbusFB functions so I can put some code into libraries, but it seems to be very slow for me. I have a Modbus device with 100ms registers. I previously setup 10 channels in the 'traditional' Modbus Slave with channels and mappings - and set a cyclic trigger at 100ms - this worked fine. I then tried the ModbusFB example, and setup reading the same 10 blocks of modbus addresses, copying the example and putting all of the requests into an array and triggering the requests sequentially. I timed how long the requests are taking to get round to each one, and it is around 1s 450ms. How do I speed this up to match the cyclic time? IF NOT(init) THEN init := TRUE; // Set the required IP address: ipAddress[0] := 192; ipAddress[1] := 168; ipAddress[2] := 1; ipAddress[3] := 10; // Pass the required IP address to the clinet FB: client_NetworkSwitch.aIPaddr := ipAddress; client_NetworkSwitch.udiLogOptions := (ModbusFB.LoggingOptions.ClientConnectDisconnect OR ModbusFB.LoggingOptions.ClientReceivedValidReplies); // Try to connect the client client_NetworkSwitch(xConnect:=TRUE); // Configure all the channels to read connecting them to the client: portStatus_Request(rClient := client_NetworkSwitch, uiStartItem := 4096, uiQuantity := 32, pData := ADR(portStatus), udiReplyTimeout := udiReplyTimeout); portSpeed_Request(rClient := client_NetworkSwitch, uiStartItem := 4352, uiQuantity := 32, pData := ADR(portSpeed)); flowControl_Request(rClient := client_NetworkSwitch, uiStartItem := 4608, uiQuantity := 32, pData := ADR(flowControl)); linkUpCounter_Request(rClient := client_NetworkSwitch, uiStartItem := 5888, uiQuantity := 32, pData := ADR(linkUpCounter)); txPacketCounter1_Request(rClient := client_NetworkSwitch, uiStartItem := 8192, uiQuantity := 100, pData := ADR(txPacketCounter1)); txPacketCounter2_Request(rClient := client_NetworkSwitch, uiStartItem := 8292, uiQuantity := 28, pData := ADR(txPacketCounter2)); rxPacketCounter1_Request(rClient := client_NetworkSwitch, uiStartItem := 8448, uiQuantity := 100, pData := ADR(rxPacketCounter1)); rxPacketCounter2_Request(rClient := client_NetworkSwitch, uiStartItem := 8548, uiQuantity := 28, pData := ADR(rxPacketCounter2)); txErrors_Request(rClient := client_NetworkSwitch, uiStartItem := 8704, uiQuantity := 64, pData := ADR(txErrors)); rxErrors_Request(rClient := client_NetworkSwitch, uiStartItem := 8960, uiQuantity := 64, pData := ADR(rxErrors)); // Trigger all client requests initially FOR clientRequestsCnt := 0 TO (SIZEOF(clientRequests)/SIZEOF(clientRequests[0]))-1 DO pClientRequest := clientRequests[clientRequestsCnt]; pClientRequest^.xExecute := TRUE; END_FOR // Prepare sequential trigger / control of client requests. clientRequestsCnt := 0; pClientRequest := clientRequests[clientRequestsCnt]; END_IF // Call the client to do request processing: client_NetworkSwitch(); // Now we trigger client request sequentially ... IF NOT pClientRequest^.xExecute AND NOT pClientRequest^.xDone AND run AND client_NetworkSwitch.xConnected THEN pClientRequest^.xExecute := TRUE; END_IF // .. and check result/error IF pClientRequest^.xExecute AND run AND client_NetworkSwitch.xConnected THEN IF pClientRequest^.xDone THEN // Prepare next trigger of client request (a rising edge of xExecute) pClientRequest^.xExecute := FALSE; IF clientRequestsCnt < SIZEOF(clientRequests)/SIZEOF(clientRequests[0])-1 THEN // next client request clientRequestsCnt := clientRequestsCnt + 1; ELSE clientRequestsIterationCounter := clientRequestsIterationCounter + 1; clientRequestsCnt := 0; END_IF pClientRequest := clientRequests[clientRequestsCnt]; END_IF END_IF I did try a semi-coded way using the IoDrvModbusTCP library, and setting the slave com settings, then 10 commands and 10 requests, then using a TP on xDone as a pause, before triggering another request - this is time the delay is around 120ms - so the device is fine with the speed, just something I am doing wrong in the ModbusFB method I am sure.
Last updated: 2024-04-26

Post by brouwyka on JSONByteArrayWriter string result incorrect order ^{CODESYS Forge} ^talk ^(Post)
Hi @TimvH, As discussed in our email contact, your example does not actually test/reproduce the bug I am describing: Adding to the JSON builder on later cycles works fine. Your example works because you do the following: 1. You finish the first cycle (xFirst) with adding an object to the array with 2 fields; 2. When the next cycle is triggered (xAdd), you immediately start with adding another object to that array. This works fine as the last thing you did before #2 was the addition of the array and an object to it. To reproduce the bug you should be doing the following instead, as I showed with the code I shared with my first post: 1. Create the array - save the index that is returned; 2. Add an item, either a primitive or an object, to the array; 3. Add an item outside the array (anything: a primitive, a new array, a nested object, etc); 4. Add another item to the array using the index you saved at #1. You will now see, as I shared in my initial post, that the second item is placed completely outside the root JSON object. This also happens to anything else you try to add after step #4: everything after this point will be added outside the root JSON object: the JSON is completely broken. Important to note is that this not only happens with arrays, but also with nested JSON objects. Once you add something outside of a nested JSON object, you can no longer add anything to that nested JSON object, as that causes the exact same bug. This also applies to arrays of objects, so if in your test you had tried adding a new key-value pair to the first nested object in your array after you created the second nested object, you would also run into this bug. It seems that the JSONByteArrayWriter (I haven't tested the other writers in the JSON Utilities SL library, so I don't know if they suffer from the same problem) simply does not handle any JSON fields that add brackets (so arrays with "[" & "]" and nested objects with "{" & "}") well, and closes them prematurely instead of checking if any later JSONElements in the JSONData's array belong to any of these bracketed fields. After reviewing the objects & functions of the JSON Utilities SL library, my guess is that either the JSONByteArrayWriter linearly goes through the array of JSONElements in the JSONData and only checks the diParentIndex of each JSONElement in direct ascending order, OR if it does use the JSONElement.GetChildren(); method, that this method is either broken and doesn't give all children correctly to the writer. Neither explains why everything completely breaks, and you cannot even add to the root JSON object anymore, however, so there is probably more than just that going wrong in the writer. To me, after a full week of testing and attempting workarounds, this seems like a bug in the library that needs to be fixed by Codesys, as I cannot see anything wrong in the JSONData constructed by the JSONBuilder - this seems purely a problem in the writer.
Last updated: 2026-06-15

Post by baltzer on ICertificateVerifier.VerifyCertificate doesn't appear to override an ERR_CERT_HAS_EXPIRED rejection in TCP_Client.Upgrade() ^{CODESYS Forge} ^talk ^(Post)
Setup: Net Base Services (NBS), TCP_Client + TLSContext, ePurpose := CLIENT_SIDE, connecting to a third-party embedded device (Velux KLF200 home automation gateway) whose factory-installed TLS certificate expired on 2026-07-12 and has no user-facing renewal path. Tested on both CODESYS Control for Raspberry Pi SL (3.5.19.0) and CODESYS Control Win V3 x64, with identical results on both. Goal: Accept the peer's expired certificate via a custom ICertificateVerifier implementation, since the certificate itself can never be replaced. Implementation: FUNCTION_BLOCK FB_MyCertVerifier IMPLEMENTS NBS.ICertificateVerifier VAR udiCallCount : UDINT; aeCurStateLog : ARRAY[0..9] OF NBS.RTS_IEC_RESULT; END_VAR METHOD VerifyCertificate : UDINT VAR_INPUT hCert : NBS.RTS_IEC_HANDLE; eCurState : NBS.RTS_IEC_RESULT; END_VAR IF udiCallCount < 10 THEN aeCurStateLog[udiCallCount] := eCurState; END_IF udiCallCount := udiCallCount + 1; VerifyCertificate := 0; // also tried: VerifyCertificate := eCurState; Wired in via tlsContext.itfCertVerifer := certVerifier at declaration time, alongside itfTLSContext := tlsContext set at TCP_Client's own declaration (per an earlier forum thread here on ensuring inline start-values on FB-typed variables are actually honored when nested one level deep - that fix was needed and worked correctly for getting the handshake to start at all). Observed: - VerifyCertificate is confirmed called exactly once per connection attempt (via the call counter above). - eCurState passed in = 0x709 = ERR_CERT_HAS_EXPIRED - correctly reflecting the actual state of the peer's certificate. - Packet capture confirms the full TLS 1.2 handshake completes correctly at the wire level: ClientHello -> ServerHello -> Certificate -> ServerKeyExchange -> ServerHelloDone -> our ClientKeyExchange/ChangeCipherSpec/Finished -> server's ChangeCipherSpec/Finished. Both sides successfully complete the cryptographic handshake. - Despite this, TCP_Client.Upgrade() subsequently returns NBS.ERROR.CONNECTION_ERROR, and the connection is torn down with a plain TCP FIN (not a TLS alert) roughly 7-8ms after our side ACKs the server's Finished message. - TCP_Client.eErrorID (inherited from LCon) remains NO_ERROR throughout - the failure is only visible via Upgrade()'s return value. - Returning 0 (ERR_OK/ERR_CERT_OK - confirmed via the CmpErrors2 Interfaces documentation that these are literally the same value) makes no difference. - Echoing eCurState back unchanged (on the theory that this callback might work like mbedTLS's native verify callback, where the incoming state is a flags value to be cleared/modified and returned, rather than paired with a separate fixed "accept" sentinel) also makes no difference. - Identical result across udiVerificationMode := 0, 1, and 2. - Importing the peer's certificate into the runtime's trusted certificate store via cert-import trusted makes no difference either. - With itfCertVerifer left at its default (no custom verifier) and udiVerificationMode := 2, the underlying engine sends its own fatal TLS alert (handshake_failure) immediately after receiving the peer's Certificate message - suggesting built-in validation may reject at the record layer independent of whether a custom verifier is even present. Questions: 1. Is there an additional step required for a custom ICertificateVerifier to actually override an ERR_CERT_HAS_EXPIRED (or more generally, any ERR_CERT_*) rejection, or is certificate validation enforced unconditionally for a CLIENT_SIDE TLSContext regardless of what the verifier returns? 2. Is 0/ERR_OK genuinely the correct "accept" return value for VerifyCertificate, or does it expect something else (a specific bit pattern, a different constant, a value that must be computed from hCert itself)? 3. Is there a supported way to connect to a peer presenting a certificate that is both self-signed and expired, short of the peer issuing a new certificate? Happy to share the full packet captures or additional test combinations if useful. Also worth noting for anyone finding this thread later: a maintained Node-RED library for this same device (node-red-contrib-velux-klf200, forked to handle this exact expired-certificate situation) solves it by disabling built-in TLS validation entirely (rejectUnauthorized: false) and doing fingerprint-based pinning by hand after the handshake completes, rather than relying on a validation callback - which may be the more realistic approach here too if ICertificateVerifier genuinely can't override this class of rejection. Thanks in advance /Jørgen Disclosure: most of the CODESYS code and this investigation was developed with the help of Claude (Anthropic's AI assistant) - the state machine design, SLIP/checksum implementation, and debugging methodology (including the packet capture analysis) were worked through in an extended back-and-forth with it. Posting here because we've run out of self-serviceable options and this now looks like it needs input from someone with visibility into NBS's actual implementation.
Last updated: 2026-07-26

<< < 1 .. 60 61 62 63 > >> (Page 62 of 63)

Sort by relevance or date

Forums

Help

Search talk: g-code comment

Forums

Help

Search talk: g-code comment

Searching