Before creating this topic, I was browsing the search results for CodesysControl.cfg - many results, and I remember very well, it's a problematic issue for a long time.
To summarize: there were many requests for documentation on this file - the most comprehensive reply is:
Hi,
not really, this is covered by the manual which you get if you use a runtime toolkit which is not free of charge.
Maybe we need to extract the config file part from that documentation if that is possible.
BR
Edwin
I am not sure how much is this relevant, since we buy SL License directly from CODESYS... I think it is a reasonable demand, to get documentation on the configuration entries affecting the documented behaviour of the runtime system and it's components
The actual reason I bring up this issue again can be read here:
but mostly my frustration about noticing some new, unknown and undocumented entries in my configuration file. Again. And this happens a lot recently.
Just some examples:
Changes with SysFile - and mandatory use of IEC path
Introduction of Mandatory user management
File transfer service now disabled by default
SysProcess - allowed commands
The above mentioned CmpApp parameters...
And finally (Regaridng windows install):
With the newer versions, the installation directory (together with the configuration file) tends to hide itself to some super silly location under the roaming profile data of local system account. I am not sure if this change was documented somewhere, but was a very unpleasant one. Someone could please explain the reason and the concept of the introduction of this release specific directories (I am sure, there is a good reason)
- how to use them properly?
- How to re-introduce user configuration (to preserve configuration data between versions)?
- How to do version - to version migrations properly?
- How to keep old version of runtime available and ready to start with it's original configuration and application?
- ...
Therefore, the lack a regularly updated description of CodesysControl .cfg , including all the configuration entries, together with their default values for different runtime versions is really a big deficiency.* This should be done for all components storing or just seeking data from this file...
(Maybe there is such thing but I failed to find???)
It is regularly causing trouble when introducing a new version (together with the long awaited bug fixes and enhancements), what has changed it's default behaviour for security or other practical reasons. I agree this is very important, and it is logical to change the default options: But it must be documented historically, and make it easily available, so we can prepare better for the upgrade of the runtime.
Forge talk is a great source, but not very practical for this kind of documentation purposes...
Thanks in advance for CODESYS staff 🙏🙏🙏
(Ps.: It would look rather silly, if some members of the user community prepares this documentation on a Forge Wiki page... Or??? Should we?)
👍
2
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
👍
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Before creating this topic, I was browsing the search results for CodesysControl.cfg - many results, and I remember very well, it's a problematic issue for a long time.
To summarize: there were many requests for documentation on this file - the most comprehensive reply is:
https://forge.codesys.com/forge/talk/Runtime/thread/ebbf851a3d/#eb85
I am not sure how much is this relevant, since we buy SL License directly from CODESYS... I think it is a reasonable demand, to get documentation on the configuration entries affecting the documented behaviour of the runtime system and it's components
The actual reason I bring up this issue again can be read here:
https://forge.codesys.com/forge/talk/Runtime/thread/febad3cc40/#0e12
but mostly my frustration about noticing some new, unknown and undocumented entries in my configuration file. Again. And this happens a lot recently.
Just some examples:
And finally (Regaridng windows install):
With the newer versions, the installation directory (together with the configuration file) tends to hide itself to some super silly location under the roaming profile data of local system account. I am not sure if this change was documented somewhere, but was a very unpleasant one. Someone could please explain the reason and the concept of the introduction of this release specific directories (I am sure, there is a good reason)
- how to use them properly?
- How to re-introduce user configuration (to preserve configuration data between versions)?
- How to do version - to version migrations properly?
- How to keep old version of runtime available and ready to start with it's original configuration and application?
- ...
Therefore, the lack a regularly updated description of CodesysControl .cfg , including all the configuration entries, together with their default values for different runtime versions is really a big deficiency.* This should be done for all components storing or just seeking data from this file...
(Maybe there is such thing but I failed to find???)
It is regularly causing trouble when introducing a new version (together with the long awaited bug fixes and enhancements), what has changed it's default behaviour for security or other practical reasons. I agree this is very important, and it is logical to change the default options: But it must be documented historically, and make it easily available, so we can prepare better for the upgrade of the runtime.
Forge talk is a great source, but not very practical for this kind of documentation purposes...
Thanks in advance for CODESYS staff 🙏🙏🙏
(Ps.: It would look rather silly, if some members of the user community prepares this documentation on a Forge Wiki page... Or??? Should we?)
more posts ...
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
__vfinitand 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.
Agree!
Me and my customers are buying SL Licences from the store but we don't get proper documentation of the runtime!
Only a few hints of the entries in CodesysControl.cfg are spread all over the Internet.