I wonder if anyone has encountered the PLC reboot to service mode due to an OS Task named anslSvTcpRecv. This issue has happened in my work for 2 - 3 times for the past year, it’s very sporadic so I can’t find a way to reproduce it. Logger screenshot below, system dump enclosed.
Since it’s ANSL related, one possible cause that I will suspect is the ping time via our VPN can be more than 500ms. I wonder if ANSL has any problem with slow ping time and high data volume (if you regard using the AS Monitor function high data volume…). Apart from this, I can’t see much correlation between the issues that I had.
I have seen this error before and it was associated with a memory smear in the application. Please check your application for field overflows or memory violations.
you can add the IECcheck library to the project and then compile your project with a rebuild all. You may get more entries in the logger. IECcheck only works if you have programmed in IEC language.
It rings a bell that the current code does contain some mistakes in terms of pointer usage. Specifically, a few MpRecipe items are using identical MpLinks in different application modules. Automation Studio will complain about it if you do this manually but somehow this got through, maybe because whoever did it copied and pasted the whole AM so AS didn’t have a chance to complain.
Since the MpRecipe and ANSL communication both run in idle task, maybe this causes issue?
BTW, I have seen this IEC check library before but can’t find enough information about how to properly use it. My understanding is you have to call this check library before your suspected cause of error. With things like ANSL, in which part of the program can you call it?
The trickiest part is we can’t find a way to trigger the page fault. However, this article is helpful and probably we can temporarily put it in the PLCs in production for some time and wait for the page fault. It may help us understand what’s happened.