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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
đź‘Ť
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In reality, other vendors are already moving towards integration with VS Code. B&R, for example, is likely the only one that could truly challenge Codesys in the market: they’ve overhauled their once-archaic environment (previously lacking ST OOP) and are now catching up significantly with Automation Studio Code, offering modern programming capabilities and native support for tools like Git and GitHub Copilot.
The other big names in the market, frankly, are still light years behind.
For smaller projects, typically handled by “wire strippers” (with all due respect!), a classic environment might be just fine. But once you’re dealing with thousands or even millions of lines of code—possibly organized in an OOP paradigm, spanning large teams, integrating third-party libraries, requiring version control, and performing comprehensive tests—a lightweight, responsive editor supercharged with AI-based features becomes essential.
The real strength of something like VS Code lies in its vast ecosystem of extensions and integrations: from advanced Git support to automated build/test pipelines, and even AI-assisted autocompletion that already makes software development much more agile and productive.
I understand that a PLC project involves more than just ST code (task setup, fieldbus configuration, libraries, etc.). However, there’s no technical reason not to at least provide ST files in a pure text format, making version control and collaboration far easier. B&R has clearly adopted this approach; I hope Codesys will accelerate its own efforts to offer a native, text-based integration and modern development tooling.
Once you go beyond a certain level of complexity—dozens of configurations, OOP hierarchies, and distributed teams—you really do need “engineer-level” software tools, not just solutions targeting “wire strippers.” For large-scale automation projects, a more open and flexible approach is the only way to avoid chronic frustration.
Let me emphasize that I truly love Codesys and consider the work done so far to be brilliant—I’d be sorry to see it overshadowed by others moving faster in this direction.
đź‘Ť
2
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Some developers export ST code manually and edit it in VSCode, then copy it back. However, a more practical approach might be using automation scripts (PowerShell, Python) to extract and inject code into the CODESYS project. You could also check if CODESYS Automation Server or CODESYS API allows better ST access for external tools. https://www.codesys.com/the-system/releases-updates-lifecycle/release-plan-roadmap.htmlGeometry Dash Lite
Network drive issues are particularly painful. As a mitigation, you could try using local project storage with periodic cloud sync instead of directly saving to a network drive. Using Rsync or Syncthing for automatic but safe synchronization might reduce risks of file corruption.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Fantastic blog. Reading your articles was enjoyable. For me, this was a really enjoyable book. I have it bookmarked and am eager to read more things from it run 3. Continue your wonderful effort!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
more posts ...
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
In reality, other vendors are already moving towards integration with VS Code. B&R, for example, is likely the only one that could truly challenge Codesys in the market: they’ve overhauled their once-archaic environment (previously lacking ST OOP) and are now catching up significantly with Automation Studio Code, offering modern programming capabilities and native support for tools like Git and GitHub Copilot.
The other big names in the market, frankly, are still light years behind.
For smaller projects, typically handled by “wire strippers” (with all due respect!), a classic environment might be just fine. But once you’re dealing with thousands or even millions of lines of code—possibly organized in an OOP paradigm, spanning large teams, integrating third-party libraries, requiring version control, and performing comprehensive tests—a lightweight, responsive editor supercharged with AI-based features becomes essential.
The real strength of something like VS Code lies in its vast ecosystem of extensions and integrations: from advanced Git support to automated build/test pipelines, and even AI-assisted autocompletion that already makes software development much more agile and productive.
I understand that a PLC project involves more than just ST code (task setup, fieldbus configuration, libraries, etc.). However, there’s no technical reason not to at least provide ST files in a pure text format, making version control and collaboration far easier. B&R has clearly adopted this approach; I hope Codesys will accelerate its own efforts to offer a native, text-based integration and modern development tooling.
Once you go beyond a certain level of complexity—dozens of configurations, OOP hierarchies, and distributed teams—you really do need “engineer-level” software tools, not just solutions targeting “wire strippers.” For large-scale automation projects, a more open and flexible approach is the only way to avoid chronic frustration.
Let me emphasize that I truly love Codesys and consider the work done so far to be brilliant—I’d be sorry to see it overshadowed by others moving faster in this direction.
Some developers export ST code manually and edit it in VSCode, then copy it back. However, a more practical approach might be using automation scripts (PowerShell, Python) to extract and inject code into the CODESYS project. You could also check if CODESYS Automation Server or CODESYS API allows better ST access for external tools.
https://www.codesys.com/the-system/releases-updates-lifecycle/release-plan-roadmap.html Geometry Dash Lite
Network drive issues are particularly painful. As a mitigation, you could try using local project storage with periodic cloud sync instead of directly saving to a network drive. Using Rsync or Syncthing for automatic but safe synchronization might reduce risks of file corruption.
Fantastic blog. Reading your articles was enjoyable. For me, this was a really enjoyable book. I have it bookmarked and am eager to read more things from it run 3. Continue your wonderful effort!