time_compare2() throwing exception

Project: 
gurux.dlms.c

Hi,

We are working in the server example 2.

The function below take 2 arguments:
int time_compare2(gxtime* value1, uint32_t value2)

When the value1 is equal to 0, it is throwing an error (check the uploaded picture).

We were able to narrow exactly the origin of this exception.

1. We set the capture period to a number different from 0 (if not the issue will not appear) for example 300s(5min).

2. Each 5 mins in the svr_handleProfileGeneric the svr_invoke will be called with these arguments :

ret = svr_invoke(
settings,
(gxObject*)object,
2,
time,
NULL,
NULL,
&object->executedTime,
next);

So, the gxtime start and end arguments are both equal to NULL.

3. In the svr_invoke function we find this condition:

if (end == NULL)
{
exec = *executed < time && time_compare2(start, time) == 0;
}

The end and start gxtime variable are NULL so the time_compare2 is taking NULL as start arguments and this is exactly the reason that is throwing the exception.

Hope this will help you to solve this issue.

Best Regards,

Lara Wakim

Status: 
Active
Priority: 
Normal
Category: 
Bug report
Component: 
Code
Reporter: 
lara.wakim
Created: 
Tue, 07/21/2020 - 11:38
Updated: 
Tue, 07/21/2020 - 11:38

Comments

Hi Mikko,

We downloaded the latest release (version 20200721.1) and tested it.

- The exception due to the time_compare2() is gone and the capture period feature of the profile generic worked perfectly

- The issue concerning the single action scheduler that was only triggered on execution time ending by 00s or 30 s is also solved.

- One issue left not solved yet: the deviation of our country is not taken into consideration when setting the execution time from the GXDLMSDirector. In fact, the deviation is skipped and the single action scheduler is triggered based on UTC time and not our country time. This issue needs to be solved.

Thank you for your hard work.

Best Regards,

Lara Wakim

Kurumi's picture

Hi Lara,

Single Action Schedule doesn't use deviation. It's manually added in svr_run.
What time zone you are using? Have you set the time zone for the clock object?

BR,
Mikko

Hi Mikko,

Our time zone is equal to -120 and we set the time zone for the clock object and tested the single action scheduler but the issue is still here.

In fact, when introducing the execution time for the GXDLMSDirector the deviation is skipped and the single action scheduler is triggered based on UTC time and not our country time.

For example, our country time is equal to UTC+3. When testing, to trigger the single action scheduler at 4:00 pm (our time UTC+3) we introduced the execution time equal to 1:00 pm (UTC time) and it worked. Instead, we expected to introduce as execution time 4:00 pm and the action to be triggered at 4:00 pm.

You told us the last time it could be solve by calling the clock_utcToMeterTime(&meterData.clock1, &tm).

Best Regards,

Lara Wakim

Kurumi's picture

Hi,
There has been a misunderstanding. clock_utcToMeterTime(&meterData.clock1, &tm) is used when you read data to profile generic. You don't use it when setting execution time.

Single action execution time is split to two parts. Date and time and deviation is ignored.

execution_time_date ::= structure
{
time: octet-string,
date: octet-string
}

Try to clear execution times and write a new execution time using GXDLMSDirector. Will it work?
Do you try to set an exact time or do you want that this schedule is executed example daily?

BR,
Mikko

Hi,

Our first objective of testing is to set an exact time delayed 1 min from our time and wait the triggering of the action scheduler. We tried to clear the execution times and write a new one using GXDLMSDirector equal to our time delayed of 1 min, but it didn't work. However when we tried to put from the GXDLMSDirector a time equal to the UTC time not ours and delayed of 1 min, it worked and the action is triggered.

We followed the code and we noticed when we are setting a new execution time it goes to the cosem_setActionSchedule() function in the "gxset.c" file. In this function, at the index number 4, we noticed for example if we set an execution time equal to 11:00:00 am (our time now) from the GXDLMSDirector, the "tm" variable is saved equal to 2:00:00 pm (they added the deviation to the set value like they were expecting the UTC time not our real time), so the saved value is equal to the UTC time plus the deviation(3h)*2. Maybe the problem is due to the GXDLMSDirector not the server.

To avoid this problem and trigger the action at 11:00:00 am our time, we set an execution time equal to 8:00:00 am from the GXDLMSDirector. Afterwards, the "tm" variable in the cosem_setActionSchedule() function is saved as 11:00:00 am, and the action schedule is triggered at 11:00:00 am like wanted.

Hope the issue is more clear now.

Best Regards,

Lara Wakim

Hi,

We downloaded the latest version of the server example 2, but this issue is still not solved. The execution time of the single action schedule is still triggered based on UTC time and not our country time. Can you check it please.

Best Regards,

Lara Wakim

Kurumi's picture

Hi Lara,

Can you show how you add the time? Have you set Time Zone for the clock object? It should be -120.

BR,
Mikko