Welcome to our new forum
All users of the legacy CODESYS Forums, please create a new account at account.codesys.com. But make sure to use the same E-Mail address as in the old Forum. Then your posts will be matched.
Close
We have the Codesys Control Win 64 runtime installed on several PC's which for a long time has berhaved pretty stable, especially considering that the system resources are shared with several other applications, which on the whole eat up the following resources, in extreme cases.
CPU / 3.4GHz (40-60%)
RAM / 8GB (80%-90%)
As we do not monitor these values in real time, we do not know if there are peaks beyond the above averages.
However, recently we have noticed the PLC runtime crashing, maybe due to a Windows scheduled task/upgrade, Defender, or even the fault of some of our applications. In most cases, a simple "Stop/Start PLC" is enough to restart the program, but in some cases, only restarting the PC solves the problem. In the worst cases, even the application is corrupted in such a way that it is necessary to re-upload the PLC program, as the engineering tool claims "there is no application inside".
So is there any guidance on that?
I would like to know what of these indicators are the most critical.
If possible, also would like to know the consequence of reaching their limits.
Regards,
Andre.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Andre,
could you check if the memory consumption is growing?
We have seen similar issues, when the whole memory is out - so memory leak or handle leak maybe could be the reason for this behavior.
Is webvisu up and running on the same machine - and if so - which browser do you use?
Check with taskmonitor - the memory and handle consumption of all running applications.
Sure could be cause by other applications too, beside CODESYS
I also thought alike, whenever RAM usage hold high, more frequent the incidence of PLC-getting-stuck. However, these days we had added another DDR memory card into PC mainboard, so that now it lies in the range of ~47% usage (16G) whereas before it was in the range of 80%-90% of 8G, but even after this hardware 'upgrade' in less than 24hs it was 2 occurrences.
Regarding Webvisu, it also face to the same issue, regardless of the browser we use (sometimes not even open). In order to check if it is up, I use the Realterm tool to open a TCP Socket connection to <localhost> port <8080> which indded do not open on these circumstances. </localhost>
BR,
Andre
Last edit: alrcastro 2021-11-23
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I fear that the root cause might be rather related to the Licencing schema. A time ago we got a committed assistance from Codesys support for over a week, which even forwarding the issue straight to Wibu-Systems, they could not assertively state the actual cause.
As posed at the above case, either the LOG and the DEBUG messages give indication of missing licence, although licence was properly activated there.
BR,
Andre
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
is it possible that you have situations where the networkinterfaces are unavailable?
2021-11-23T18:26:26.682Z, 0x0000007a, 4, 0, 0, **** ERROR: CM SDK: : can't create connection to codemeter server 127.0.0.1
you could install MS Loopback adapter to prevent this.
This is what I would recommend for such cases.
BR
Edwin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
in accordance with your tips, the MS Loopback connector was installed, as can be seen attached; however, after a couple of hours, I'd noticed the PLC getting innactive at the output, and no TCP connection to the Webvisu 127.0.0.1:8080, so once again the program got stuck.
By checking the CODESYS Control Win V3 - x64.log content, I could notice the same pattern, the following sentence even with the loopback connector there:
*CODESYS Control Service: Warning: DEMO mode activated, terminating in approx. 120 minutes.*
Am I missing something ?
11/23/21 09:52:31: --------------------------------------------------------------------------11/23/21 09:52:31: CODESYS Control Win V3 - x64 Service started11/23/21 09:52:31: Config file:11/23/21 09:52:31: C:\ProgramData\CODESYS\CODESYSControlWinV3x64\E76864C4\CODESYSControl.cfg11/23/21 09:53:28: CODESYS Control Win V3 - x64 Service stopped11/23/21 09:53:33: --------------------------------------------------------------------------11/23/21 09:53:33: CODESYS Control Win V3 - x64 Service started11/23/21 09:53:33: Config file:11/23/21 09:53:33: C:\ProgramData\CODESYS\CODESYSControlWinV3x64\E76864C4\CODESYSControl.cfg11/23/21 15:22:48: CODESYS Control Win V3 - x64 Service stopped11/23/21 15:22:52: --------------------------------------------------------------------------11/23/21 15:22:52: CODESYS Control Win V3 - x64 Service started11/23/21 15:22:52: Config file:11/23/21 15:22:52: C:\ProgramData\CODESYS\CODESYSControlWinV3x64\E76864C4\CODESYSControl.cfg11/23/21 15:22:53: CODESYS Control Service: Warning: DEMO mode activated, terminating in approx. 120 minutes.11/23/21 15:25:01: CODESYS Control Win V3 - x64 Service stopped11/23/21 15:25:07: --------------------------------------------------------------------------11/23/21 15:25:07: CODESYS Control Win V3 - x64 Service started11/23/21 15:25:07: Config file:11/23/21 15:25:07: C:\ProgramData\CODESYS\CODESYSControlWinV3x64\E76864C4\CODESYSControl.cfg11/23/21 15:25:16: CODESYS Control Service: Warning: DEMO mode activated, terminating in approx. 120 minutes.11/23/21 15:26:22: CODESYS Control Win V3 - x64 Service stopped11/23/21 15:26:26: --------------------------------------------------------------------------11/23/21 15:26:26: CODESYS Control Win V3 - x64 Service started11/23/21 15:26:26: Config file:11/23/21 15:26:26: C:\ProgramData\CODESYS\CODESYSControlWinV3x64\E76864C4\CODESYSControl.cfg11/23/21 15:26:27: CODESYS Control Service: Warning: DEMO mode activated, terminating in approx. 120 minutes.11/23/21 15:28:36: CODESYS Control Win V3 - x64 Service stopped11/23/21 15:28:39: --------------------------------------------------------------------------11/23/21 15:28:39: CODESYS Control Win V3 - x64 Service started11/23/21 15:28:39: Config file:11/23/21 15:28:39: C:\ProgramData\CODESYS\CODESYSControlWinV3x64\E76864C4\CODESYSControl.cfg11/23/21 23:07:34: --------------------------------------------------------------------------11/23/21 23:07:34: CODESYS Control Win V3 - x64 Service started11/23/21 23:07:34: Config file:11/23/21 23:07:34: C:\ProgramData\CODESYS\CODESYSControlWinV3x64\E76864C4\CODESYSControl.cfg11/23/21 23:07:37: CODESYS Control Service: Warning: DEMO mode activated, terminating in approx. 120 minutes.11/23/21 23:12:03: *** Shutdown command from service control manager received...11/23/21 23:12:04: CODESYS Control Win V3 - x64 Service stopped11/23/21 23:13:51: --------------------------------------------------------------------------11/23/21 23:13:51: CODESYS Control Win V3 - x64 Service started11/23/21 23:13:51: Config file:11/23/21 23:13:51: C:\ProgramData\CODESYS\CODESYSControlWinV3x64\E76864C4\CODESYSControl.cfg11/24/21 22:58:19: CODESYS Control Win V3 - x64 Service stopped11/24/21 22:58:26: --------------------------------------------------------------------------11/24/21 22:58:26: CODESYS Control Win V3 - x64 Service started11/24/21 22:58:26: Config file:11/24/21 22:58:26: C:\ProgramData\CODESYS\CODESYSControlWinV3x64\E76864C4\CODESYSControl.cfg11/24/21 22:58:27: CODESYS Control Service: Warning: DEMO mode activated, terminating in approx. 120 minutes.11/24/21 23:01:04: CODESYS Control Win V3 - x64 Service stopped11/24/21 23:01:10: --------------------------------------------------------------------------11/24/21 23:01:10: CODESYS Control Win V3 - x64 Service started11/24/21 23:01:10: Config file:11/24/21 23:01:10: C:\ProgramData\CODESYS\CODESYSControlWinV3x64\E76864C4\CODESYSControl.cfg11/24/21 23:02:04: *** Shutdown command from service control manager received...11/24/21 23:02:05: CODESYS Control Win V3 - x64 Service stopped11/24/21 23:03:49: --------------------------------------------------------------------------11/24/21 23:03:49: CODESYS Control Win V3 - x64 Service started11/24/21 23:03:49: Config file:11/24/21 23:03:49: C:\ProgramData\CODESYS\CODESYSControlWinV3x64\E76864C4\CODESYSControl.cfg
we need the Plclog.csv.. for this situation.
If this happens check:
1. Is there a coredump available in the /PlcLogic/Applications/ directroy (Application.core)
2. avaiable memory in this situation / cpu load?
BR
Edwin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for your patience.
As per the above points:
I could find an occurrence of a coredump at the file Application.core file as an <cmp>CmpCoreDump</cmp> entry, but I'm unable to understand what this mean. Unfortunatelly there is no timestamp close to this text so that I could determine any relation with the stuck issue.
In fact, I cannot check the system resources in realtime, just the average at a glance from time to time, and now that we added another SSD card, MEM lies in the range of 40% and CPU do not exceed 30%, eventually (actually, rarelly) reaching a peak of 50%.
Just out of curiosity, I added the dwCycleTime variable of the CmpIecTask.Task_Info2 to the Webvisu, in order to take the last task execution cycle time of each one of the IEC tasks, running cyclically, and sometimes (quite rare) I can find it reaching the 1,000 us limit defined on the Task configuration in the range of 5-10% at most. In other PCs it doesnt happens so often even running the "same" application with the same OS and H/W, but since this is not too frequent, I presume this by itself is not the root of the problem, although worthy to mention.
Anyway, back to the coredump approach, could you give a tip of what could I infer from what was found above ?
BR,
ANDRE.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The above link redirects to this thread, is it the intent ?
I can't see here where is the answer to the question posed before:
I could find an occurrence of a coredump word at the file Application.core file as an <cmp>CmpCoreDump</cmp> entry, but I'm unable to understand what this mean.
Last edit: alrcastro 2021-11-26
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
We have the Codesys Control Win 64 runtime installed on several PC's which for a long time has berhaved pretty stable, especially considering that the system resources are shared with several other applications, which on the whole eat up the following resources, in extreme cases.
CPU / 3.4GHz (40-60%)
RAM / 8GB (80%-90%)
As we do not monitor these values in real time, we do not know if there are peaks beyond the above averages.
However, recently we have noticed the PLC runtime crashing, maybe due to a Windows scheduled task/upgrade, Defender, or even the fault of some of our applications. In most cases, a simple "Stop/Start PLC" is enough to restart the program, but in some cases, only restarting the PC solves the problem. In the worst cases, even the application is corrupted in such a way that it is necessary to re-upload the PLC program, as the engineering tool claims "there is no application inside".
So is there any guidance on that?
I would like to know what of these indicators are the most critical.
If possible, also would like to know the consequence of reaching their limits.
Regards,
Andre.
more posts ...
Hi Andre,
I would start with this:
first you need to extend the plc logger and enable
that the log - will be written in a file:
c:\ProgramData\CODESYS\CODESYSControlWinV3x64\XXXXXXX\CODESYSControl.cfg
[CmpLog]
Logger.0.Name=PlcLog
;Logger.0.Filter=0xFFFFFFFF
Logger.0.Enable=1
Logger.0.MaxEntries=500000
Logger.0.MaxFileSize=500000
Logger.0.MaxFiles=3
Logger.0.Backend.0.ClassId=0x0000010B ;sends logger messages to SysOut
Logger.0.Backend.1.ClassId=0x00000104 ;writes logger messages in a file
If this happens again, check PlcLog.csv for more information for the error cause.
Best Regards
Edwin
Last edit: eschwellinger 2021-11-23
Hi Edwin,
These are either the LOG and CSV files. Seems like there is an issue with the licence acknowledgement, although we DO have all PC's properly licenced.
What to do ?
LOG
CSV
Last edit: alrcastro 2021-11-24
is this running on an real machine or vitual machine?
a real one, Windows 10, i5, DELL optiplex 7070
I'd attached the whole CSV file.
Just changed the HOST name and IP, for security sake.
Att.
Last edit: alrcastro 2021-11-23
Hi Andre,
could you check if the memory consumption is growing?
We have seen similar issues, when the whole memory is out - so memory leak or handle leak maybe could be the reason for this behavior.
Is webvisu up and running on the same machine - and if so - which browser do you use?
Check with taskmonitor - the memory and handle consumption of all running applications.
Sure could be cause by other applications too, beside CODESYS
Last edit: eschwellinger 2021-11-23
Hi Edwin,
I also thought alike, whenever RAM usage hold high, more frequent the incidence of PLC-getting-stuck. However, these days we had added another DDR memory card into PC mainboard, so that now it lies in the range of ~47% usage (16G) whereas before it was in the range of 80%-90% of 8G, but even after this hardware 'upgrade' in less than 24hs it was 2 occurrences.
Regarding Webvisu, it also face to the same issue, regardless of the browser we use (sometimes not even open). In order to check if it is up, I use the Realterm tool to open a TCP Socket connection to <localhost> port <8080> which indded do not open on these circumstances. </localhost>
BR,
Andre
Last edit: alrcastro 2021-11-23
Hi Edwin,
I fear that the root cause might be rather related to the Licencing schema. A time ago we got a committed assistance from Codesys support for over a week, which even forwarding the issue straight to Wibu-Systems, they could not assertively state the actual cause.
As posed at the above case, either the LOG and the DEBUG messages give indication of missing licence, although licence was properly activated there.
BR,
Andre
Hi Andre,
is it possible that you have situations where the networkinterfaces are unavailable?
2021-11-23T18:26:26.682Z, 0x0000007a, 4, 0, 0, **** ERROR: CM SDK: : can't create connection to codemeter server 127.0.0.1
you could install MS Loopback adapter to prevent this.
This is what I would recommend for such cases.
BR
Edwin
Interesting, never heard about that loopback.
[Added]
I've just installed, and I presume I need to define [IP Address] as 127.0.0.1 (I did it) but what about [gateway] and [mask] ?
Thanks a lot.
Last edit: alrcastro 2021-11-24
just install the loopback that's it
Hi Edwin,
in accordance with your tips, the MS Loopback connector was installed, as can be seen attached; however, after a couple of hours, I'd noticed the PLC getting innactive at the output, and no TCP connection to the Webvisu 127.0.0.1:8080, so once again the program got stuck.
By checking the CODESYS Control Win V3 - x64.log content, I could notice the same pattern, the following sentence even with the loopback connector there:
*CODESYS Control Service: Warning: DEMO mode activated, terminating in approx. 120 minutes.*Am I missing something ?
Last edit: alrcastro 2021-11-25
we need the Plclog.csv.. for this situation.
If this happens check:
1. Is there a coredump available in the /PlcLogic/Applications/ directroy (Application.core)
2. avaiable memory in this situation / cpu load?
BR
Edwin
Hi Edwin,
Thank you for your patience.
As per the above points:
Just out of curiosity, I added the dwCycleTime variable of the CmpIecTask.Task_Info2 to the Webvisu, in order to take the last task execution cycle time of each one of the IEC tasks, running cyclically, and sometimes (quite rare) I can find it reaching the 1,000 us limit defined on the Task configuration in the range of 5-10% at most. In other PCs it doesnt happens so often even running the "same" application with the same OS and H/W, but since this is not too frequent, I presume this by itself is not the root of the problem, although worthy to mention.
Anyway, back to the coredump approach, could you give a tip of what could I infer from what was found above ?
BR,
ANDRE.
Hi Edwin,
Could you give some feedback on this ?
BR,
Last edit: alrcastro 2021-11-26
start here:
https://forge.codesys.com/forge/talk/Runtime/thread/eafcb96918/
should be a link to the onlinehelp.
have no computer in my hands
Last edit: eschwellinger 2021-11-27
The above link redirects to this thread, is it the intent ?
I can't see here where is the answer to the question posed before:
Last edit: alrcastro 2021-11-26
sorry for this:
here the link
https://help.codesys.com/webapp/_cds_using_core_dump;product=codesys;version=3.5.17.0
Last edit: eschwellinger 2021-11-27
Many thanks again for your kind help.