Skip to main content
Home
for DLMS smart meters
Open source solutions for DLMS smart metering

Main navigation

  • Home
  • Products
  • About us
  • Open Source
  • Community
  • Forum
  • Downloads
User account menu
  • Log in

Breadcrumb

  1. Home
  2. Incorrect Page Calculation In Image Transfer Class

Incorrect Page Calculation in Image Transfer class

Forum Rules

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.

By icabrera , 5 February, 2020
Forums
DLMSDirector

Hello,

I found an incorrect page calculation in image transfer class.

The steps to reproduce the error are the following:

1. Connect to the meter and read the association (f5 key).

2. Open the window update pop up (selection of update file) and wait until the meter closes session due to the lack of keep alive messages. In my case, 1 minute.

3. Then, select one file and click OK.

4. Start the firmware update process and it will fail due to Disconnected state of the meter.

5. Connect again to the meter.

6. Click on update, and update process will start without asking for update file.

-- At this point, Gurux calculates incorrectly the number of pages because it is taking into account the default block size (200) and not the block size provided by the meter.

-- Update continues sending pages at incorrect block size causing fail in the update process, because meter waits for messages with length of the block size property.

Profile picture for user Kurumi

Kurumi

6 years 4 months ago

Hello,

Hello,

Image block size (attribute 2) is read from the meter at first. Can you try to read it? Just select Image Transfer object and read it. What is the value?

BR,
Mikko

icabrera

6 years 4 months ago

Hello,

Hello,

Yes, by reading the attribute 2 (256 bytes in my case) everything works fine, also when you upload a new image the attribute is automatically reading at first.

The problem is when you "resumes" a previously started process, the attribute is not readed again and then the process starts with the default value in Gurux (200 bytes).

In the example case provided first, the attribute is not readed in the first attempt because the session closed -expired while we choose the file to upload-, and then when you click "Upload" again, the process restarts without reading again the block size attribute.

I think the behavior of Gurux is appropiate by reading the block size at first, this allows to know the block size and the process the upload file in a correct way, but I think the fail is to "resume" a previous process without reading again the attribute, in special when the previous read of the attribute could not be completed -due to closed session and/or failed to communicate-.

Just as a comment, for developers or tech people, it can be ok to read the attribute before start an update process, but for non-tech people or operators it can be confusing.

Regards,

  • Create new account
  • Reset your password

Hire Us!

Latest Releases

  • Tue, 06/09/2026 - 11:16
    gurux.dlms.java 4.0.95
  • Tue, 06/09/2026 - 10:03
    Gurux.DLMS.Python 1.0.199
  • Mon, 06/08/2026 - 13:39
    gurux.dlms.cpp 9.0.2606.0801
  • Mon, 06/01/2026 - 10:15
    gurux.dlms.cpp 9.0.2606.0101
  • Thu, 05/28/2026 - 16:06
    gurux.dlms.java 4.0.94

New forum topics

  • Error reading L&G Meter
  • Pass a TCP Client to GXNet
  • Australian EDMI Mk10D (Essential Energy area)
  • Strange mix of data notificiation vs get response
  • DLMS Connection
More

Who's new

  • Tuanhgg
  • Adel
  • charnon
  • Paddles
  • Miguel Ángel
RSS feed
Privacy FAQ GXDN Issues Contact
Follow Gurux on Twitter Follow Gurux on Linkedin