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 timvh on Detect "Cancel" Press in FileOpenSave Dialog ^{CODESYS Forge talk (Post)}
Maybe there is a better way, but a long time ago I created a test application that worked like this: With a button I opened the dialog and I added a "Input configuration - OnDialogClosed" "Execute ST-Code" action to this same button which called the following Function when the dialog was closed: F_OnFileDialogClosed(pClientData); Below this Function which handled the result: // This function is called from the visualization when the dialog is closed. FUNCTION F_OnFileDialogClosed : BOOL VAR_INPUT pClientData : POINTER TO VisuElems.VisuStructClientData; END_VAR VAR dialogMan : VisuElems.IDialogManager; FileOpenCloseDialog : VisuElems.IVisualisationDialog; result : VisuElems.Visu_DialogResult; _sFileName : STRING(255); END_VAR // the DialogManager is provided via the implicitly available VisuManager dialogMan := VisuElems.g_VisuManager.GetDialogManager(); IF dialogMan <> 0 AND pClientData <> 0 THEN FileOpenCloseDialog := dialogMan.GetDialog('VisuDialogs.FileOpenSave'); // gets the FileOpenSave dialog IF FileOpenCloseDialog <> 0 THEN result := FileOpenCloseDialog.GetResult(); // gets the result (OK, Cancel) of the dialog IF result = VisuElems.Visu_DialogResult.OK THEN // Original code gvlFile.FileListProvider(); _sFileName := CONCAT(gvlFile.FileListProvider._stDirectory, gvlFile.FileListProvider.stFile); // do something with this file name... END_IF END_IF END_IF
Last updated: 2023-09-19

Post by sturmghost on Initialization of visualization variables and cyclic code execution ^{CODESYS Forge talk (Post)}
I'm looking for a smart and short way to implement initialization of visualization variables depending on the visualization input. For an easy example consider a rectangle which rests at XPos := 0 when the input state is false and at XPos := 50 when the input state is true. My visualization variables look like this: VAR_IN_OUT State : BOOL; END_VAR VAR XPos : INT; END_VAR I put this rectangle via a visualization frame element into another visualization and link a frame reference variable with the state to it. If the variable is true, the rectangle should rest at XPos := 50 and false at XPos := 0 at visualization init but how should I assign the 50 or 0 to the internal visualization variable XPos? I would need some init-methode for the visualization but I dont want a global init-method for such tasks. I want to do it inside of the visualization element but I can't see any solution for this? It would be good to be able to define ST-code within the visualization element which runs cyclic at each VISU_TASK task-cycle then I could just check the input state and change the XPos accordingly. Does someone have a solution?
Last updated: 2023-10-01

Post by denkihitsuji on Content update through Data URI on Web Brower on Visualization Toolbox ^{CODESYS Forge talk (Post)}
Objective: I want to dynamically update the content with strings and JPEG images received from a TCP/IP socket. For this purpose, I am exploring the possibility of utilizing the Web Browser feature of the Visualization toolbox. Example: In a standard web browser, entering data:text/plain;charset=utf-8;base64,SGVsbG8gc3RyYW5nZXI= in the URL window will display "Hello stranger" on the webpage. Issue: When attempting to use this method in the Web Browser of the Visualization toolbox, the content does not display as expected. Instead, it shows the error:'Navigation to the webpage was canceled.'. Request: I seek guidance on how to resolve this issue so that the Web Browser in the Visualization toolbox correctly interprets and displays the data URI content. Alternative Solution Welcomed: Or, if it is possible to directly use Codesys Structured Text (ST) variables within an HTML page, this approach would also meet my requirements. Thank you for your attention.
Last updated: 2024-07-30

Post by breiter on Frustration-Fueled Feedback on Project File Management and Git Integration ^{CODESYS Forge talk (Post)}
Hi, supporting a text based storage format is on our roadmap, see https://www.codesys.com/the-system/releases-updates-lifecycle/release-plan-roadmap.html It will be an Add-On feature called "File Based Storage" for the professional developer edition. Structured text POUs will be stored as plain text. Other graphical languages will remain in an xml format. You will be able to switch the storage type for projects. Certain workflows will become easier this way. Nevertheless restrictions will remain because of CODESYS specific storage logic (for example how methods below function blocks are stored as file). So merging using our Git Integration Add-On remains the recommended workflow. A workflow involving Visual Studio Code as the main IDE is not supported. Simply because many topics like library management, task configuration or fieldbus configurators are not available for VS Code. A PLC project is a lot more than just some ST POUs. Best Regards
Last updated: 2024-10-16

Post by kevinrn on CODESYS Development System V3 installation auf unter Parallells Windows 11auf MAC PRO M1 ARM Prozessor ^{CODESYS Forge talk (Post)}
Hallo, das Thema ist ja etwas offtopic. Aber ich kann gerne mal von meiner Erfahrung berichten: Nachdem ich von 2020 bis 2023 immer einen MacBook Pro mit Intel CPU hatte (i9/32GB) und nun seit Januar 2024 mit dem M3 Max unterwegs bin kann ich Nachfolgendes berichten. Infos zu den Aufgaben, die ich damit erledige: Die Runtime nutze ich nicht auf dem Mac (Wenn ich von Mac rede, dann meine ich damit die Win11 ARM64 Parallels Umgebung) Ich nutze die IDE für Library development und für automatisierungs Tests von CI/CD jobs. Weiterhin öffne ich oft große Projektarchive mit teilweise 160 MB. Erfahrungen zur Installation von CODESYS Versionen: Ich habe einige Versionen installiert, unter anderem, 3.5.14.4, 3.5.17.2, 3.5.16.3, 3.5.18.4 und 3.5.19.6. Ich hatte mit keiner einizgen Installation ein Problem. Die Installation lief immer ohne Probleme durch. Runtimes (Control Win) installiere ich nicht. Ich nutze linux basierte Zielsysteme und bei bedarf eine Windows VM auf einen entfernen Host mit X64. Lokales Gateway läuft ebenso Sonstige Erfahrungen: Ich nutze viele Komponenten Querbeet: Alarming, AC Persistence, Symbol Konfiguration, CFC und ST Editor, externes Packages wie STWeep, Git für Library Entwicklung, Visu, etc. Mit keiner dieser "Komponenten" hatte ich schwierigkeiten oder einen Unterschied zu x64 systemen festgestellt. Man muss aber auch sagen, dass das alles nur ein kleiner Bruchteil ist, was die CODESYS Welt beinhaltet, deshalb sind diese Aussagen auch nur subjektiv aus meinem Erfahrungsbereich. Für das Entwickeln von Libraries sehe ich keine Performance Einschränkungen. Ganz im Gegenteil, für das, dass hier eine emulation stattfindet, ist es erstaunlich schnell. Meiner Meinung nach sind sogar einfache und kleine Projekte schneller als beim Intel Mac. Die Akku Leistung mit dem Mac und Parallels ist fantastisch. Lüfter hört man nicht mal bei der Nutzung von CODESYS. Beim Intel konnte ich sonst ein Spiegelei auf der Abdeckung zubereiten... Was evtl. etwas langsamer ist bzw. mir manchmal so vor kommt ist, der CFC Editor im Online Mode. Aber hierzu fehlt mir ein richtiger Vergleich. Fazit: Ich bin selbst erstaunt wie gut die CODESYS IDE auf einem ARM64 emuliert wird. Ich muss aber auch sagen, dass ich jederzeit eine x64 Workspace zur Verfügung habe, falls was nicht funktionieren sollte. Das habe ich mir extra zum Umstieg zu gelegt. Bisher habe ich es jedoch noch nie benötigt, da meine Anforderungen alle erfüllt werden. Es sollte einem aber bewusst sein, dass dies keine supportete Umgebung ist und man auch bei spezifischen Problemen keinen Support erwarten sollte. Ich nutze CODESYS ca. 4-12 Stunden die Woche und ich warte immer noch auf etwas, um meine X64 Cloud Workspace mal zu verwenden... Vielleicht hilft dir dies ja etwas bei der Entscheidung.
Last updated: 2024-03-21

Sort by relevance or date