Codesys SysTimeRtcConvertHighResToLocal unexpected behaviour

AlfredoQuintero · Apr 14, 2020

Hello Codesys wizards, once again a cry for help from this mind with limited understanding of Codesys.
I have almost completed an application that gathers data from a number of sources. I chose Codesys to handle data storing event handling and a middleware for handling the communication with the PLCs which are the data sources. This middleware and Codesys exchange data through OPC interface and this part is working fine.

My problem is the time stamp for the data I am storing is calculated with the function SysTimeRtcConvertHighResToLocal. I got this working a few days ago and I have just realized that this function is getting the day of the month incorrectly until 08:59:59, and correctly from 09:00:00.

It sounds as though I am doing something wrong, so I have taken the screenshot below showing the program, the actual system time and an extract of yesterday's data, in the hope that a kind and more learned PLCTALK.NET colleague can illuminate my way out of this dark tunnel.

Ken Roach · Apr 15, 2020

To clarify that we're looking at the issue the same way: Japan is "Greenwich + 9 hours", right ? So the general guess is that the CoDeSys function is basing its Day of Month on what day it is at "Zulu Time" / "Greenwich Mean Time", not what day it is in Japan.

Is that function part of the "Date and Time" library ?

https://store.codesys.com/date-and-time.html

It makes sense to me that you're getting a UTC timestamp, then converting it to local time... and that the conversion function simply gets the day wrong, even though it gets the local hour correct.

Now that we've got the obvious stuff out of the way... can you subtract from that raw timestamp to let the function get the Date right, then use the raw timestamp to get the hour ? You would run SysTimeRtcConvertHighResToLocal twice.

I'm going to see if I can get that running on a CoDeSys instance here on the US West Coast (UCT -8) and see what it tells me.

Edit: CoDeSys crashed promptly just trying to install the library package for Date-and-Time. I'll give it another shot.

AlfredoQuintero · Apr 15, 2020

Ken Roach said:
Is that function part of the "Date and Time" library ?

https://store.codesys.com/date-and-time.html

Hello Ken: Thanks so much for this gudance. Much appreciated.

Here is how I am declaring my variables:

stdNow : SysTimeRtc.SysTimeDate;
stUTC_Timestamp : SysTimeRtc.SysTime;

So I think, yes, they are from the library in the example that you are showing me in the link on your message.

Ken Roach said:
Now that we've got the obvious stuff out of the way... can you subtract from that raw timestamp to let the function get the Date right, then use the raw timestamp to get the hour ? You would run SysTimeRtcConvertHighResToLocal twice.

I am not sure I can follow you. You ask me "Can you substract from that..." but I have an "English as a second language" problem so I do not get what is it I have to substract.

By the way, at this moment the day of the month is shown properly, because from 09:00 the day becomes the current day. So anything I do I would need to wait until midnight or early tomorrow morning to test it.

Lare · Apr 15, 2020

AlfredoQuintero said:
Hello Ken: Thanks so much for this gudance. Much appreciated.

Here is how I am declaring my variables:

stdNow : SysTimeRtc.SysTimeDate;
stUTC_Timestamp : SysTimeRtc.SysTime;

So I think, yes, they are from the library in the example that you are showing me in the link on your message.

I am not sure I can follow you. You ask me "Can you substract from that..." but I have an "English as a second language" problem so I do not get what is it I have to substract.

By the way, at this moment the day of the month is shown properly, because from 09:00 the day becomes the current day. So anything I do I would need to wait until midnight or early tomorrow morning to test it.

look:
https://product-help.schneider-electric.com/Machine%20Expert/V1.1/en/LibDevSummary/topics/date_time.htm

I don't see any difference comapring there. (expect that conversion error is on same variable, and you have seperate variables)

For testing you can make own variable and write computer times there, then convert from it and see if there is error. No need to wait midnight then as you can test easily different time values.

AustralIan · Apr 15, 2020

I ran across this too. It is fixed for me in the latest version runtime (currently 3.5.15.40). For me it only happened on Control Win, OR Simulation mode (which uses control win), it didn't effect the actual PLC.

Still, here is the workaround (or long walk around!) for ealier versions. You could probably make it a function...:

Code:

FUNCTION getTheActualLocalTime : DT
VAR
    dtLocal: DT;
    uiYear,
    uiMonth , 
    uiDay , 
    uiHour , 
    uiMinute , 
    uiSecond :UINT;
    
    myTZ : Util.TimeZone := (asgPeriod := [2((dtDate := (eWeekday := WEEKDAY.SUNDAY)))]);
    myRTCTZ: SysTimeRtc.TimezoneInformation;
END_VAR
~~~

SysTimeRTC.SysTimeRtcGetTimezone(myRTCTZ);
myTZ.iBias := -1 * myRTCTZ.iBias;

Util.SplitDateTime(uliDateTime:= UDINT_TO_ULINT(myRTCTZ.ulStandardDate) * 1000, 
                    //uiYear=> myTZ.asgPeriod[1].dtDate.uiYear, 
                    uiMonth=> myTZ.asgPeriod[1].dtDate.uiMonth, 
                    uiDay=> myTZ.asgPeriod[1].dtDate.uiDay, 
                    uiHour=> myTZ.asgPeriod[1].dtDate.uiHour, 
                    uiMinute=> myTZ.asgPeriod[1].dtDate.uiMinute, 
                    uiSecond=> myTZ.asgPeriod[1].dtDate.uiSecond, 
                    uiMilliseconds=> myTZ.asgPeriod[1].dtDate.uiMilliseconds, );
                    //eWeekday=> myTZ.asgPeriod[1].dtDate.eWeekday);

myTZ.asgPeriod[1].iBias := -1 * myRTCTZ.iStandardBias;
myTZ.asgPeriod[1].sName := myRTCTZ.szStandardName;

Util.SplitDateTime(uliDateTime:= UDINT_TO_ULINT(myRTCTZ.ulDaylightDate) * 1000, 
                    //uiYear=> myTZ.asgPeriod[2].dtDate.uiYear, 
                    uiMonth=> myTZ.asgPeriod[2].dtDate.uiMonth, 
                    uiDay=> myTZ.asgPeriod[2].dtDate.uiDay, 
                    uiHour=> myTZ.asgPeriod[2].dtDate.uiHour, 
                    uiMinute=> myTZ.asgPeriod[2].dtDate.uiMinute, 
                    uiSecond=> myTZ.asgPeriod[2].dtDate.uiSecond, 
                    uiMilliseconds=> myTZ.asgPeriod[2].dtDate.uiMilliseconds, );
                    //eWeekday=> myTZ.asgPeriod[2].dtDate.eWeekday);
                    
myTZ.asgPeriod[2].iBias := -1 * myRTCTZ.iDaylightBias;
myTZ.asgPeriod[2].sName := myRTCTZ.szDaylightName;

dtLocal := ULINT_TO_DT(Util.GetLocalDateTime(myTZ)/1000);
    
//can use these if you're interested
DTU.DTSplit(
    dtDateAndTime:= dtLocal, 
    puiYear:= ADR(uiYear), 
    puiMonth:= ADR(uiMonth), 
    puiDay:= ADR(uiDay), 
    puiHour:= ADR(uiHour), 
    puiMinute:= ADR(uiMinute), 
    puiSecond:= ADR(uiSecond));
    
getTheActualLocalTime := dtLocal; //return

Code:

PROGRAM PLC_PRG
VAR
    mytime : DT;
END_VAR
~~~


myTime := getTheActualLocalTime();

AlfredoQuintero · Apr 15, 2020

AustralIan: Thanks very much for the hint. I am using 3.5.15.30. I am using ControlWin, because I am not controlling IO with Codesys, just gathering data from two PLCs.

Fortunately, I have full control of the version for this application. The machine is running production at the moment. It will be stopping in a few hours. I will update the Codesys environment and start the application, then will check again tomorrow morning.

If this version update does not fix my problem I will either try your solution or use the time stamp provided by the communication middle ware which does not seem to have this problem.

Also, thanks very much to Ken and Lare. I will be documenting the result of my investigation and my resolution.

AlfredoQuintero · Apr 16, 2020

Hello again, AustralIan:

The newest Version: 3.5.15.40 has fixed the problem. This morning before 09:00 my program was displaying the correct day of week and day of months. Thanks so very much. It makes me anxious to think why the previous library had this problem. Was it maybe something that used to work properly and had this problem introduced into some patch? Let's hope 3S can establish a regression test that prevent this issue from ever happening again.

Codesys SysTimeRtcConvertHighResToLocal unexpected behaviour

AlfredoQuintero

Lifetime Supporting Member

Ken Roach

Lifetime Supporting Member + Moderator

AlfredoQuintero

Lifetime Supporting Member

Lare

Member

AustralIan

Member

AlfredoQuintero

Lifetime Supporting Member

AlfredoQuintero

Lifetime Supporting Member

Similar Topics