Hi,
I am using the Elster AS3500 DLMS meter and I am trying to read this meter via serial Connection (RS485) using C stack but not able to read it. But, the same thing when I am trying to read Via GXDLMS director is reading properly.
I found that, Via C stack, it's not sending AARQ request after SNRM request. Below are the Frames:
Data Parse is not happening. I have commented the return ret, then its sending the AARQ request.
I have observed that for any frame data parse is not happening for this meter. Even though GXDLMS Tool and Stack frames are same.
Can you tell me the reason and how to resolve this ?
This is tested with your commands and it worked like expected. You have broken something. Reject the changes and try again. You can try with client example if you add this parameter:
-s 208
Hi,
I tried several times, but its returning from that function only, even though SNRM response is correct and not sending AARQ request. and I am using Logical address as 208 only.
The same code is working fine with other DLMS meter( Kamstrup , Chint)
Because this was working when your trace was simulated you need to check that you haven't made any changes for the source code. Try to get the latest version from the GitHub and replace your code with that. Or try to run client example with -s parameter.
Hi,
Thanks for your reply .
Sorry, but I am not understanding this - try to run client example with -s parameter.
Can you pls tell me where I have o give this -s parameter in the code. An example will be much appreciated.
The size of the client address is always 1. If that fails, then your meter sends something else than what you have added here.
7E A0 19 21 02 A1 73 02 43 81 80 0C 05 01 80 06 01 80 07 01 01 08 01 01 05 13 7E
Are (and can) you using malloc? Are you sure that data in the buffer is this:
7E A0 19 21 02 A1 73 02 43 81 80 0C 05 01 80 06 01 80 07 01 01 08 01 01 05 13 7E
The reason why I'm asking this is that this is used in lots of different places and if the data is the same as in your log below this should succeed. Verify what data you have saved to the buffer.
Hi,
When I am querying the OBIS code(1.1.72.7.0.255) sometimes I am receiving the below frame can you pls tell me what's this mean.
snrm cmd:
7e a0 15 02 a1 21 93 dd 15 81 80 08 05 02 03 f2 06 02 03 f2 03 f0 7e
Resp:
7e a0 19 21 02 a1 73 02 43 81 80 0c 05 01 80 06 01 80 07 01 01 08 01 01 05 13 7e
Your meter is sending ReceiverReady, but there is no reason why this is happening. I believe that this is a meter issue. You should talk with the meter manufacturer about this.
Hi,
Thanks for your quick response.
One more query I have.
When I am receiving AARQ response that time its returning value as 260 which is DLMS_OUT_OF_MEMORY even though I am giving Max PDU size 0xFFFF.
Have you cleared the receiver buffer? It's the buffer where you are appending received bytes.
Max PDU size is not causing this DLMS_OUT_OF_MEMORY error. It's something else.
Hi,
Thanks for your reply this got resolved.
One more query i have some times i am not getting response from the meter so received buffer is coming 0.
Can you tell me why this is happening if you have any idea?
I am using linux board this time and also i am not using fifo here.
In microcontroller based device i am receiving response every time.
After analyzing all the communication logs
Reader Ready means that the authentication is correct and is ready for valid Request.
It appears that the request is incorrect because the response means Next Frame. With this behavior, this means the Request is regarding the frames.
The message is lost for some reason. This is happening all the time when the connection is not good.
If you are making the meter the might also be a problem with the meter, but it's impossible to say what is causing this.
Hi,
I found that whenever Next Frame(receiver Ready) is coming as respone that time Command Frame is different that why the meter is requesting to send the next frame. Can you check the command frame and let me know why this is happening. Check the Frame type value.
1.1.72.7.0.255
cmd : 7e a0 1a 02 a1 21 fe c2 c7 e6 e6 00 c0 01 81 00 03 01 01 48 07 00 ff 02 00 bc 77 7e
resp : 7e a0 14 21 02 a1 1e 95 87 e6 e7 00 c4 01 81 00 12 08 bb b9 b5 7e
cmd : 7e a0 1a 02 a1 21 32 a2 cb e6 e6 00 c0 01 81 00 03 01 01 48 07 00 ff 02 00 bc 77 7e
resp : 7e a0 08 21 02 a1 11 12 bc 7e
1.1.14.7.0.255
cmd : 7e a0 1a 02 a1 21 fe c2 c7 e6 e6 00 c0 01 81 00 03 01 01 0e 07 00 ff 02 00 97 6d 7e
resp : 7e a0 14 21 02 a1 1e 95 87 e6 e7 00 c4 01 81 00 12 13 8b 03 f5 7e
cmd :7e a0 1a 02 a1 21 ba e2 c3 e6 e6 00 c0 01 81 00 03 01 01 0e 07 00 ff 02 00 97 6d 7e
resp : 7e a0 08 21 02 a1 f1 1c 5b 7e
Hi,
Thanks for your reply. I don't think I have done any changes and those are not two consecutive frames. but I will check. can you tell me in which function I have to check? Is it "dlms_getHdlcFrame()"
Also, can you tell me the Frame type value will be always the same for the command(for the same OBIS of a meter) or it will vary in every query for the same OBIS code?
Hi, I have observed that
Hi, I have observed that below function (cl_parseUAResponse) is not returning 0 (Zero) .
if ((ret = cl_snrmRequest(&connection->settings, &messages)) != 0 ||
(ret = com_readDataBlock(connection, &messages, &reply)) != 0 ||
(ret = cl_parseUAResponse(&connection->settings, &reply.data)) != 0)
{
debug_print("dlms_parseSnrmUaResponse : %d\r\n",ret); // 263
mes_clear(&messages);
reply_clear(&reply);
//return ret; - uncomment this after tesing.
}
Data Parse is not happening. I have commented the return ret, then its sending the AARQ request.
I have observed that for any frame data parse is not happening for this meter. Even though GXDLMS Tool and Stack frames are same.
Can you tell me the reason and how to resolve this ?
Hi,
Hi,
This is tested with your commands and it worked like expected. You have broken something. Reject the changes and try again. You can try with client example if you add this parameter:
-s 208
BR,
Mikko
Hi,
Hi,
I tried several times, but its returning from that function only, even though SNRM response is correct and not sending AARQ request. and I am using Logical address as 208 only.
The same code is working fine with other DLMS meter( Kamstrup , Chint)
Hi,
Hi,
Because this was working when your trace was simulated you need to check that you haven't made any changes for the source code. Try to get the latest version from the GitHub and replace your code with that. Or try to run client example with -s parameter.
BR,
Mikko
Hi,
Hi,
Thanks for your reply .
Sorry, but I am not understanding this - try to run client example with -s parameter.
Can you pls tell me where I have o give this -s parameter in the code. An example will be much appreciated.
Hi Mikko,
Hi Mikko,
Now I am able to read this ELSTER meter via C library. After commenting the "return DLMS_ERROR_CODE_INVALID_CLIENT_ADDRESS; "
Can you pls tell me why this check is there - if (isClientAddress && size != 1)
if (isClientAddress && size != 1)
{
//return DLMS_ERROR_CODE_INVALID_CLIENT_ADDRESS;
}
if (size == 1)
{
if ((ret = bb_getUInt8(buff, &ch)) != 0)
{
return ret;
}
*address = ((ch & 0xFE) >> 1);
}
else if (size == 2)
{
if ((ret = bb_getUInt16(buff, &s)) != 0)
{
return ret;
}
*address = ((s & 0xFE) >> 1) | ((s & 0xFE00) >> 2);
}
else if (size == 4)
{
if ((ret = bb_getUInt32(buff, &l)) != 0)
{
return ret;
}
*address = ((l & 0xFE) >> 1) | ((l & 0xFE00) >> 2)
| ((l & 0xFE0000) >> 3) | ((l & 0xFE000000) >> 4);
}
else
{
return DLMS_ERROR_CODE_INVALID_PARAMETER;
}
return DLMS_ERROR_CODE_OK;
Hi,
Hi,
Also can you pls provide cl_getServerAddress function definition. So that I can add it to my DLMS library.
Hi,
Hi,
The size of the client address is always 1. If that fails, then your meter sends something else than what you have added here.
7E A0 19 21 02 A1 73 02 43 81 80 0C 05 01 80 06 01 80 07 01 01 08 01 01 05 13 7E
BR,
Mikko
Hi,
Hi,
The meter sends the same frame which I have mentioned earlier.
Hi,
Hi,
Are you sure that you haven't made modifications to the source code? What compiler you are using?
BR,
Mikko
Hi,
Hi,
Yes I have not done any changes in DLMS library. And I am using GNU C Compiler : 8.2.1
Hi,
Hi,
Are you running this in Linux?
BR,
Mikko
Hi,
Hi,
No I am using RTOS based embedded device, ATSAME70Q20 Micro-controller . And I am using Atmel Studio to build the code.
Hi,
Hi,
Are (and can) you using malloc? Are you sure that data in the buffer is this:
7E A0 19 21 02 A1 73 02 43 81 80 0C 05 01 80 06 01 80 07 01 01 08 01 01 05 13 7E
The reason why I'm asking this is that this is used in lots of different places and if the data is the same as in your log below this should succeed. Verify what data you have saved to the buffer.
BR,
Mikko
hi,
hi,
Yes Malloc has been used in the library, below is the code
void mes_init(message* mes)
{
mes->capacity = MESSAGE_CAPACITY;
mes->data = (gxByteBuffer**) gxmalloc(mes->capacity * sizeof(gxByteBuffer*));
mes->size = 0;
}
below is the response we are getting in our embedded device:
sending Command:
7e a0 08 02 a1 21 93 e9 dd 7e
received buffer: 27
7e a0 19 21 02 a1 73 02 43 81 80 0c 05 01 80 06 01 80 07 01 01 08 01 01 05 13 7e
Client address:0
Client address Size:1
Client address:1
Client address Size:2
I tried to hardcode size to 1 to check whether this meter is parsing data or not. But unfortunately its not parsing when size is 1.
Hi,
Hi,
When I am querying the OBIS code(1.1.72.7.0.255) sometimes I am receiving the below frame can you pls tell me what's this mean.
snrm cmd:
7e a0 15 02 a1 21 93 dd 15 81 80 08 05 02 03 f2 06 02 03 f2 03 f0 7e
Resp:
7e a0 19 21 02 a1 73 02 43 81 80 0c 05 01 80 06 01 80 07 01 01 08 01 01 05 13 7e
Aarq Cmd :
7e a0 45 02 a1 21 10 2c d6 e6 e6 00 60 36 a1 09 06 07 60 85 74 05 08 01 01 8a 02 07 80 8b 07 60 85 74 05 08 02 01 ac 0a 80 08 30 30 30 30 30 30 30 30 be 10 04 0e 01 00 00 00 06 5f 1f 04 00 00 1e 1d ff ff 5c fd 7e
resp:
7e a0 38 21 02 a1 30 48 58 e6 e7 00 61 29 a1 09 06 07 60 85 74 05 08 01 01 a2 03 02 01 00 a3 05 a1 03 02 01 00 be 10 04 0e 08 00 06 5f 1f 04 00 00 18 1d 03 e8 00 07 58 26 7e
cmd : 1.1.72.7.0.255
7e a0 1a 02 a1 21 32 a2 cb e6 e6 00 c0 01 81 00 03 01 01 48 07 00 ff 02 00 bc 77 7e
Resp :
7e a0 08 21 02 a1 91 1a 38 7e
Hi,
Hi,
Your meter is sending ReceiverReady, but there is no reason why this is happening. I believe that this is a meter issue. You should talk with the meter manufacturer about this.
BR,
Mikko
Hi,
Hi,
Thanks for your quick response.
One more query I have.
When I am receiving AARQ response that time its returning value as 260 which is DLMS_OUT_OF_MEMORY even though I am giving Max PDU size 0xFFFF.
snrm cmd:
7e a0 15 02 a1 21 93 dd 15 81 80 08 05 02 03 f2 06 02 03 f2 03 f0 7e
Resp:
7e a0 19 21 02 a1 73 02 43 81 80 0c 05 01 80 06 01 80 07 01 01 08 01 01 05 13 7e
Aarq Cmd :
7e a0 45 02 a1 21 10 2c d6 e6 e6 00 60 36 a1 09 06 07 60 85 74 05 08 01 01 8a 02 07 80 8b 07 60 85 74 05 08 02 01 ac 0a 80 08 30 30 30 30 30 30 30 30 be 10 04 0e 01 00 00 00 06 5f 1f 04 00 00 1e 1d ff ff 5c fd 7e
resp:
7e a0 38 21 02 a1 30 48 58 e6 e7 00 61 29 a1 09 06 07 60 85 74 05 08 01 01 a2 03 02 01 00 a3 05 a1 03 02 01 00 be 10 04 0e 08 00 06 5f 1f 04 00 00 18 1d 03 e8 00 07 58 26 7e
Hi,
Hi,
Have you cleared the receiver buffer? It's the buffer where you are appending received bytes.
Max PDU size is not causing this DLMS_OUT_OF_MEMORY error. It's something else.
BR,
Mikko
Hi,
Hi,
Thanks for your reply this got resolved.
One more query i have some times i am not getting response from the meter so received buffer is coming 0.
Can you tell me why this is happening if you have any idea?
I am using linux board this time and also i am not using fifo here.
In microcontroller based device i am receiving response every time.
Hi,
Hi,
This is what i got response from elster team.
After analyzing all the communication logs
Reader Ready means that the authentication is correct and is ready for valid Request.
It appears that the request is incorrect because the response means Next Frame. With this behavior, this means the Request is regarding the frames.
Hi,
Hi,
The message is lost for some reason. This is happening all the time when the connection is not good.
If you are making the meter the might also be a problem with the meter, but it's impossible to say what is causing this.
BR,
Mikko
Hi,
Hi,
I found that whenever Next Frame(receiver Ready) is coming as respone that time Command Frame is different that why the meter is requesting to send the next frame. Can you check the command frame and let me know why this is happening. Check the Frame type value.
1.1.72.7.0.255
cmd : 7e a0 1a 02 a1 21 fe c2 c7 e6 e6 00 c0 01 81 00 03 01 01 48 07 00 ff 02 00 bc 77 7e
resp : 7e a0 14 21 02 a1 1e 95 87 e6 e7 00 c4 01 81 00 12 08 bb b9 b5 7e
cmd : 7e a0 1a 02 a1 21 32 a2 cb e6 e6 00 c0 01 81 00 03 01 01 48 07 00 ff 02 00 bc 77 7e
resp : 7e a0 08 21 02 a1 11 12 bc 7e
1.1.14.7.0.255
cmd : 7e a0 1a 02 a1 21 fe c2 c7 e6 e6 00 c0 01 81 00 03 01 01 0e 07 00 ff 02 00 97 6d 7e
resp : 7e a0 14 21 02 a1 1e 95 87 e6 e7 00 c4 01 81 00 12 13 8b 03 f5 7e
cmd :7e a0 1a 02 a1 21 ba e2 c3 e6 e6 00 c0 01 81 00 03 01 01 0e 07 00 ff 02 00 97 6d 7e
resp : 7e a0 08 21 02 a1 f1 1c 5b 7e
Hi,
Hi,
Can you pls reply to this as soon as possible. Please.
Hi,
Hi,
If those are two consecutive frames your HDLC frame sequence number is wrong. Make sure that you haven't made any changes to the source code.
BR,
Mikko
Hi,
Hi,
Thanks for your reply. I don't think I have done any changes and those are not two consecutive frames. but I will check. can you tell me in which function I have to check? Is it "dlms_getHdlcFrame()"
Also, can you tell me the Frame type value will be always the same for the command(for the same OBIS of a meter) or it will vary in every query for the same OBIS code?
Hi,
Hi,
Another option is that you call ex, read method twice. Each call will increase HDLC sequence number.
BR,
Mikko