SCH2 Technical Manual TSP016.doc Issue 3.0 – January 2005
Money Controls 2005. All rights reserved.
Page 41 of 61
Header 166: Request hopper status
Transmitted data :
<none>
Received data :
[ event counter ] [ payout coins remaining ]
[ last payout : coins paid ] [ last payout : coins unpaid ]
[ event counter ]
Every valid ‘Dispense hopper coins’ command increments the event counter. Valid means
there was no comms error in the command packet.
The event counter only has the value 0 at power-up or reset - if its value is 255 and another
dispense command is received then the event counter changes to 1. Then 2, 3, 4 etc.
The event counter is added for security reasons - if the reply to a ‘Dispense hopper coins’
command is corrupted or missing due to noise then the event counter should be checked
prior to re-transmitting the command to prevent over payout of coins. Correctly written host
software should always check the event counter before re-sending a dispense command.
[ payout coins remaining ]
After a ‘Dispense hopper coins’ command this counter is primed with the number of coins to
pay out. It then
decrements
with each coin dispensed until it reaches zero.
[ last payout : coins paid ]
The number of coins paid out in the last ‘Dispense hopper coins’ command. This counter
increments
as coins are being paid out.
[ last payout : coins unpaid ]
The number of coins which failed to be paid out in the last ‘Dispense hopper coins’
command. This counter is
cleared
during a payout.
As soon as a dispense hopper coins command is received, the status bytes are updated as
follows…
[ payout coins remaining ]
Ö
‘N coins’ /
decrements
as each coin is paid out
[ last payout : coins paid ]
Ö
Cleared to ZERO /
increments
as each coin is paid out
[ last payout : coins unpaid ]
Ö
Cleared to ZERO
When payout is completed ( success or abort ) then the status bytes become…
[ payout coins remaining ]
Ö
Cleared to ZERO
[ last payout : coins paid ]
Ö
Correct value for last operation
[ last payout : coins unpaid ]
Ö
Correct value for last operation
Host software should always wait for [ payout coins remaining ] to reach zero before
deciding what to do next.
Request hopper status : Coding Recommendations
Using life test results, Money Controls can now make the following coding
recommendations…
Polling the hopper status after a ‘Dispense hopper coins’ command is best done every
200ms
. It is essential that a retry mechanism is put in place such that if there is no reply to
the ‘Request hopper status’ command after
50ms
then it is sent again. The number of
sequential
retries allowed before a hardware fault is suspected should be set at around
10
.
The reason for the heavy retry mechanism is the electrical noise generated by the motor. If
suitable measures are taken in software then the serial communication link should be 100%
reliable and this has been confirmed by tests at Money Controls.
Summary of Contents for SCH2
Page 8: ......
