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.
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?
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.
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
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,