Milan / Paylink System Manual Issue 1.5 29 January 2020
CONFIDENTIAL
Not to be disclosed without prior written permission from Aardvark Embedded Solutions Ltd
Page 46 of 71
cctalk hopper processing
This is divided into two parts, the processing associate with reporting the ongoing ability of a
functioning hopper to pay out coins, and that associated with checking that the hopper is operational.
Both of these require a “Test Hopper” command to be sent to the unit, but the reporting mechanism is
different.
The ongoing ability to pay out is reported as the Status field in the dispenser block, the results of the
regular check are reported as “self test” events.
Note: that when a Payout is issued the results of the “self Test” are ignored - the dispense coins
command is dent to the hopper regardless.
On a regular basis the “Test Hopper” command is sent to the each hopper and the result evaluated.
After start-up, and regularly thereafter, a IMHEI_COIN_DISPENSER_NOW_OK is reported if there are no
errors.
The defined return from this command is a string of up to 4 bytes (depending upon the exact unit)
with one (or theoretically more) bits set to indicate the problem.
The action of Paylink is to regard these bytes as containing 32 bits. The bits are classified by this
section of Paylink as an Error, a Fraud attempt, a Payout result or “information only”. Paylink scans
along these bits looking for the first Error or Fraud bit that is non-zero. Other bits are ignored.
The bit number of this first bit (i.e. a number between 0 to 31) is then returned in RawEvent and an
EventCode of either IMHEI_COIN_DISPENSER_FRAUD_ATTEMPT or IMHEI_COIN_DISPENSER_REPORTED_
FAULT
To Next Page
Loading...