«Table of Contents Table of Contents Revision History Introduction Purpose of Document Intended Audience Associated Document(s) Naming Supported ...»
This document is the property of Aardvark Embedded Solutions Ltd and may not be reproduced in part or in total
by any means, electronic or otherwise, without the written permission of Aardvark Embedded Solutions Ltd.
Aardvark Embedded Solutions Ltd does not accept liability for any errors or omissions contained within this
document. Aardvark Embedded Solutions Ltd shall not incur any penalties arising out of the adherence to,
interpretation of, or reliance on, this standard. Aardvark Embedded Solutions Ltd will provide full support for this product when used as described within this document. Use in applications not covered or outside the scope of this document may not be supported. Aardvark Embedded Solutions Ltd. reserves the right to amend, improve or change the product referred to within this document or the document itself at any time.
Milan / Paylink System Manual Issue 1.2 1 August 2013 Table of Contents Table of Contents
Purpose of Document
PaySpecific Function (1.12.6)
End of payout processing.
Coin / Note Acceptor Usage Details
Token Handling (Coin Ids) (1.11.x)
Dual Currency Handling (Coin Ids) (1.11.x)
Route coins to a general cash box
Route specific coins to a specific cash box.
Route coins to a hopper until it is full then route it to a coin cash box.
Paylink Routing - Flow Diagram
Control of Motorised Acceptors
ccTalk bulk coin acceptor (1.11.3)
BCR / CR10x coin recyclers (1.11.5)
MDB changer / BCR / CR10x recycler support.
MDB tube level monitoring
Read out of Acceptor Details (1.11.x)
Coin / Note Dispenser Usage Details
Dispenser Power Fail support.
Detailed Device Support
Abandoning a payout in progress (1.11.3)
Control of unwanted bill payout (1.11.3)
Combi Hopper Support
Read out of Dispenser Details (1.11.x)
CONFIDENTIALNot to be disclosed without prior written permission from Aardvark Embedded Solutions Ltd Page 2 of 54 Milan / Paylink System Manual Issue 1.2 1 August 2013 Bill Recycler Operation (1.12.3)
DES Key Exchange
Notification of progress
Temporary power interruption
Full power Failure
Device Specific Functionality
Innovative NV11 Recycler (DES)
Innovative NV200 Recycler (DES)
JCM UBA Recycler
JCM Vega (DES) & JCM UBA Recycler
F56 / F53 Bill Dispenser
Extended Escrow (1.12.6)
Meters / Counters
Mechanical Meters (1.12.4)
Events (Faults / Auditing)
cctalk coin processing
cctalk note processing
cctalk hopper processing
ID-003 note processing
CCNet note processing
Command Line Options
CONFIDENTIALNot to be disclosed without prior written permission from Aardvark Embedded Solutions Ltd Page 3 of 54 Milan / Paylink System Manual Issue 1.2 1 August 2013 Limitations
Milan / Paylink Driver Program Configuration
Multiple Paylink Unit Support.
External Paylink Peripheral Specification
The Configuration File
CCTALK Device Definition
CCNet Device Definition
MDB Device Definition
Original Paylink Definition.
Introduction Purpose of Document This document describes the structure of a system using the AES Intelligent Money Handling Equipment Interface (Milan / Paylink), as seen by the person designing and setting up the system Intended Audience The intended audience of this document is the system engineer or programmer who is configuring the system that will be using Paylink.
Associated Document(s) This document is one of a pair that together cover creating and using a Paylink system. This document is written for the use of the person who is possibly not a programmer, but is concerned with designing and setting up the system centred around a Paylink unit. That document covers the configuration setting that are used to describe the units connected to Paylink, and the way in which such units are controlled.
The companion document “Milan / Paylink Application Program Interface Manual” is written for the use of programmers and covers the details of how to write the programs that interface to Paylink.
Naming The system described here has a few names. This section attempts to explain them.
AES Aardvark Embedded Solutions - us.
IMHEI Intelligent Money Handling Interface Equipment. This was the original name for the project, This was however difficult to say, and so was replaced in common use by Milan. It remains in the names in of the header files etc.
Milan This was originally the name of the first hardware build. It has however become the name of the overall project. Most documents from AES talk about Milan to cover the whole family of products that are used with this API Paylink This is the name of the USB module made and sold by Money Control under licence from
AES. There are at present three versions of Paylink:
Paylink The original, metal cased version.
Paylink Lite A much smaller, plastic cased version with a reduced function set.
uPaylink (Micro Paylink) a PC software only version, for use with Money controls USB peripherals.
PCI Card This is the original obsolescent hardware unit. It was known as Milan a long time ago, but this is its current name,
Supported Facilities It should be noted that this document cover all versions of the Milan / Paylink system, even those versions that are not yet generally available.
Where a facility may not be available with the version that you are running, the topic titles are suffixed with a version indication in brackets Version Numbering All AES software releases have a 4 part version number. This is made up from 4 separate fields,
M M Is a minor release, representing an upgrade in facilities or bug clearance, but where the application code will remain the same (both source and executable).
V V is a significant release, where the application will at a minimum need to be re-compiled, and where facilities may hay have changed to the point where the application code needs to change.
P P Is a product code. This is 1 for Paylink and is 25 for DES Paylink
LL Is the release level. This is a code, rather than a level, and has meaning as follows:
4 is a full release, and should never contain any errors or omissions. These release happen relatively rarely and a full history of the code is maintained. A code starting 4 uniquely identifies a particular build of the software.
3 is a beta release. This may contain errors as it has not been fully regression tested, but it is intended to be sufficiently stable that development, or even live running is possible. Again, a code starting 3 uniquely identifies a particular build of the software.
Normally the full release of a version will be almost identical to the beta release.
2 is an alpha release. These are only usually issued at the start of a major version. They should be stable and bug free, but are not fully tested, especially they will only have had minor regression testing. This release is to enable developers to “get started” with a new set of facilities. Again, a code starting 2 uniquely identifies a particular build of the software.
1 is an engineering release. These are generated during our internal development process, and are occasionally released to customers is response to specific requests. A build code of 1 can only be distinguished by the date / time stamp embedded in the code, and no internal record is kept of the items / changes that have gone into such a build.
This document is divided into three overall parts:
Concepts Where the document describes the ideas behind how Paylink works Details Where the specifics of how Paylink handles peripherals and situations are described Configuration Which defines the configuration file (which is essential to Paylink operation).
Paylink Installation All aspects of actually installing Paylink software on a target PC are described in the companion Application Program Interface document.
Money representation Within Paylink all monetary figures are in 32 bit integers, which represent an amount of money in terms of a single base unit. This would typically be pence or cents, but could be yen etc.
Where note acceptors are reading in high value notes, the acceptor will typically provide a conversion factor, which enables Paylink to convert the notes. A “normal” dollar / euro acceptor will provide a conversion factor of 100.
Acceptance All money acceptance is handled by means of updating total counters. Before starting operation, the application notes the current value of all the counters in which it is interested, and then monitors these counters for changes.
This serves to remove all needs for queuing and for spotting events from the system - there is no way that application can fail to have accurate information.
For the simplest application, there is a single total of all credit received. This actually totals the credit received for the life of the unit, and hence can also be used for auditing / security purposes.
For a more complex understanding of the money received, Paylink provides a block of information for each acceptor. As well as being able to use this block to disable specific coins / notes it also monitors the insertion of each coin / note. For each coin / note the total number accepted since the Paylink unit was reset is reported.
Payment Paylink provides two similar mechanisms for paying currency out from dispensers to the users of the system.
The original system used the Payout() function and with this the application specified the total amount, and Paylink would attempt to pay out sufficient of the available notes and coins to total the specified amount.
The new (1.12.6) precise pay system uses the SetDispenseQuantity() and PaySpecific() functions to pay out a precisely specified set of notes and coins.
Payout Function This method of paying money out using a Paylink is by calling the Payout() function, which takes a value in Paylink base units.
Paylink maintains a count of the total of all credit paid out for the life of the unit. This total is updated continuously as the process of paying money out proceeds, and can be used to check the amount of credit that has been paid out in the event of a payout being in progress when power is lost.
A Paylink is connected to one or more dispenser devices, which can be used to achieve this payout.
Internally Paylink holds these devices in descending order of value and when a pay command is issued it works down this list, paying as many base units as possible from each device in turn.
Each device request will be successful, or will result in nothing being paid, or will pay less than the requested amount.
Where either nothing or less than the requested amount is paid then Paylink will automatically issue another request on that device for the remainder. When two successive request have resulted in nothing being paid, then Paylink abandons the use of that device for this command, and will attempt to pay the outstanding balance from lower value.
The application can exert limited control over progress of a payment by disabling specific dispensers, which has the effect of causing the dispenser to ignored when selecting which units to use for a payment.
PaySpecific Function (1.12.6) The alternative method of paying money out using a Paylink is by calling the SetDispenseQuantity() function, once for each dispenser that is to be used for the payout to specify how many coins / notes are required from that..
When all the required calls have been made, a single call to the PaySpecific() function will Paylink to start processing the payout.
The call to the PaySpecific() function, will return the total amount to be paid in Paylink base units, in many ways subsequent processing is the same as a that triggered by a Payout() call for this value.
Internally Paylink holds these devices in descending order of value and it works down this list, paying as many base units as possible from each device in turn.
Each device request will be issued and the result used to update the Status of the relevant Dispenser.
If the application disables specific dispensers, this will still have the effect of causing the dispenser to be ignored when it is reached in this processing.
End of payout processing.
As money is paid out during either process, Paylink updates the total of all credit paid out.