JSON Utilities - JSON file written with invalid structure ^{CODESYS Forge talk (Thread)}
JSON Utilities - JSON file written with invalid structure
Last updated: 2026-06-14

Post by timvh on JSONByteArrayWriter string result incorrect order ^{CODESYS Forge talk (Post)}
See the example below. You can insert key/value pairs as required At first the JSON string will be filled with: "{$"Key1$": $"Value0$", $"Key2$": [{$"Key3$": 1, $"Key4$": 2}]}" With xAdd, you can insert items, which will result in: "{$"Key1$": $"Value0$", $"Key2$": [{$"Key3$": 1, $"Key4$": 2},{$"Key3$": 3, $"Key4$": 4}]}" VAR factory : JSON.JSONDataFactory; eDataFactoryError : FBF.ERROR; pJsonData : POINTER TO JSON.JSONData := factory.Create(eError => eDataFactoryError); fb_JBuilder : JSON.JSONBuilder; wsValue : WSTRING; diRootIndex, diObjectIndex1, diObjectIndex2, diObjectIndex3 : DINT; iValue : INT; jsonArrayWriter : JSON.JSONByteArrayWriter; wsJsonData : WSTRING(1000); xFirst : BOOL := TRUE; xWrite: BOOL; xAdd: BOOL; END_VAR IF xFirst THEN fb_JBuilder.Reset(); fb_JBuilder(pJsonData := pJsonData, diRootObj => diRootIndex); wsValue := "Value0"; fb_JBuilder.SetKeyWithValue("Key1", wsValue, diParentIndex := diRootIndex); diObjectIndex1 := fb_JBuilder.SetKeyWithArray(wsKey := "Key2", diParentIndex := diRootIndex); diObjectIndex2 := fb_JBuilder.SetObject(diParentIndex := diObjectIndex1); iValue := 1; fb_JBuilder.SetKeyWithValue("Key3", iValue, diParentIndex := diObjectIndex2); iValue := 2; fb_JBuilder.SetKeyWithValue("Key4", iValue, diParentIndex := diObjectIndex2); xFirst := FALSE; xWrite := TRUE; END_IF IF xAdd THEN xAdd := FALSE; diObjectIndex3 := fb_JBuilder.SetObject(diParentIndex := diObjectIndex1); iValue := 3; fb_JBuilder.SetKeyWithValue("Key3", iValue, diParentIndex := diObjectIndex3); iValue := 4; fb_JBuilder.SetKeyWithValue("Key4", iValue, diParentIndex := diObjectIndex3); xWrite := TRUE; END_IF IF xWrite THEN xWrite := FALSE; jsonArrayWriter( xExecute := TRUE, wsLinebreak := "", pwData := ADR(wsJsonData), udiSize := SIZEOF(wsJsonData), jsonData := pJsonData^, xAsyncMode := FALSE ); END_IF IF jsonArrayWriter.xDone OR jsonArrayWriter.xError THEN jsonArrayWriter(xExecute := FALSE, pwData := ADR(wsJsonData), udiSize := SIZEOF(wsJsonData), jsonData := pJsonData^, xAsyncMode := FALSE); END_IF
Last updated: 2026-06-14

JSONByteArrayWriter problem? ^{CODESYS Forge talk (Thread)}
JSONByteArrayWriter problem?
Last updated: 2026-06-14

[New Hardware] EtherCAT Digital & Analog IO Board – CODESYS Compatible, All Channels Isolated ^{CODESYS Forge talk (Thread)}
[New Hardware] EtherCAT Digital & Analog IO Board – CODESYS Compatible, All Channels Isolated
Last updated: 2026-06-13

Post by timvh on JSONByteArrayWriter problem? ^{CODESYS Forge talk (Post)}
See : https://forge.codesys.com/forge/talk/Engineering/thread/9afc7c8bad/#711c
Last updated: 2026-06-14

Post by yueqiqi on Where Can I download the latest Version of CoDeSys V ^{CODESYS Forge talk (Post)}
Where Can I download the latest Version of CoDeSys V2.3?
Last updated: 2026-06-15

Codesys V2.3 🇬🇧 ^{CODESYS Forge talk (Discussion)}
Forum about V2.3
Last updated: 2026-06-15

Where Can I download the latest Version of CoDeSys V ^{CODESYS Forge talk (Thread)}
Where Can I download the latest Version of CoDeSys V
Last updated: 2026-06-15

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

Hardware compatibility with Linux RealTime PLC ^{CODESYS Forge talk (Thread)}
Hardware compatibility with Linux RealTime PLC
Last updated: 2026-06-15

JSONByteArrayWriter string result incorrect order ^{CODESYS Forge talk (Thread)}
JSONByteArrayWriter string result incorrect order
Last updated: 2026-06-15

Post by wistaro on Hardware compatibility with Linux RealTime PLC ^{CODESYS Forge talk (Post)}
Hello, I am currently using Codesys Control RTE Softmotion V3 to control my servo-drives in CAN, EtherCAT and PROFINET IRT. I am using a PC with Windows 10 with the following boards: - PEAK-CAN PCIe board (for CAN and Softmotion); - Hilscher CifX with firmware 3.X and SysDrv3s driver (for PROFINET IRT); - Realteak standard NIC (for EtherCAT). I would like to switch to Linux (Debian), because this computer is old, slow, and outdated (Windows 11 is far from being compatible with this computer). Before doing this, I would like to be sure of the compatility between my 3 boards and Codesys Control Linux SL. Otherwize, I will stay on Windows 10 and use it in an isolated environnement. Thanks for your advices. Regards,
Last updated: 2026-06-15

Forge 🇬🇧 ^{CODESYS Forge talk (Discussion)}
Discussions about CODESYS Forge projects and features of the CODESYS Forge website
Last updated: 2026-06-15

WebVisu scaling regression in V3.5.22 P2: frame size jumps when switching visualizations ^{CODESYS Forge talk (Thread)}
WebVisu scaling regression in V3.5.22 P2: frame size jumps when switching visualizations
Last updated: 2026-06-15

Post by charly29160 on WebVisu scaling regression in V3.5.22 P2: frame size jumps when switching visualizations ^{CODESYS Forge talk (Post)}
Environment: - CODESYS V3.5.22 Patch 2 - CODESYS Control for Raspberry Pi MC SL - WebVisu in browser Problem: When switching between visualizations using a Register element (Registerkarten), the displayed frame size jumps incorrectly after returning to a previously viewed visualization. This behavior was introduced in V3.5.22 Patch 2. The same project worked correctly in V3.5.21 Patch 4. WebVisu settings in V3.5.21 (working): - Scaling: Isotropisch - Automatisch ermittelte Clientgröße verwenden: active - All visualizations: Automatisch erkannte Visualisierungsgröße Workaround?
Last updated: 2026-06-15

Post by meke001 on Visualisierungswerkzeuge ^{CODESYS Forge talk (Post)}
Hallo zusammen, ich habe ein hartnäckiges Problem mit der CODESYS-Visualisierung und hoffe auf eure Expertise. In meinem Projekt wird die Toolbox ("Werkzeuge") für die Visualisierung komplett leer angezeigt, es lassen sich also keine Basis-Elemente wie Rechtecke oder Kreise in die Zeichenfläche ziehen. Mein System: CODESYS V3.5 SP22 Patch 2 (64-bit) Device / Compiler-Version: 3.5.22.20 Das Kuriose:Das eigentliche Projekt läuft absolut einwandfrei. Mein Programmcode lässt sich ohne Probleme übersetzen, die SPS-Logik funktioniert fehlerfrei und auch die Simulation läuft einwandfrei durch. Nur das "Gesicht" des Projekts fehlt. Zwischendurch tauchte in den Meldungen der Fehler auf: Die Bibliothek '#System_VisuElems' konnte nicht aufgelöst werden. Was ich bereits zur Fehlerbehebung versucht habe: Installer-Check: Im CODESYS Installer geprüft, ob das Add-on "CODESYS Visualization" installiert ist (ist vorhanden und aktiv). Profil erzwungen: Im Visualisierungsmanager das Visualisierungsprofil manuell auf die aktuellste Version gesetzt. Gerät aktualisiert: Das Device im Projektbaum per Rechtsklick sauber auf die Version 3.5.22.20 hochgezogen. Clean Build: Mehrfach "Alles bereinigen" ausgeführt und neu übersetzt. Neues Projekt: Selbst wenn ich ein komplett neues Standardprojekt anlege, fehlen die Werkzeuge in der Visualisierung weiterhin. Hat jemand von euch eine Idee, woran das noch liegen könnte? Gibt es unter Windows eventuell einen versteckten Cache-Ordner für die Visualisierungs-Bibliotheken, den man manuell leeren muss? Für jeden Tipp wäre ich sehr dankbar! Viele Grüße
Last updated: 2026-06-15

Visualisierungswerkzeuge ^{CODESYS Forge talk (Thread)}
Visualisierungswerkzeuge
Last updated: 2026-06-15

Post by hezhikui on Codesys 3.5.21 fails to copy file to USB ^{CODESYS Forge talk (Post)}
Hi,Canplum,did you solved this problem?
Last updated: 2026-06-16

Automation Server 🇬🇧 ^{CODESYS Forge talk (Discussion)}
The Industry 4.0 administration platform for users and operators of CODESYS compatible controllers
Last updated: 2026-06-16

Using SCADA Data and C# Integration for Real-Time Production KPI Monitoring ^{CODESYS Forge talk (Thread)}
Using SCADA Data and C# Integration for Real-Time Production KPI Monitoring
Last updated: 2026-06-16

Codesys 3.5.21 fails to copy file to USB ^{CODESYS Forge talk (Thread)}
Codesys 3.5.21 fails to copy file to USB
Last updated: 2026-06-16

Post by hezhikui on Codesys 3.5.21 fails to copy file to USB ^{CODESYS Forge talk (Post)}
Hi,Canplum,did you solved this problem?
Last updated: 2026-06-16

XY Chart causes extremely long cycle in Visu Task ^{CODESYS Forge talk (Thread)}
XY Chart causes extremely long cycle in Visu Task
Last updated: 2026-06-16

Post by manuknecht on XY Chart causes extremely long cycle in Visu Task ^{CODESYS Forge talk (Post)}
I am using the visualization element "Cartesian XY Chart" in a visualization template within a library to display recorded position values. I managed to configure the chart as desired and it displays the values like it should. A problem occurs when clicking on the chart to move the cursor, zoom or pan. Upon clicking the visualization element for the first time, the task in which the visualization is run spikes to a cycle time of around 5'000 to 15'000 ms (the configured cycle time is 100 ms). Sometimes this even completely crashes the web-visualization. After this very long cycle, the visu task normalizes again and the chart can be interacted with as usual. Another spike in cycle time occurs once the visualization is switched to a frame that does not contain the chart. I did reduce the data array to only a few values and tried changing the update behaviour of the chart, but it did not change the problems I am facing. Did anyone experience a similar issue or even has a solution for this?
Last updated: 2026-06-16

TCP communication and TCP Streams ^{CODESYS Forge talk (Thread)}
TCP communication and TCP Streams
Last updated: 2026-06-16

Sort by relevance or date