Before commenting read Forum rules
Don't comment the topic if you have a new question.
You can create a new topic selecting correct category from Gurux Forum and then create a new topic selecting "New Topic" from the top left.
Forums
Dear,
When I try to read the Association with the client example (v4.0.5), If any transmission of any block fails then the example does a retry and we are getting "java.lang.IllegalArgumentException: getUInt16" while processing the retransmitted package.
Log snippet from the example:
TX: 08:16:31.047 00 01 00 01 00 01 00 07 C0 02 C1 00 00 00 1A
Data send failed. Try to resend 1/3
TX: 08:16:34.051 00 01 00 01 00 01 00 07 C0 02 C1 00 00 00 1A
RX: 08:16:34.757 C4 00 01 00 01 00 01 00
When I monitored the packets using Wireshark, I could see that the received block is a valid block, Looks like there is a bug while appending the retransmitted packet with the previously received packets.
If required I could provide the WireShark capture file.
Exception stack trace:
java.lang.IllegalArgumentException: getUInt16
at gurux.dlms.GXByteBuffer.getUInt16(GXByteBuffer.java:380)
at gurux.dlms.GXByteBuffer.getUInt16(GXByteBuffer.java:369)
at gurux.dlms.GXDLMS.getTcpData(GXDLMS.java:2129)
at gurux.dlms.GXDLMS.getData(GXDLMS.java:3809)
at gurux.dlms.GXDLMSClient.getData(GXDLMSClient.java:2795)
at gurux.dlms.client.GXDLMSReader.readDLMSPacket(GXDLMSReader.java:295)
at gurux.dlms.client.GXDLMSReader.readDataBlock(GXDLMSReader.java:372)
at gurux.dlms.client.GXDLMSReader.getAssociationView(GXDLMSReader.java:996)
at gurux.dlms.client.GXDLMSReader.readAll(GXDLMSReader.java:1031)
at gurux.dlms.client.sampleclient.main(sampleclient.java:122)
BR
Pramod
Hi Pramod,
Hi Pramod,
Can you post send and received bytes? You can find my email address here:
http://www.gurux.fi/AboutUs
BR,
Mikko
Hi Mikko,
Hi Mikko,
I have sent you the email with details.
BR
Pramod
Hi,
Hi,
Your meter sends the first three blocks correctly. When four is asked, meter return invalid data.
C4 00 01 00 01 00 01 00
Ask your meter manufacturer to fix it.
BR,
Mikko
Hi Mikko,
Hi Mikko,
When I sniffed the packets using Wireshark, I could see that the meter is sending a valid block.
Below is the content of the 4th block extracted using Wireshark:
00010001000100d8c402c100000000040081cd02041200091100090600000a0200ff0202010202030f0116000002030f02160000010102020f01160102041200091100090600000a0300ff0202010202030f0116000002030f02160000010102020f01160102041200091100090600000a0400ff0202010202030f0116000002030f02160000010102020f01160102041200091100090600000a0500ff0202010202030f0116000002030f02160000010102020f01160102041200091100090600000a0600ff0202010202030f0116000002030f02160000010102020f011601
The communication is not always failing at 4th block, sometimes it 23rd or sometimes it will even go up to 45. Due to bad network, when is block is failed to receive the library is asking for retransmission and fails while decoding retransmitted block. If i copy the retransmitted block content and translate using gurux translator, it is being translated without any errors.
BR
Pramod
Hi Pramod,
Hi Pramod,
We have faced the same problem with some meters. There is nothing that client can do. A communication channel is bad. This isn't usually a problem when HDLC framing is used, but with WRAPPER is causing problems because there is no CRC.
The only solution is to try to read only a small amount of the data at the time. Save association view and read profile generic tables several times a day.
I don't know is this the problem in your case, but some meters lost data block after it's sent. If it's lost on the way, the client asks it again but it meter doesn't have it and meter sends data like yours.
This is easy to test. Ask received data block again and if meter returns data like below, there is an error on the meter.
C4 00 01 00 01 00 01 00
BR,
Mikko
Hi Mikko,
Hi Mikko,
When we read the Association using the GXDLMSDirector we also have the problem of losing the packets but there the client will ask for retransmission and the retry works there.
Below is an extract from GXDLMSDirector, If it helps I can send you the complete communication log from GXDLMSDirector.
04:47:46 Get Next Data block.
04:47:46 Collecting objects
00 01 00 01 00 01 00 07 C0 02 C1 00 00 00 88
<WRAPPER len="F" >
<TargetAddress Value="1" />
<SourceAddress Value="1" />
<PDU>
<GetRequest>
<GetRequestForNextDataBlock>
<InvokeIdAndPriority Value="C1" />
<BlockNumber Value="00000088" />
</GetRequestForNextDataBlock>
</GetRequest>
</PDU>
</WRAPPER>
04:47:51 Data send failed. Try to resend 1/3
04:47:52
00 01 00 01 00 01 00 C5 C4 02 C1 00 00 00 00 89 00 81 BA 02 04 12 00 04 11 00 09 06 01 00 0A 02 00 FF 02 02 01 05 02 03 0F 01 16 01 00 02 03 0F 02 16 01 00 02 03 0F 03 16 01 00 02 03 0F 04 16 01 00 02 03 0F 05 16 01 00 01 01 02 02 0F 01 16 00 02 04 12 00 04 11 00 09 06 01 00 0A 02 01 FF 02 02 01 05 02 03 0F 01 16 01 00 02 03 0F 02 16 01 00 02 03 0F 03 16 01 00 02 03 0F 04 16 01 00 02 03 0F 05 16 01 00 01 01 02 02 0F 01 16 00 02 04 12 00 04 11 00 09 06 01 00 0A 02 02 FF 02 02 01 05 02 03 0F 01 16 01 00 02 03 0F 02 16 01 00 02 03 0F 03 16 01 00 02 03 0F 04 16 01 00 02 03 0F 05 16 01 00 01 01 02 02 0F 01 16 00
<WRAPPER len="CD" >
<TargetAddress Value="1" />
<SourceAddress Value="1" />
<PDU>
<GetResponse>
<GetResponsewithDataBlock>
<InvokeIdAndPriority Value="C1" />
<Result>
<LastBlock Value="00" />
<BlockNumber Value="00000089" />
<Result>
<RawData Value="02041200041100090601000A0200FF0202010502030F0116010002030F0216010002030F0316010002030F0416010002030F05160100010102020F01160002041200041100090601000A0201FF0202010502030F0116010002030F0216010002030F0316010002030F0416010002030F05160100010102020F01160002041200041100090601000A0202FF0202010502030F0116010002030F0216010002030F0316010002030F0416010002030F05160100010102020F011600" />
</Result>
</Result>
</GetResponsewithDataBlock>
</GetResponse>
</PDU>
</WRAPPER>
BR,
Pramod
Hi Pramod,
Hi Pramod,
If communication channel is not working errors might be random. I'm wondering where this C4 is coming to the message:
C4 00 01 00 01 00 01 00
We'll improved WRAPPER parser so it can handle this and the new version is released today.
BR,
Mikko
Hi Mikko,
Hi Mikko,
To avoid the network error variable I have randomly tested reading the Association 10 times both using the GXDLMSDirector and the client example. I could successfully read the Association all the times with GXDLMSDirector but it always failed with client example.
I have monitored the traffic of both director and client example using Wireshark, the pattern of retry transmission is same but the Java lib fails to recognize the retransmitted packet.
With version 4.0.6 we are getting a different exception than earlier:
Count
java.lang.IllegalArgumentException: Count
at gurux.common.ReceiveParameters.setCount(ReceiveParameters.java:149)
at gurux.dlms.client.GXDLMSReader.readDLMSPacket(GXDLMSReader.java:312)
at gurux.dlms.client.GXDLMSReader.readDataBlock(GXDLMSReader.java:372)
at gurux.dlms.client.GXDLMSReader.getAssociationView(GXDLMSReader.java:996)
at gurux.dlms.client.GXDLMSReader.readAll(GXDLMSReader.java:1031)
at gurux.dlms.client.sampleclient.main(sampleclient.java:122)
The client example pom file is still refering to 4.0.5 version of gurux dlms. I have changed it to 4.0.6 before testing.
BR
Pramod