(CRITICAL) Upgrading from versions prior to version 28 of the Operating System will reset the datalogger’s CPU drive. This is due to a change in the format of the file system from FAT16 to FAT32. In order for the datalogger to operate correctly, as part of the upgrade, the CPU drive is formatted to FAT32. Any programs stored and running from the CPU drive will be lost. It is not recommended to update the datalogger’s Operating System over a remote connection where program control regulates the communication equipment (turning it on or off, etc.). In these cases, an on-site visit and a backup using DevConfig’s backup utility is necessary to update the datalogger’s Operating System.In all cases where the datalogger is being updated with an Operating System prior to 28, the use of DevConfig’s backup utility is recommended due to the fact that the CPU drive is formatted using the new FAT32 format.Watch the Video Tutorial: Sending an OS to a Local Datalogger.
Made a change to allow the use of “/” as a path delimiter when a directory listing is requested by LoggerNet during automated File Retrieval. Stricter matching of the expected path delimiter of “:” was introduced with version 28.00. The symptom was that when using LoggerNet 4.3 to retrieve files from a datalogger running OS 28.00, files could only be retrieved if the drive was omitted or if more than one file pattern entry was entered. For example, specifying usr:*.csv no longer worked when using LoggerNet 4.x with a datalogger using OS 28.00. The work around in LoggerNet was to specify a pattern that did not contain the drive name, for example *.jpg, or to add a second entry. The problem arose because the LoggerNet server was using a “/” character as the path delimiter instead of the “:” character.
Fixed GetDataRecord() by initializing an uninitialized pointer. The symptom was the process of running GetDataRecord() would corrupt the first variable in memory.
Fixed FTPClient() when using comma separated file names for LocalFileName. Introduced with OS version 28, the first comma in the list of file names was being replaced by a null character, causing FTPClient() to think only one file name was being specified, subsequently causing unexpected behavior.
Changed BRHalf() by returning to a new safe state (ready for Battery()). The symptom was a voltage spike was being generated on the SE channel when the BRHalf() instruction was not preceded by a Battery() instruction. This was found because of, but not limited to, an observed 10-15 deg measurement when the potentiometer of a 05103 was actually within its deadband.
Changed PPP to fix memory leak when the modem drops the connection but the datalogger did not detect the drop.
Changed the LwIP code to close IP connections without using additional memory. The symptom was that that datalogger in a heavy traffic TCP/IP environment was watchdogging. The LwIP code was modified so that when closing a connection it always calls the error call back function. This is done so that the API knows that the connection is truly closed. Previously it was looping and causing a doubling of pbufs which would eventually watchdog the datalogger.
Fixed a memory (TCP_PBUF) leak when a connection times out when waiting in a closed state or in a sync received state.
Modified the TCPOpen() server time-out so it now renews when transmitting data. Previously the timer only renewed incoming data.
Fixed VibratingWire() instruction so it now works. It was broken in OS 27.00.
TableFile 64 mode changed to close input and output TOB3 files when the tablefile output fails. This fixes a problem when the disk fills up in ring mode.
Fixed the data collection find record calculation to not request more records than will fit in the allocated output buffer. This was only for non-interval tables. With record sizes <= 8 bytes, there was a possibility of memory corruption if no table in the program had a record frame size < ~1600 bytes and the max PakBus packet size was set at 1000.
Fixed possible lock-up in file system if FAT is corrupted on a SD card. Prior to this fix, the card would have to be removed in order for the datalogger program to resume running.