(Sorry, rambling error description)
I'm trying to track down an issue where - in some cases - reported meter readings (from CounterRead) don't appear to be correct. The problem occurs on a number of sites, although I've been unable to duplicate the error in-house. Instead, I've added extra debugging to the site software. Specifically, each call to CounterIncrement will now:
1. Call CounterIncrement(meterno,inc)
2. Call CounterRead(meterno), and store the value read back on the hard disk
3. Increment a simple integer value stored on the hard disk
When the software was installed, initial meter readings were taken (using CounterRead), so the difference between the start and end readings should equal the simple counter. On sites reporting discrepancies, the integer counter was greater than this difference - as if CounterIncrement hadn't actually incremented the meter, or CounterRead had returned an incorrect value.
I've also heard cases of meters reporting identical values (eg CASHIN meter reading equalling CASHOUT), but don't have any further information on this.
Anyone know of any issues with using CounterIncrement or CounterRead?
Starpoint Meters - Problems
Moderators: aardvark, davebush, Admin
Rick,
We however are aware of a problem with either the Starpoint meter, or our firmware, whereby the clock signal gets out of sync with the data. This results in a succession of faulty messages, followed by our handler resetting the meter and attempting to continue. It is possible to theoretically lose updates that were pending during this period, as the handler “starts again” at this point.
We now have code, in our 3.1.9.7 release, so that the meter protocol handler "expects" the meter to become faulty occasionally, and takes steps to ensure that updates are not lost during the recovery.
You do not say what release you are using. I assume it is running on the PCI based unit, and is 1.8.15.
I can either link you to 3.1.9.7 (which is a stable beta with a number of changes & improvements) of I could probably retro-fit the new meter handler into 1.8.15 to give you 1.8.16
We however are aware of a problem with either the Starpoint meter, or our firmware, whereby the clock signal gets out of sync with the data. This results in a succession of faulty messages, followed by our handler resetting the meter and attempting to continue. It is possible to theoretically lose updates that were pending during this period, as the handler “starts again” at this point.
We now have code, in our 3.1.9.7 release, so that the meter protocol handler "expects" the meter to become faulty occasionally, and takes steps to ensure that updates are not lost during the recovery.
You do not say what release you are using. I assume it is running on the PCI based unit, and is 1.8.15.
I can either link you to 3.1.9.7 (which is a stable beta with a number of changes & improvements) of I could probably retro-fit the new meter handler into 1.8.15 to give you 1.8.16
Aardvark software developer. Please put all communication on the problem through the board for the benefit of others.
Rich,
The firmware image for 4.1.8.17 at http://www.aardvark.eu.com/downloads/so ... 1-8-17.zip implements a new approach to driving the meter whereby it expects to have to reset the meter, and will remember increments over this process and perform them when the meter is again working.
I hope that this fixes your problem.
Dave Bush
The firmware image for 4.1.8.17 at http://www.aardvark.eu.com/downloads/so ... 1-8-17.zip implements a new approach to driving the meter whereby it expects to have to reset the meter, and will remember increments over this process and perform them when the meter is again working.
I hope that this fixes your problem.
Dave Bush
Aardvark software developer. Please put all communication on the problem through the board for the benefit of others.
The executable you've downloaded should happily reprogram any x.1.8.x issue of the firware.
Instead of a two file release, running "Program.exe" on a .a37 file, the .a37 file has been combined with an improved program.exe to give the executable you've now got.
I can give you the .a37, but I'd prefer you to try the executable you've got first.
Instead of a two file release, running "Program.exe" on a .a37 file, the .a37 file has been combined with an improved program.exe to give the executable you've now got.
I can give you the .a37, but I'd prefer you to try the executable you've got first.
Aardvark software developer. Please put all communication on the problem through the board for the benefit of others.