I have an application with several tasks that utilizes the SysTimeRtc* family of functions. The initial problem I encountered was that the SysTimeRtcConvertHighResToLocal function would not properly convert the UTC time to local time. The converted time that was being returned was always for the UTC time zone.
During the debugging process I discovered that the SysTimeRtcGetTimezone function was returning the timezone as UTC even though the PLC was properly configured with the appropriate time zone.
Digging further, I narrowed the issue down to the runtime somehow getting corrupted when multiple tasks call the SysTimeRtc* functions concurrently. Specifically, calling SysTimeRtcGetTimezone from multiple tasks causes the runtime to raise an AccessViolation exception.
Once corrupted, the runtime needs to be restarted. No issues with UTC to local timezone conversations are encountered with only one task using the functions.
My question is whether or not the SysTimeRtc* functions are expected to be reentrant and if not is there documentation specifying which functions are or are not thread-safe.
Thanks
Vic
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Vic
seems like we are facing a similar problem using the SysTimeRtcGetTimezone function in multiple tasks, resulting in access violations. Did you solve it?
Thanks
Lennart
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi, I have very similar issue on Wago PFC200 (750-8212 and 750-8202).
I using directly only one thread. But I think that same 'internal processes' are also using this function. For example I've started to have 'access violation' when I added 'Trend recording' - it's working in another thread.
As workaround I can use Wago library, but it is not optimal/universal resolution. I always try to write 'vendor-independent' code as much as possible.
Maybe someone can check it on 'clear codesys' with codesys runtime.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
On any preemptive multitasking system you will still have a race condition unless the operation of getting the data is an atomic operation. So you still end up with a need to address this race condition.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Good afternoon
I have an application with several tasks that utilizes the SysTimeRtc* family of functions. The initial problem I encountered was that the SysTimeRtcConvertHighResToLocal function would not properly convert the UTC time to local time. The converted time that was being returned was always for the UTC time zone.
During the debugging process I discovered that the SysTimeRtcGetTimezone function was returning the timezone as UTC even though the PLC was properly configured with the appropriate time zone.
Digging further, I narrowed the issue down to the runtime somehow getting corrupted when multiple tasks call the SysTimeRtc* functions concurrently. Specifically, calling SysTimeRtcGetTimezone from multiple tasks causes the runtime to raise an AccessViolation exception.
Once corrupted, the runtime needs to be restarted. No issues with UTC to local timezone conversations are encountered with only one task using the functions.
My question is whether or not the SysTimeRtc* functions are expected to be reentrant and if not is there documentation specifying which functions are or are not thread-safe.
Thanks
Vic
Hi Vic
seems like we are facing a similar problem using the SysTimeRtcGetTimezone function in multiple tasks, resulting in access violations. Did you solve it?
Thanks
Lennart
If I remember correctly, I wrapped the methods and put a giant lock/semaphore around the system calls.
Hi, I have very similar issue on Wago PFC200 (750-8212 and 750-8202).
I using directly only one thread. But I think that same 'internal processes' are also using this function. For example I've started to have 'access violation' when I added 'Trend recording' - it's working in another thread.
As workaround I can use Wago library, but it is not optimal/universal resolution. I always try to write 'vendor-independent' code as much as possible.
Maybe someone can check it on 'clear codesys' with codesys runtime.
why not run this function only once in the most highest prio (or fastest) task and share the outcome via a global var.
On any preemptive multitasking system you will still have a race condition unless the operation of getting the data is an atomic operation. So you still end up with a need to address this race condition.