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

Post by matteodigani on Error using function block "Write alias address" ^{CODESYS Forge talk (Post)}
Hi, I've got a problem using the function block "Write alias address" (ETCStack library 4.9.0.0). this is the code: EtherCAT_1(); IF EtherCAT_1.ConfigRead AND enable THEN CASE seq OF 0: exec := FALSE; T.IN := TRUE; T.PT := T#10S; T(); IF T.Q THEN seq := 1; T.IN := FALSE; END_IF ; 1: T.IN := FALSE; T(); //THIS ONE WORK CORRECTLY! WrAliasAdd.xAbort := FALSE; WrAliasAdd.usiCom := DWORD_TO_USINT(EtherCAT_1.InstanceNumber); WrAliasAdd.wSlaveAddress := 1002; WrAliasAdd.xAutoIncAdr := FALSE; WrAliasAdd.uiAliasAddress := 19; WrAliasAdd.udiTimeOut := 3000; IF start THEN exec := TRUE; ELSE IF NOT error THEN start := TRUE; END_IF END_IF IF WrAliasAdd.xDone THEN start := FALSE; done := TRUE; error := FALSE; exec := FALSE; seq := 5; END_IF IF WrAliasAdd.xError THEN start := FALSE; done := FALSE; error := TRUE; exec := FALSE; END_IF ; 5: exec := FALSE; T.IN := TRUE; T.PT := T#1S; T(); IF T.Q THEN seq := 10; END_IF ; 10: T.IN := FALSE; T(); //THIS ONE GIVES ME AN ERROR! WrAliasAdd.xAbort := FALSE; WrAliasAdd.usiCom := DWORD_TO_USINT(EtherCAT_1.InstanceNumber); WrAliasAdd.wSlaveAddress := 1006; WrAliasAdd.xAutoIncAdr := FALSE; WrAliasAdd.uiAliasAddress := 25; WrAliasAdd.udiTimeOut := 1000; IF start THEN exec := TRUE; ELSE IF NOT error THEN start := TRUE; END_IF END_IF IF WrAliasAdd.xDone THEN start := FALSE; done := TRUE; error := FALSE; exec := FALSE; seq := 99; END_IF IF WrAliasAdd.xError THEN start := FALSE; done := FALSE; error := TRUE; exec := FALSE; END_IF ; ELSE ; END_CASE WrAliasAdd(xExecute := exec); END_IF The first one slave ethercat works correctly, but the other one gives me an error. Attached the ethercat configuration of the devices. All the devices are set "Optional". So my idea is to enable only the first one (1002) and the fifth one (1006).
Last updated: 2025-10-01

Post by mondinmr on Why SysPipeWindows is not implemented in RTE? ^{CODESYS Forge talk (Post)}
This library would be very useful for IPC communications. Using a UDP socket on localhost is unpredictable, as with slightly loaded machines it does not even guarantee packet delivery locally. Using TCP creates a lot of overhead. Message named pipes would be an excellent solution for Windows RTE. On Linux, since the release of the extension package, there is no issue, as it is sufficient to develop a component. However, although now 90% of our clients understand that Linux runtimes are better in every way compared to Windows RTE, especially from the security aspect (Not in kernel space) and the issues with Windows updates, 10% stubbornly insist (sometimes for trivial commercial reasons) on using Windows. Managing IPC with circular buffers in shared memory is quite ugly, or rather really ugly and unaesthetic. In the manuals, I saw the SysPipeWindows libraries, so I decided to test them, but unfortunately, I noticed that they are not implemented for RTE devices. Technically, I could try to open them as regular files, but SysFileOpen returns 16#27 or 16#39 depending on how I set the name (direction of the slashes). Here is the code to create shared memory and named pipes. Shared memory work great, named pipes no! #ifdef Q_OS_WIN32 SECURITY_ATTRIBUTES sa; SECURITY_DESCRIPTOR sd; InitializeSecurityDescriptor(&sd, SECURITY_DESCRIPTOR_REVISION); SetSecurityDescriptorDacl(&sd, TRUE, NULL, FALSE); sa.nLength = sizeof(SECURITY_ATTRIBUTES); sa.lpSecurityDescriptor = &sd; sa.bInheritHandle = FALSE; const wchar_t* name = L"Global\\ShmTest"; HANDLE hMapFile = CreateFileMapping( INVALID_HANDLE_VALUE, NULL, PAGE_READWRITE, 0, sizeof(SharedData), name); if (hMapFile == NULL) { qCritical("Error creating shared memory"); return 1; } data = static_cast<SharedData*>(MapViewOfFile(hMapFile, FILE_MAP_ALL_ACCESS, 0, 0, sizeof(SharedData))); if (data == NULL) { qCritical("Error mapping shared memory"); return 1; } HANDLE hPipe = CreateNamedPipe( TEXT("\\\\.\\pipe\\MyPipe"), PIPE_ACCESS_DUPLEX, PIPE_TYPE_MESSAGE | PIPE_READMODE_MESSAGE | PIPE_WAIT, PIPE_UNLIMITED_INSTANCES, 1024 * 1024, 1024 * 1024, NMPWAIT_USE_DEFAULT_WAIT, &sa); if (hPipe == INVALID_HANDLE_VALUE) { qCritical("Error creating named pipe"); return -1; } if (!ConnectNamedPipe(hPipe, NULL)) { qCritical("Error connecting to named pipe"); return -1; } checkPipe(hPipe); #endif
Last updated: 2024-02-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 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 jonasz on Device diagnosis ( EtherCAT IO card ) ^{CODESYS Forge talk (Post)}
Hi, I'll link to the topic not wanting to start a new one. In the application I am building, I wanted to use the diagnostics described in the CAA Device Diagnosis library. In principle, everything is ok, except for the elements related to ModbusTCP. Despite the fact that ModbusTCP is taken into account in the documentation, it is not recognised via the interfaces. FUNCTION_BLOCK NET_HW_DIAG VAR_INPUT END_VAR VAR_OUTPUT END_VAR VAR (* Referencja do struktury z danymi dla HMI ASTRAADA.*) Visu: REFERENCE TO VISU; (* Wskaźnik na mastera EtherCAT.*) pEtherCATMaster : POINTER TO IoDrvEtherCAT; (* Wskaźnik na slave EtherCAT.*) pEtherCATSlave : POINTER TO EtcSlave; (* Interfejs dla węzła w drzewie urządzeń.*) _itfNode: DED.INode; (* Ogólny interfejs magistrali. Zapewnia podstawowe informacje o magistrali polowej.*) _itfBus: DED.IBus; (* Interfejs urządzenia. Zapewnia rozszerzone informacje o urządzeniu (magistralowym).*) _itfDevice2: DED.IDevice2; (* Ogólny interfejs magistrali. Zapewnia podstawowe informacje o magistrali polowej.*) _itfStack: DED.IStack; (* Numer węzła w drzewie urządzeń.*) uiNodes: UINT; (* Operator jest rozszerzeniem normy IEC 61131-3. W czasie wykonywania operator wykonuje konwersję typu odwołania do interfejsu na inny typ. Operator zwraca wynik BOOL. Wartość TRUE oznacza, że CODESYS pomyślnie wykonał konwersję. *) xQueryResultBus: BOOL; xQueryResultDevice2: BOOL; xQueryResultStack: BOOL; (* Struktura danych dotyczących węzłów w drzewie urządzeń.*) NetHwDiag: NW_HW_STAT; ModbusTcpClientDeviceInfo: IoDrvModbusTCP.DED.DEVICE_INFO; ModbusTcpClientDeviceState: IoDrvModbusTCP.DED.DEVICE_STATE; ModbusTcpDeviceInfo: IoDrvModbusTCP.DED.DEVICE_INFO; ModbusTcpDeviceState: IoDrvModbusTCP.DED.DEVICE_STATE; END_VAR (* Pobranie wskaźników dla pierwszego mastera i pierwszego slave w sieci EtherCAT.*) pEtherCATMaster := g_pFirstMaster; pEtherCATSlave := pEtherCATMaster^.FirstSlave; (* Diagnostyka sieci EtherCAT.*) pEtherCATMaster := g_pFirstMaster; pEtherCATSlave := pEtherCATMaster^.FirstSlave; NetHwDiag.xConfigFinished := pEtherCATMaster^.xConfigFinished; NetHwDiag.xDistributedClockInSync := pEtherCATMaster^.xDistributedClockInSync; NetHwDiag.xError := pEtherCATMaster^.xError; NetHwDiag.xSyncInWindow := pEtherCATMaster^.xSyncInWindow; NetHwDiag.sLastMessage := pEtherCATMaster^.LastMessage; NetHwDiag.LastError := pEtherCATMaster^.LastError; (* Diagnostyka drzewa urządzeń.*) uiNodes := 0; _itfNode := DED.GetRoot(); REPEAT NetHwDiag.asDeviceName[uiNodes] := DED.GetDeviceNameString(itfNode := _itfNode); xQueryResultBus := __QUERYINTERFACE(_itfNode,_itfBus); IF xQueryResultBus THEN _itfBus.GetBusInfo(buiInfo := NetHwDiag.aBusInfo[uiNodes]); NetHwDiag.aBusState[uiNodes] := _itfBus.GetBusState(); END_IF xQueryResultDevice2 := __QUERYINTERFACE(_itfNode,_itfDevice2); IF xQueryResultDevice2 THEN _itfDevice2.GetDeviceInfo(deiInfo := NetHwDiag.aDeviceInfo[uiNodes]); NetHwDiag.aDeviceState[uiNodes] := _itfDevice2.GetDeviceState(); IF pEtherCATSlave <>0 THEN pEtherCATSlave^(); IF pEtherCATSlave^.SlaveAddr = NetHwDiag.aDeviceInfo[uiNodes].idSystem THEN NetHwDiag.aAlStatus[uiNodes] := pEtherCATSlave^.ALStatus; pEtherCATSlave := pEtherCATSlave^.NextInstance; END_IF END_IF ELSE xQueryResultStack := __QUERYINTERFACE(_itfNode,_itfStack); IF xQueryResultStack THEN _itfStack.GetDeviceInfo(deiInfo := NetHwDiag.aDeviceInfo[uiNodes]); NetHwDiag.aDeviceState[uiNodes] := _itfStack.GetDeviceState(); END_IF END_IF uiNodes := uiNodes + 1; _itfNode := DED.GetNextNode(_itfNode); UNTIL _itfNode = 0 END_REPEAT (* Diagnostyka Modbus.*) Modbus_TCP_Client.GetDeviceInfo(deiInfo := ModbusTcpClientDeviceInfo); ModbusTcpClientDeviceState := Modbus_TCP_Client.GetDeviceState(); PAC_3200T.GetDeviceInfo(deiInfo := ModbusTcpDeviceInfo); ModbusTcpDeviceState := PAC_3200T.GetDeviceState(); Of course, you can take the easy way out and refer directly to the devices, but I wanted a reusable component. Any constructive help is very welcome Best regards Jonasz
Last updated: 2025-07-15

Post by 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 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 sahin6033 on DSE M840-001-02: DSEServiceTool transfers CodesysApp.pkg successfully, but device shows “No application loaded ^{CODESYS Forge talk (Post)}
Hi, I am trying to load a test application into a DSE M840-001-02 display, but after reboot the device still shows: “No application loaded” I would like to understand whether the problem is in my project, the package creation process, or firmware/runtime compatibility. Hardware Device: DSE M840-001-02 Firmware used: M840 MKII Firmware File v4.1.2 Software CODESYS V3.5 SP12 (32-bit) DSE CODESYS Package v1.5.44 DSEServiceTool What I did Created a new empty Standard Project Selected target/template: M840-02 V4.1 Used a minimal ST program only: PROGRAM PLC_PRG VAR xAlive : BOOL := TRUE; END_VAR Confirmed: project builds PLC_PRG is assigned to MainTask created Boot Application Generated CodesysApp.pkg Put the M840 into bootloader mode Sent the package using DSEServiceTool DSEServiceTool result Transfer completes successfully and I get: connection accepted 100% download package ACK <status>OK</status> ** Example log:** Searching for controllers.... sendPackageToController: waiting for incoming data connection... sendPackageToController: connection accepted... <status>Downloading</status> <percent>20</percent> <percent>40</percent> <percent>90</percent> <percent>100</percent> sendPackageToController: sent 112cb8 bytes OK Package ...\CodesysApp.pkg transferred to controller c0a80101 OK sendPackageToController: package ACK <status>OK</status> Actual result After reboot, the display still shows: “No application loaded” Additional issue I also saw earlier At one stage I also had these fatal errors in CODESYS: [FATAL ERROR] Unresolved reference: 'IOMGRLOCKENTER' [FATAL ERROR] Unresolved reference: 'IOMGRLOCKLEAVE' I checked library versions and adjusted them to: IoDrvBase = 3.5.5.0 IoStandard = 3.5.10.0 Also, I am using CODESYS SP12, which I understand is the correct version for DSE M840. My questions If DSEServiceTool shows Status OK and package ACK, but the device still says “No application loaded”, does that mean: the .pkg was transferred but not accepted as a valid application? the package was built incorrectly? the boot application / runtime / firmware versions are still mismatched? What is the correct procedure to generate CodesysApp.pkg for M840-02 V4.1? Is there any known compatibility issue between: DSE CODESYS Package 1.5.44 M840 MKII Firmware 4.1.2 CODESYS 3.5 SP12 Has anyone successfully loaded even a minimal empty test project into M840-001-02, and if so, what exact versions/process did you use? Any help would be appreciated.
Last updated: 2026-03-17

Post by winki on ModbusFB ClientRequest: never recovers after a single ReplyTimeout (requires full download) ^{CODESYS Forge talk (Post)}
Library: ModbusFB (CODESYS Modbus package) IDE / Runtime: CODESYS V3.5 SP___ / Control runtime ___ Target: ___ (e.g. gateway, Linux ARM64 / Debian) Slave: Modbus TCP inverter Summary I poll a Modbus TCP slave with a permanent connection: one ClientTCP (kept connected, xConnect:=TRUE) and one ClientRequestReadHoldingRegisters, triggered cyclically. Everything works fine after a fresh application download. But as soon as one single ReplyTimeout occurs (slave temporarily not answering), the request never recovers. It stays stuck and no further messages are sent, even though the TCP connection is still reported as alive. Only a full application download brings it back — an online change or a runtime reset is not enough / not what I want in production. State observed when stuck So the connection is alive, the request finished in ReplyTimeout, the FB is back to _state = None, but udiNumMsgSent no longer increases — as if a new rising edge on xExecute is no longer accepted / no longer produces a new message. My trigger logic (simplified) Each PLC cycle, in this order: If the request is fully at rest (NOT xExecute AND NOT xBusy AND NOT xDone AND NOT xError) and a read is pending, I set xExecute := TRUE. I call clientTcp() then clientRequest(rClient := clientTcp) once each, per cycle. On xDone or xError, I set xExecute := FALSE. I made sure to insert at least one full cycle with xExecute = FALSE (seen by the FB call) before re-triggering, so the falling edge is processed. Questions After a ReplyTimeout (xError = TRUE), what is the exact, correct sequence to re-trigger the same ClientRequest so a new message is actually sent again? Is a full cycle with xExecute = FALSE between two executions mandatory? Is there a known condition where, after ReplyTimeout, the ClientTCP keeps xConnected = TRUE but silently stops sending new requests (e.g. an internal request queue / _udiRequestId that gets out of sync)? udiNumMsgSent freezing at 23 while the FB shows _state = None is what puzzles me. Is the recommended pattern to drop the connection (ClientTCP.xConnect := FALSE for one cycle, then TRUE) on a request error, rather than keeping it alive? The docs state a request error does not close the connection, so I kept it open — but maybe that is the issue here. Could the large uiStartItem (50514) be relevant? It works right after download, so addressing seems correct, but I want to rule it out. Any guidance on the canonical recovery pattern after a request timeout would be greatly appreciated. Thanks!
Last updated: 2026-06-19

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 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 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 alessandro on SysMemCmp SysMemCpy ^{CODESYS Forge talk (Post)}
VAR Data1:ARRAY[1..10] OF SINT ; Data2:ARRAY[1..10] OF SINT ; Data3:ARRAY[1..10] OF SINT ; Data4:ARRAY[1..10] OF SINT ; ex_1 : BOOL ; ex_2 : BOOL ; enable : BOOL :=0 ; END_VAR // PROGRAM // The scope of this example is compare and copy the values of two ARRAY only if some value is different using SysMemCmp and SysMemCpy. // In this 2 example we don't use a FOR cicle for do this, and pBuffer1 and pBuffer2 is just a pointer to ARRAY. See details in Library util.SysMem of Codesys // The compare funcion util.SysMem.SysMemCmp is bidirectional if Data1 chanege respect Data2 ex_1 go to 1 and if Data2 change respect Data1 also // but the copy function util.SysMem.SysMemCpy work only from source ARRAY pSrc:=ADR(Data1) to destination ARRAY pDest:=ADR(Data2) // Example 1 Full ARRAY compare and copy // This compare 2 different equal ARRAY and if there is some difference ex_1 go to 1 and if you give enable he copy Data1 in Data2 ex_1 := TO_BOOL(util.SysMem.SysMemCmp(pBuffer1:=ADR(Data1), pBuffer2:=ADR(Data2), udiCount:=SIZEOF(Data1))); IF ex_1 AND enable THEN util.SysMem.SysMemCpy(pDest:=ADR(Data2), pSrc:=ADR(Data1), udiCount:=SIZEOF(Data1)); END_IF // Example 2 Only selected area of the ARRAY compare and copy // This compare 2 different equal ARRAY starting from position number [3] for 4 byte in this case start at position [3] and finish at position number [6] // and if there is some difference only in area [3..6] of the ARRAY ex_2 go to 1 if you give enalbe he copy Data3[3..6] in Data4[3..6] // if something change in other array position[0..2] or [7..10] are ingnored ex_2 := TO_BOOL(util.SysMem.SysMemCmp(pBuffer1:=ADR(Data3[3]), pBuffer2:=ADR(Data4[3]), udiCount:=4)); IF ex_2 AND enable THEN util.SysMem.SysMemCpy(pDest:=ADR(Data4[3]), pSrc:=ADR(Data3[3]), udiCount:=4); END_IF // Attention udiCount input is intended in <byte> in the example 1 I pass to udiCount:=SIZEOF(Data1) for compare and copy the intere ARRAY and // SIZEOF pass the size of intere ARRAY in byte to the function input, in this 2 examples I used variable type SINT each one occupie 1 byte and one position in the ARRAY // and in the example 2 I pass udiCount:=4 for compare and copy only 4 position of Data3/4[3..6] if you want to extend this example and use it for an ARRAY OF WORD // remember that each WORD will occupe 2 byte (16 bit) and you will have to pass udiCount:=SIZEOF(Data1) if you need to compare intere ARRAY example 1 // but need udiCount:=(42) for the example 2 because need to compare and copy 4 word each occupie 2 byte (16 bit). // For REAL (32 bit) need udiCount:=SIZEOF(44) for LREAL or (64 bit) need udiCount:=SIZEOF(416) // a good rule is calculate the dimension of the ARRAY in byte without empty space at the end, multiple of data type number for variable bigger then 8 bit // Example : If you want to create an ARRAY for 5 REAL (32 bit) each occupie 4 byte the correct size is ARRAY[0..19] OF REAL 54=20 position. // NOTE : In the example the position of compare function util.SysMem.SysMemCmp is first and the copy function util.SysMem.SysMemCpy inside the IF is after // in one cycle of the program the two array is compared and if there is some difference and enable are copied. // If you move util.SysMem.SysMemCmp after the IF cycle he will copare the ARRAY in the current cycle but the copy of the value will do in the next cycle.</byte>
Last updated: 2025-10-24

Post by brouwyka on JSONByteArrayWriter string result incorrect order ^{CODESYS Forge talk (Post)}
Hello everybody! We are currently working on implementing a call to an API that tracks data sent to it through a JSON body. Versions: CODESYS V3.5 SP19 Patch 7 using IIOT Libraries SL license, specifically JSON Utilities SL version 1.13.0.0. For simplicity, let's say we want to construct the following JSON body for our request (simplified to just 1 key-value pair in each of the array objects to keep things shorter, but we'd have multiple fields in each in reality): { "id": "machine_1", "readings": [ { "temp_mid": 153.8 }, { "temp_mid": 98.3 } ], "status": "RUNNING" } However, our "readings" data is added over time, not in creation, so calls to the builder would be somewhat out of order. In a simplified manner, our calls would look like this: jsonBuilder(pJsonData := JsonData, diRootObj => rootJsonIndex); // rootJsonIndex = 0. // Set "id" at root JSON object. wsValue := "machine_1"; jsonBuilder.SetKeyWithValue("id", wsValue, diParentIndex := rootJsonIndex); // JSONData KEY: diParentIndex = 0 & diIndex = 1, VALUE: diParentIndex = 1 & diIndex = 2. // ... Time passes, we get our first reading to add ... // The "readings" array does not exist yet, so we make it first at root JSON object before adding our first reading. readingsJsonArrayIndex := jsonBuilder.SetKeyWithArray("readings", diParentIndex := rootJsonIndex); // JSONData KEY: diParentIndex = 0 & diIndex = 3, VALUE: diParentIndex = 3 & diIndex = 4. // Then add the first reading, for which we first have to make an object. readingsJsonArrayObjectIndex := jsonBuilder.SetObject(diParentIndex := readingsJsonArrayIndex); // JSONData OBJECT: diParentIndex = 4 & diIndex = 5. // And then we add the field(s) in the object for the first reading. // NOTE the use of `readingsJsonArrayObjectIndex` so we set the field(s) in the first object in the array. rValue := 153.8; jsonBuilder.SetKeyWithValue("temp_mid", wsValue, diParentIndex := readingsJsonArrayObjectIndex); // JSONData KEY: diParentIndex = 5 & diIndex = 6, VALUE: diParentIndex = 6 & diIndex = 7. // ... Time passes, we want to add another root-JSON-level field ... // Set "status" at root JSON object. wsValue := "RUNNING"; jsonBuilder.SetKeyWithValue("status", wsValue, diParentIndex := rootJsonIndex); // JSONData KEY: diParentIndex = 0 & diIndex = 8, VALUE: diParentIndex = 8 & diIndex = 9. // ... Time passes, we want to add a second reading ... // "readings" array exists, so add the second reading, but first we have to make another object. // NOTE the re-use of the earlier stored `readingsJsonArrayIndex`, so we add the new object to that previously created array. readingsJsonArrayObjectIndex := jsonBuilder.SetObject(diParentIndex := readingsJsonArrayIndex); // JSONData OBJECT: diParentIndex = 4 & diIndex = 10. // And then we add the field(s) in the object for the first reading. // NOTE the use of `readingsJsonArrayObjectIndex` so we set the field(s) in the SECOND(, new) object in the array. rValue := 98.3; jsonBuilder.SetKeyWithValue("temp_mid", wsValue, diParentIndex := rootJsonIndex); // JSONData KEY: diParentIndex = 10 & diIndex = 11, VALUE: diParentIndex = 11 & diIndex = 12. // ... Finally, we want to send to the API, so we must convert the builder to data the client accepts as a body ... xTestWriteToJsonArray := TRUE; jsonArrayWriter( xExecute := xTestWriteToJsonArray, pwData := ADR(jsonDataString), udiSize := SIZEOF(jsonDataString), jsonData := JsonData^ ); IF jsonArrayWriter.xDone THEN // The writer was successful, the `jsonDataString` VAR should now contain a WString copy of the JSON object from the builder. xTestWriteToJsonArray := FALSE; END_IF We see that the JsonData STRUCT is correctly organised (in terms of the diParentIndex & diIndex set by it for each JsonElement) as we expect, as outlined in my comments in the simplified code above. However, as soon as we pass it to the jsonArrayWriter (which is a JSON.JSONByteArrayWriter), the resulting jsonDataString does not match our expectations, instead coming out like this: { "id": "machine_1", "readings": [ { "temp_mid": 153.8 } ] } { "temp_mid": 98.3 } "status": "RUNNING" The behaviour of the JSONByteArrayWriter thus seems to be the problem here. It does not seem to correctly process the children of JsonElements that are ARRAYs when additions to them are done broken up by additions to the lower level JSON OBJECT they are a part of. We have confirmed this by changing the order of the calls in our example to add both readings before adding the "status", in which case we get our expected outcome. However, in reality this is not possible for us - additions to any of the JSON's objects, arrays or array objects may happen at any time after other fields elsewhere in the JSON have been added. Does anyone know a way around this, a fix, or knows a solution we simply have not found? This same phenomenon was also noted on this forum by user @ryusoup at the end of 2023 (https://forge.codesys.com/forge/talk/Engineering/thread/c45929e2f1/#e27f) and user @mtho in early 2024 (https://forge.codesys.com/forge/talk/Engineering/thread/cd1bb450db/#1292) but both topics received no activity beyond both users' opening posts. Looking through the release notes of all the versions of the JSON Utilities SL library, I also did not see any remarks on resolutions of bugs in this vain. Thanks in advance for the assistance!
Last updated: 2026-06-10

Sort by relevance or date