Welcome to our new forum
All users of the legacy CODESYS Forums, please create a new account at account.codesys.com. But make sure to use the same E-Mail address as in the old Forum. Then your posts will be matched.
Close
have you ever encounered this problem below before
when reading from large files (I am using FILE_ACCESS library), and the size of buffer cannot accomodate all data in the file, and consequently for getting all data from the file, I set the file pointer position (FILE.SetPos) to where it stopped (clearly multiples of buffer size) and read again and so on until end of file is reached (FILE.xEOF).
The very weird behaviour which I observe is that when using the function block (FILE.SetPos), and when the file is all read BUT there are still empty bytes in the buffer, then somehow the buffer is filled from the function (FILE.READ) from the end of the file all the way backward with the size of the empty bytes. plus that i never get ''FILE.xEOF'' TRUE .
Exmaple:
If file is composed of 100 bytes and i have buffer of size 80. I read the first 80 bytes and in the next cycle the position is set to 80 , and now, however, there are only 20 bytes left, it will read the residue 20 bytes and other last 60 other bytes in the file to fill the rest of the buffer.
I really appreciate any contributions for a solution.
Regards,
Anas
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2016-07-20
Originally created by: scott_cunningham
I think the file read is performing a byte copy from the hardware buffer for fast response. This means it does not first clear the answer to 0 bytes and then copy - it just copies over the old. So for you example, the answer was 80 bytes - and then you tell it to read again - so it copies 20 bytes and stops, leaving the rest of the answer filled with old data.
As a work around for not seeing an end of file, you could first read the file size and then determine how many times you must read at 80 bytes and what the leftover is (in your example 20). This is how I solved it once.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello everyone
have you ever encounered this problem below before
when reading from large files (I am using FILE_ACCESS library), and the size of buffer cannot accomodate all data in the file, and consequently for getting all data from the file, I set the file pointer position (FILE.SetPos) to where it stopped (clearly multiples of buffer size) and read again and so on until end of file is reached (FILE.xEOF).
The very weird behaviour which I observe is that when using the function block (FILE.SetPos), and when the file is all read BUT there are still empty bytes in the buffer, then somehow the buffer is filled from the function (FILE.READ) from the end of the file all the way backward with the size of the empty bytes. plus that i never get ''FILE.xEOF'' TRUE .
Exmaple:
If file is composed of 100 bytes and i have buffer of size 80. I read the first 80 bytes and in the next cycle the position is set to 80 , and now, however, there are only 20 bytes left, it will read the residue 20 bytes and other last 60 other bytes in the file to fill the rest of the buffer.
I really appreciate any contributions for a solution.
Regards,
Anas
Originally created by: scott_cunningham
I think the file read is performing a byte copy from the hardware buffer for fast response. This means it does not first clear the answer to 0 bytes and then copy - it just copies over the old. So for you example, the answer was 80 bytes - and then you tell it to read again - so it copies 20 bytes and stops, leaving the rest of the answer filled with old data.
As a work around for not seeing an end of file, you could first read the file size and then determine how many times you must read at 80 bytes and what the leftover is (in your example 20). This is how I solved it once.
Hello scott cunningham!
That was genius !! Absolutely brilliant , it worked like magic
Thank you so much for your reply, super helpful !!
Best Regards,
Anas