Dispenser.CoinCount Rolled Over From 255 to 0

[paulp]

Hi,
Have spent quite a while trying to track down the cause of a rare issue. I have just managed to reproduce it and in this particular instance it was caused by the dispenser's CoinCount changing from 255 to 0 when a note was recycled on a JCM iPro-RC. To us this looked like a dispense of -255 rather than a recycle of +1 as we expected. The documents state CoinCount is an integer, not a byte.

My Paylink.exe is v4.1.12.9 (even though I know there is a v4.1.12.10) and outputted the following
15:30:52.088 ID-003: Stack escrow note
15:30:55.020 ID-003: note 2 stacked to 2
15:30:55.020 ID-003: Entrance now clear
15:30:55.020 DP: Coin 2: saved
15:30:55.020 DP: ID-003 Status to 0
15:30:55.180 ID-003: Box 2, Stored count 256 updated to 0 ****

Would this have been different if I had been using 4.1.12.10 I wonder? I have tried writing back a value of 250 so I can retest, but that request appears to be rejected and I don't know why.
16:12:07.175 ID-003: Cmd Reject
16:12:07.478 ID-003: Update Box 1 from 59 to 250

I guess Ill find out after applying another 255 tests!

Thanks

Paul

[paulp]

We seem to have lost the update I posted on Friday.

Even with 4.1.12.10, after putting another 256 notes through I saw the Paylink log identify that it was storing the value of 256 as 0. On the next poll, I was the dispenser was reported as having a CoinCount of 0. I did originally post this evidence from the log but I don't have it anymore. I don't feel incline to stick another 256 notes through.

So it seems to me that even using the latest Paylink driver, the CoinCount is having a 8-bit boundary applied to it.

[davebush]

Hi,

This is just a placeholder. I'm following this up.

Dave

[davebush]

I am still waiting for a definitive reply from JCM, but so far as I know the situation is that:
1/ The iPro documentation only discusses up to 100 notes in the recycle unit.
2/ The message from the iPro regarding the recycle unit contents is only defined a single byte.

This would imply that the although this is a bug in the system, the bug is located in the internal design of the iPro unit.

If you regularly intend to keep track of more than 255 notes in a recycle unit I'm afraid you will have to spot this overflow (and it's corresponding underflow) in your own code.

(As the number of coins in the recycle unit is unreliable (due to the ability of the operator to remove and replace them) Paylink pays no attention internally to this field, and will happily queue a Payout to a unit reporting zero.)

Regards

Dave