Product Alert #45
Starlog Software Version 2 and Version 3 - Models 6300 and 6301
Incremental Unloads Losing Old Data
25 May 1998
Problem
This problem only affects schemes using the circular buffer option.
Incremental unloads can lose old data if enough time has passed since the previous unload for the logger to fill the buffer up and start overwriting data that has not been unloaded. The amount of time depends on the log size and the frequency of logging. Both software packages will display an estimate of this time when asked to show information about the scheme.
The result is that only a variable amount of recent data is unloaded. The data unloaded is valid (including time stamping), however, it is incomplete.
If you suspect you are experiencing this problem, you can perform a Full Unload to recover all of the logged data available on the logger.
If possible, this problem can be avoided completely by unloading the logger before it starts overwriting data that hasn't been unloaded.
Correction
Update Version 2 software to version 2.18 or later. Update Version 3 software to version 3.09 or later. Updates for both versions of the software are available from the
downloads page.
The changes made to the software packages will require you to resave any affected schemes, and then for the loggers to be reloaded with the scheme(s).
Users who have developed their own schemes, or modified the standard scheme skeleton supplied with the software should read the Technical Note below.
Technical Note for the curious
Inside the logger are several pointers related to the log data buffer. There is a start pointer that points to the beginning of the memory reserved for log data, an end pointer that points to the end of that reservered memory, and a current pointer that points to where any newly logged data will be written. The current pointer is (obviously) updated after every log. As data is logged the current pointer moves from the start pointer towards the end pointer. For linear (stop when full) buffers, when the current pointer gets to the end pointer it stops and the logger does not log any more data. For circular buffers, when the current pointer reaches the end pointer it resets itself to the start pointer and continues (it “wraps around”), overwriting the previously logged data.
Incremental unloads were designed such that after every unload the current pointer would be stored in a part of the loggers memory. When the user subsequently selected to perform an incremental unload, only the data logged between the stored current pointer and the “live” current pointer would be unloaded.
The problem described in this product alert occurs when the “live” current pointer has moved right around the buffer and gone past the bit of memory pointed to by the stored current pointer. As the logger is only capable of telling when the current pointer has “wrapped around” from the end back to the start, and not when the logger has passed the stored pointer, it does not realise that the current pointer has wrapped right around.
The problem has been fixed by counting how many times the current pointer wraps around from the end to the start and ignoring the buffer overflow flag (which can be derived from the overflow count anyway). This count is stored in the Buffer Control Table. The count is three bytes in size for Version 3 software and is stored at offsets 7-9 for standard buffers and offsets 6-8 for extended buffers (i.e. these offsets translate to addresses 263-265 and 261-263 respectively for Buffer #0). In Version 3 software this is where the “stored current pointer” was kept. That is now stored in a new *.IUP (Incremental Unload Pointer) file for each scheme, along with the overflow count and log start time. (By storing the incremental unload pointer in a file local to the computer, this also has the side-effect of allowing multiple users on different computers to perform their own incremental unloads without affecting any of the other user’s incremental unloads).
Version 2 software handles it slightly differently. For technical reasons, the counts are only two bytes long. They are stored in the Buffer Control Table at offsets 7-8 and 6-7 for Standard and Extended buffers respectively (or addresses 263-264 and 261-262 for buffer #0). The stored current pointer is kept on the logger (rather than in an external file) at memory addresses 42-43.
In order to maintain compatibility unloading loggers programmed before these modifications, a new bit has been allocated to signify “overflow counting”. It is bit #3 in the Buffer Status Flags (and is guaranteed to be zero in loggers programmed with older schemes).
Changes were made to the Version 3 unload script (PDLFUNL.CCF), and the Version 2 unload script (PDL_I.LCF). The version 2 changes also resulted in the Version 2 script interpreter (PDLIO.EXE) needing to be updated to version 2.24. It is included in the Version 2.18 software update.
|
