Cashcode Net Interface
Uploaded by
bmorrissCashcode Net Interface
Uploaded by
bmorrissCashCode NET
Interface
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 1 of 98
Contents
1......................................................................................................General Information
.........................................................................................................................................4
1.1
Introduction.................................................................................................................................................. 4
1.2
Operational and Application Notes............................................................................................................... 4
2...............................................................................................Communication Format.
.........................................................................................................................................5
2.1
Data format.................................................................................................................................................. 5
2.2
Message Format.......................................................................................................................................... 5
2.3
Transmission and reception message formats............................................................................................. 8
2.4
Peripheral Addresses................................................................................................................................... 9
2.5
Software Operational Rules......................................................................................................................... 9
2.6
Typical Session Examples......................................................................................................................... 10
2.7
Timing Definitions...................................................................................................................................... 12
2.8
Timing Specifications................................................................................................................................. 12
3.........................CONTROLLER/BILL-TO-BILL UNIT Communication Specification
.......................................................................................................................................13
3.1
Introduction................................................................................................................................................ 13
3.2
Command Protocol.................................................................................................................................... 13
3.3
Controller Commands................................................................................................................................ 13
3.4
Controller Command Format..................................................................................................................... 14
4..............................CONTROLLER/COIN CHANGER Communication Specification
.......................................................................................................................................25
4.1
Introduction................................................................................................................................................ 25
4.2
Command Protocol.................................................................................................................................... 25
4.3
Controller Commands................................................................................................................................ 25
4.4
Controller Command Format..................................................................................................................... 25
5.............................CONTROLLER/BILL VALIDATOR Communication Specification
.......................................................................................................................................32
5.1
Introduction................................................................................................................................................ 32
5.2
Command Protocol.................................................................................................................................... 32
5.3
Controller Commands................................................................................................................................ 32
5.4
Controller Command Format..................................................................................................................... 33
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 2 of 98
6....................................CONTROLLER/ Card Reader Communication Specification
.......................................................................................................................................45
6.1
Introduction................................................................................................................................................ 45
6.2
Card Reader States................................................................................................................................... 45
6.3
Command Protocol.................................................................................................................................... 46
6.4
Controller Commands................................................................................................................................ 46
6.5
Controller Command Format..................................................................................................................... 46
6.6
Non-Response Time................................................................................................................................... 52
7..................................................APPENDIX Example CCNET Message Sequences
.......................................................................................................................................53
7.1
Power Up & Reset sequence..................................................................................................................... 54
7.2
Enable sequence....................................................................................................................................... 54
7.3
Disable sequence....................................................................................................................................... 55
7.4
Bill Accept sequence (Bill stacked)............................................................................................................ 55
7.5
Bill Accept sequence (Bill returned)........................................................................................................... 56
7.6
Bill Dispense sequence (Bill dispensed).................................................................................................... 57
7.7
Bill Unload sequence (Bill unloaded)......................................................................................................... 58
7.8
Set cassette type sequence....................................................................................................................... 59
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 3 of 98
1
1.1
General Information
Introduction
This document defines a serial network interface. The interface is Master-Slave arrangement
where all peripherals are Slave to a Master Controller.
1.2
Operational and Application Notes
The serial network interface, or serial bus interface, is configured for Master- Slave operation.
There is one Master with the capability of communicating with some peripherals. The Master is
defined as Controller and Slave as Peripheral.
Each peripheral is assigned a unique address and command set. The Controller will poll the
Bus for Peripheral activity. That is, each Peripheral is asked for activity, and responds with
either acknowledge, negative acknowledge, invalid command acknowledge, or specific data
dependent on its current activity. If a Peripheral does not respond within a predefined time, (tnon-response as defined in the peripheral sections) it is assumed that it is not present on the
Bus.
Bus interference or crashes are prevented because each Peripheral only responds upon
being polled.
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 4 of 98
2
2.1
Communication Format.
Data format
Baud Rate: 9600 bps/19200 bps (no negotiation, hardware selectable)
Start bit:
Data bit:
8 (bit 0 = LSB, bit 0 sent first)
Parity:
Stop bit:
2.2
Parity none
1
Message Format
SY
SY
N
C
A
D
R:
LN
G
C
M
D
DA
TA
C
R
C
LN
G
DA
TA
C
R
1 byte
Message transmission start code [02H], fixed
1 byte
Peripheral address
1 byte*
1 byte
Data length (Total number of bytes including SYNC
and CRC)
Command
0 to 250
bytes
2 bytes
Data necessary for command (omitted if not required
by CMD)
Check code by CRC method, LSB first
Object section to be from and including SYNC to end
of DATA
(Initial value = 0)
Error control method:
Error detection CRC method
CRC - CCITT using whole byte shifting into a two-byte frame
P(X) = X16 + X12 + X5 + l
* if a package cannot be fitted into 250-byte frame a wider frame may be used by setting LNG
to 0; the actual packet length is inserted into DATA block bytes 0 and 1 if CMD (if present in the
frame) does not require subcommand, otherwise in DATA block bytes 1 and 2; two-byte LNG
always follows MSB first.
case 1 (CMD present, no subcommand):
SYN
AD
CM
L
N
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
L
N
DAT
CRC
Page 5 of 98
G
H
I
G
H
L
O
W
case 2 (CMD present, subcommand present):
SYN
AD
L
N
G
S
U
B
C
M
D
CM
L
N
G
H
I
G
H
DAT
CR
L
O
W
case 3 (CMD not present, no subcommand):
SYN
AD
L
N
G
H
I
G
H
L
N
G
DAT
CRC
L
O
W
This allows accommodation of data packages of up to 65528 bytes; please keep in mind that
lengthy exchanges compromise bus bandwidth.
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 6 of 98
Example of CCNET CRC calculation using C-language source code:
#define POLYNOMIAL 0x08408
unsigned int GetCRC16(unsigned char* bufData, unsigned int
sizeData)
{
unsigned int TmpCRC, CRC, i;
unsigned char j;
CRC = 0;
for(i=0; i < sizeData; i++)
{
TmpCRC = CRC ^ bufData[i];
for(j=0; j < 8; j++)
{
if(TmpCRC & 0x0001) {TmpCRC >>= 1; TmpCRC ^= POLYNOMIAL;}
else TmpCRC >>= 1;
}
}
return CRC;
}
Example of CCNET CRC calculation using PASCAL-language source code:
const _CR_CCNET_CRC_POLY = $08408
function GetCRC16(InData: array of byte; DataLng: word): word;
var i,TmpCRC: word;
j: byte;
begin
result:=0;
for i:=0 to (DataLng-1) do
begin
TmpCRC:=result xor InData[i];
for j:=0 to 7 do
begin
if (TmpCRC and $0001)<>0 then
begin
TmpCRC:=TmpCRC shr 1;
TmpCRC:=TmpCRC xor _CR_CCNET_CRC_POLY;
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 7 of 98
end
else
TmpCRC:=TmpCRC shr 1;
end;
result:=TmpCRC;
end;
end;
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 8 of 98
2.3
Transmission and reception message formats
Transmission and reception message format is divided into the following four types.
(1) Command transmission CONTROLLER to PERIPHERAL
SYNC
SYNC :
ADR :
LNG :
CMD :
DATA :
CRC :
ADR
LNG
CMD
DATA
CRC
[02H]
Peripheral address
Data length
Command
Data necessary for command (omitted if not required by CMD)
Check code by CRC method
(2) ACK response PERIPHERAL to CONTROLLER/ CONTROLLER to PERIPHERAL
SYNC
SYNC :
ADR :
LNG :
DATA :
CRC :
ADR
LNG
DATA
CRC
[02H]
Peripheral address
[06H]
[00H]
Check code by CRC method
(3) NAK response PERIPHERAL to CONTROLLER/ CONTROLLER to PERIPHERAL
SYNC
SYNC :
ADR :
LNG :
DATA :
CRC :
ADR
LNG
DATA
CRC
[02H]
Peripheral address
[06H]
[FFH]
Check code by CRC method
Sent in PERIPHERAL to CONTROLLER direction if command from controller was not correctly received.
(4) Response message PERIPHERAL to CONTROLLER
SYNC
SYNC :
ADR :
LNG :
DATA :
CRC :
ADR
LNG
DATA
CRC
[02H]
Peripheral address
Data length
Responses Data
Check code by CRC method
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 9 of 98
(5) ILLEGAL COMMAND Response message PERIPHERAL to CONTROLLER
SYNC
SYNC :
ADR :
LNG :
DATA :
CRC :
ADR
LNG
DATA
CRC
[02H]
Peripheral address
[06]
[30H]
Check code by CRC method
Sent by the PERIPHERAL if command from CONTROLLER is not valid in reference to the current
peripheral state.
2.4
Peripheral Addresses
The addresses below are defined.
2.5
Address
Definition
00H
01H
02H
03H
04H
05H
.
.
.
0DH
0EH
0FH
Forbidden
Bill-to-Bill unit
Coin Changer
Bill Validator
Card Reader
Reserved for Future Standard Peripherals
.
.
.
Reserved for Future Standard Peripherals
Reserved for Future Broadcast Transmissions
Reserved for Future Standard Peripherals
Software Operational Rules
During multi-byte messages the most significant byte is sent first.
If the Peripheral has not responded to a poll for its maximum non-response time, the Controller must
continue to poll the Peripheral at least every ten seconds with a RESET command.
All messages, from Controller or Peripheral, must be sent as quickly as possible. There is no
minimum tresponse time. All data block transmissions must be started within 10 mS.
Any data (bytes or bits) within a command or response that are not specifically defined must be left in
a 0 state.
The Controller may reset Peripheral by sending the signal BUS RESET for a minimum of 100 mS.
This informs Peripheral to abort any activity and return to its power-on reset state. It is recommended
that the Controller re-initialize each Peripheral after this type of reset. WARNING: BUS RESET is
device and implementation dependant and may not be present within some devices.
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 10 of 98
2.6
Typical Session Examples
The Controller must respond to data from a Peripheral with an Acknowledgment (ACK) or
Negative Acknowledgment (NAK) message. The 10 mS time-out (t-response) described in the
Timing section of this document is the equivalent of a NAK message.
A Peripheral must respond to command from the Controller with response message, or ACK
message, or NAK message. The 10 mS time-out (t-response) described in the Timing section
of this document is the equivalent of a NAK message.
The tfree must be obeyed by the Controller between the end of any ACK or NAK confirmation
response and start of the next command transmission. Currently t free is defined as 10 mS of Bus
silence, but for reliable operation of future multi-device buses the recommended value of t free is
20mS.
2.6.1
The diagram below represents a typical transmission when PERIPHERAL has no data to return.
Controller
ller
r
l
er
2.6.2
Command
Peripheral
ACK message
d
Less or equal to 10 mS
The diagram below represents a typical transmission when PERIPHERAL has data to return.
Controller
Peripheral
Poll command
Status
Less or equal to 10 mS
ACK message
From 100 to 200 mS
Poll command
Bus silence of tfree msec
Status
ACK message
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 11 of 98
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 12 of 98
2.6.3
The diagram below represents a typical transmission when the Controller determines a CRC is not
correct.
Controller
Peripheral
Poll Command command
Status
Less or equal to 10 mS
NAK message
From 100 to 200 mS
Poll command
Bus silence of tfree msec
Status
ACK message
2.6.4
The diagram below represents a typical transmission when Peripheral determines a CRC is not
correct. The Peripheral responds by sending a NAK message to the Controller to indicate that the
information was not received correctly.
Controller
Peripheral
Poll Command command
NAK message
Less or equal to 10 mS
Poll command
From 100 to 200 mS
Status data
ACK message
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 13 of 98
2.7
Timing Definitions
Baud rate
tinterbyte(max.)
tresponse(m
ax.)
tbus
reset(min.)
tnon-
2.8
The rate of bit transfer per second
The maximum time allowed between bytes in a block
transmission
The maximum time Peripheral will take to respond to a
valid communication
The minimum time of sending signal BUS RESET
response
(max.)
tpoll
The maximum non-response time
tfree
The interval of time between confirmation ACK or NAK and
next command
The interval of time between two commands Poll
Timing Specifications
Baud Rate
tinterbyte(max.)
tresponse(m
ax.)
tbus
reset(min.)
Tnon-
9600/19200 +1%/-2% NRZ (nonreturn to zero), non-negotiable,
hardware selectable
5.0 ms
10.0 ms
100 ms
5.0 S
tfree
10 ms (recommended 20 ms or
more)
response
(max.)
tpoll
100-200 ms
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 14 of 98
3
3.1
CONTROLLER/BILL-TO-BILL UNIT Communication Specification
Introduction
This section defines the communication bytes sent and received between Bill-to-Bill unit and
the Controller. Unless stated otherwise, all information is assumed to be in a hexadecimal
format. The Bill-to-Bill units address is 01H.
3.2
Command Protocol
The IDENTIFICATION, GET BILL TABLE and DOWNLOAD commands may be sent by the
Controller when Bill-to-Bill unit is in the following states only: Power up, Initialise or Unit
Disabled. If a command cannot be executed by the Bill-to-Bill unit in a given state COMMAND
INVALID response is issued.
3.3
Controller Commands
Command
RESET
GET STATUS
SET SECURITY
POLL
ENABLE BILL
TYPES
STACK
RETURN
H
E
X
C
o
d
e
3
0
H
3
1
H
3
2
H
3
3
H
3
4
H
3
5
H
3
6
H
Description
Command for Bill-to-Bill unit to self-reset
Request for Bill-to-Bill unit set-up status
Sets Bill-to-Bill unit Security Mode.
Command is followed by set-up data. See
command format
Request for Bill-to-Bill unit activity Status
Indicates Bill Type enable or disable.
Command is followed by set-up data. See
command format
Sent by Controller to stack a bill in escrow
into drop cassette or into one of the
recycling cassettes
Sent by Controller to return a bill in escrow
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 15 of 98
IDENTIFICATION
HOLD
CASSETTE
STATUS
DISPENSE
UNLOAD
ESCROW
CASSETTE
STATUS
ESCROW
CASSETTE
UNLOAD
SET CASSETTE
TYPE
GET BILL TABLE
DOWNLOAD
(see details for
subcommands)
3
7
H
3
8
H
3
B
H
3
C
H
3
D
H
3
E
H
3
F
H
4
0
H
4
1
H
5
0
H
Request for Model, Serial Number,
Software Version of Bill-to-Bill unit, Country
ISO code, Asset Number
Command for holding the Bill-to-Bill unit in
Escrow state
Request for Bill-to-Bill unit cassette status
Command to dispense a bill of specific type
Command to unload bills from recycling
cassette(s) to drop cassette
Request for recycling cassette(s) status
Command for routing bills to recycling
cassette(s)
Assigns cassettes to bill types
Request for bill type assignments
Command for transition to download mode.
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 16 of 98
3.4
Controller Command Format
RESET
Controller Command
Code
Controller Data
RESET
30H
No data bytes
This command is used to tell the Bill-to-Bill unit that it must return to its default operating mode.
It must abort all communication, reject any bills in the validation process, return any bills in the
escrow position, and disable all other activity until otherwise instructed by the Controller.
GET STATUS
Controller Command
GET STATUS
Z
1
Z
3
Z
4
Z
6
Z
7
Z
9
Code
31H
Bill-to-Bill unit Response Data
9 bytes: Z1 Z9
Bill Type, 3 bytes. Indicates the bill enables for bill types 0 to 23.
Bill Security Levels, 3 bytes. Indicates the security level for bill types 0 to 23.
Bill Type Routing, 3 bytes. Indicates what bill types can be routed to the Bill-toBill units cassettes. Valid bill types are 0 to 23.
Bill Type
Byte Z1
Byte Z2
Byte Z3
bits
bits
bits
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
Bill types enabled if bits set
23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Bill Security Levels
Byte Z4
bits
Byte Z5
bits
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Byte Z6
bits
Page 17 of 98
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
Bill types set to high security if bits set
23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Bill Type Routing
Byte Z7
Byte Z8
Byte Z9
bits
bits
bits
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
Bill types can be routed if bits set
23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 18 of 98
SET SECURITY
Controller Command
Code
Controller Data
SET SECURITY
32H
3 Bytes: Y1 Y3
Byte Y1
Byte Y2
Byte Y3
bits
bits
bits
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
Bill types set to high security if bits set
23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
A bit is set to indicate the type of bill(s), which are set to a high security level.
POLL
Controller Command
POLL
Code
Bill-to-Bill unit Response Data
33H
1 or 2 bytes: Z1 or Z1- Z2
Indicates status of the Bill-to-Bill unit and its activity. The Bill-to-Bill unit may send 1or 2 of the
following data bytes:
Resp
onse
data
bytes
Z
1
1
0
H
1
1
H
1
2
H
1
2
H
Description
Power Up
The state of Bill-to-Bill unit after power up
Power Bill
Power up with bill in validating head. After a
RESET command from the Controller, the
Bill-to-Bill unit returns the bill and continues
initializing.
Power up with bill in Bill-to-Bill unit. Always followed by location byte (see
below).
00H
Power up with bill in transport section. After a
Power w/Bill in
RESET command from the Controller, the
Transport Path
Bill-to-Bill unit stacks the bill to the drop
cassette and continues initializing.
01H
Power w/Bill in
Power up with bills in dispenser. After a
RESET command from the Controller, the
Dispenser
Bill-to-Bill unit returns the bills to exit bezel
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 19 of 98
1
3
H
1
4
H
1
5
H
1
7
H
Initialize
1
8
H
Returning
Idling
1
9
H
1
A
H
1
B
H
1
C
H
1
C
H
1
C
H
1
C
H
1
C
H
1
C
H
Accepting
In this state Bill-to-Bill unit executes scanning
of a bill and determines its denomination.
Stacking
In this state, the Bill-to-Bill unit transports a
bill from Escrow position to the recycling
cassette or to the drop box and remains in
this state until the bill is stacked or returned if
jammed.
In this state Bill-to-Bill unit transports a bill
from Escrow position to entry bezel and
remains in this state until the bill is removed
by customer.
The Bill-to-Bill unit has been disabled by the
Controller and also the state in which Bill-toBill unit is after initialization
The state, in which the bill is held in Escrow
position after the HOLD command from the
Controller.
The state, in which Bill-to-Bill unit cannot
answer a detailed command right now. On
expiration of time YH, peripheral is
accessible for polling. YH is expressed as
multiple of 100 milliseconds.
Unit Disabled
Holding
and continues initializing.
The state, in which Bill-to-Bill unit executes
initialization after RESET command from the
Controller.
In this state Bill-to-Bill unit waits for bill
insertion.
Device Busy
Generic rejecting code. Always followed by rejection reason byte (see below).
60H
Rejecting due
to Insertion
Insertion error
61H
Rejecting due
to Magnetic
Magnetic error
62H
Rejecting due
to bill
Remaining in
the head
Bill remains in the head, and new bill is
rejected.
63H
Rejecting due
to Multiplying
Compensation error/multiplying factor error
64H
Rejecting due
to Conveying
Conveying error
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 20 of 98
1
C
H
1
C
H
1
C
H
1
C
H
1
C
H
1
C
H
1
C
H
65H
Rejecting due
to
Identification1
Identification error
66H
Rejecting due
to Verification
Verification error
67H
Rejecting due
to Optic
Optic error
68H
Rejecting due
to Inhibit
Return by inhibited denomination error
69H
Rejecting due
to Capacity
Capacitance error
6AH
Rejecting due
to Operation
Operation error
6CH
Rejecting due
to Length
Length error
1
D
H
Dispensing
Bill-to-Bill unit enters this state after
DISPENSE command. In this state Bill-to-Bill
unit transports a bill from recycling
cassette(s) to customer through dispenser
and remains in this state until the bill(s) are
removed by customer or jammed.
1
E
H
Unloading
Transporting bills to drop cassette.
1
F
H
Custom
returning
2
0
H
Recycling
unloading
2
1
H
Bill-to-Bill unit pass to this state after
RECYCLING CASSETTE UNLOAD
command if high bit of data byte is set. In
this state Bill-to-Bill unit transports bill(s) from
recycling cassette to customer through
dispenser and remains in this state until the
customer removes the bill(s).
Bill-to-Bill unit passes to this state after
RECYCLING CASSETTE UNLOAD
command if high bit of data byte is dropped.
In this state Bill-to-Bill unit transports bill from
recycling cassette to recycle cassette of
appropriate bill type or to drop cassette.
Setting
cassette type
Unloading of the recycling cassette is carried
out and cassette is reassigned to new bill
type
2
5
H
Dispensed
Dispensing is completed.
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 21 of 98
2
6
H
2
7
H
2
8
H
2
9
H
3
0
H
4
1
H
4
2
H
4
3
H
4
4
H
4
5
H
Unloading is completed
Custom bills
returned
Bills are returned to customer.
Recycling
cassette
unloaded
Recycling Cassette unloading is completed.
Set cassette
type
Setting recycling cassette type is completed.
Invalid
command
Command from the Controller is not valid.
Drop Cassette
Full
Drop Cassette full condition
Drop Cassette
out of position
The Bill-to-Bill unit has detected the drop
cassette to be open or removed.
Bill Validator
Jammed
Bill(s) are jammed in the acceptance path.
Cassette
Jammed
A bill are jammed in drop cassette.
Cheated
4
6
H
4
7
H
4
7
H
4
7
H
4
Unloaded
Pause
The Bill-to-Bill unit sends this event if the
intentions of the user to deceive the Bill-toBill unit are detected.
The Bill-to-Bill unit reaches this state when
the user tries to insert a bill before the
previous bill is stacked. Bill-to-Bill unit stops
motion of the bill until the entry channel is
cleared.
Generic Failure codes. Always followed by failure description byte (see below).
50H
51H
52H
Stack Motor
Failure
Transport
Motor Speed
Failure
Transport
Drop Cassette Motor failure
Transport Motor Speed out of range
Transport Motor failure
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 22 of 98
7
H
4
7
H
4
7
H
4
7
H
4
7
H
4
7
H
4
7
H
4
7
H
4
7
H
4
7
H
4
7
H
4
7
H
4
7
H
4
7
H
Motor Failure
53H
Aligning Motor
Failure
Aligning Motor failure
54H
Initial Box
Status Failure
Initial cassette Status failure
55H
Optic Canal
Failure
One of the optic sensors has failed to
provide its response.
56H
Magnetic
Canal Failure
Inductive Sensor failure
57H
Cassette 1
Motor Failure
Recycling Cassette 1 Motor Failure
58H
Cassette 2
Motor Failure
Recycling Cassette 2 Motor Failure
59H
Cassette 3
Motor Failure
Recycling Cassette 3 Motor Failure
5AH
Bill-to-Bill unit
Transport
Motor Failure
One of the Bill-to-Bill unit Transport Motors
failure
5BH
Switch Motor 1
Failure
Switch Motor 1 Failure
5CH
Switch Motor 2
Failure
Switch Motor 2 Failure
5DH
5EH
5FH
Dispenser
Motor 1
Failure
Dispenser
Motor 2
Failure
Capacitance
Canal Failure
Dispenser Motor 1 Failure
Dispenser Motor 2 Failure
Capacitance sensor failed to respond
Bill-to-Bill unit Jammed. Always followed by location byte (see below).
4
8
H
4
8
H
4
70H
Bill Jammed in
Cassette 1
A bill is jammed in Recycling Cassette 1
71H
Bill Jammed in
Cassette 2
A bill is jammed in Recycling Cassette 2
72H
Bill Jammed in
A bill is jammed in Recycling Cassette 3
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 23 of 98
8
H
4
8
H
4
8
H
4
8
H
Cassette 3
73H
Bill Jammed in
Transport Path
A bill is jammed in Transport Path
74H
Bill Jammed in
Switch
A bill is jammed in Switch
75H
Bill Jammed in
Dispenser
A bill is jammed in Dispenser
Events with credit.
8
0
H
8
1
H
8
2
H
Escrow
position
Y = bill type (0 to 23)
Bill stacked
Y = bill type (0 to 23)
Bill returned
Y = bill type (0 to 23)
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 24 of 98
ENABLE BILL TYPES
Controller Command
Code
Controller Data
ENABLE BILL TYPES
34H
6 bytes: Y1 Y6
Byte Y1
Byte Y2
Byte Y3
bits
bits
bits
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
Bill types enabled if bits set
23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
NOTE: Sending 000000H disables the Bill-to-Bill unit.
Byte Y4
Byte Y5
Byte Y6
bits
bits
bits
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
Bill types with escrow enabled if bits set
23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
NOTE: On power-up or reset all bill acceptance and escrow are disabled.
STACK
Controller Command
Code
STACK
Controller Data
35H
No data bytes
This command forces a bill in escrow position to be sent to drop cassette or one of the
recycling cassettes.
NOTE: After a STACK command the Bill-to-Bill unit should respond to a POLL command with
the BILL STACKED message within 30 seconds. If this command is sent when the Bill-to-Bill
unit is not in ESCROW state the ILLEGAL COMMAND message is returned.
RETURN
Controller Command
Code
Controller Data
RETURN
36H
No data bytes
This command causes the Bill-to-Bill unit to return a bill in escrow position to the customer.
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 25 of 98
NOTE: After a RETURN command the Bill-to-Bill unit should respond to a POLL command
with the BILL RETURNED message within 30 seconds. If this command is sent when the Billto-Bill unit is not in ESCROW state the ILLEGAL COMMAND message is returned.
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 26 of 98
IDENTIFICATION
Controller Command
Code
Bill-to-Bill unit Response Data
IDENTIFICATION
37H
34 bytes:
B
y
t
e
s
Z
1
Z
1
5
Z
1
6
Z
2
7
Z
2
8
Z
3
4
Z1 Z34
Description
Part Number 15 bytes, ASCII characters
Serial Number 12 bytes Factory assigned serial number, ASCII
characters
Asset Number 7 bytes, unique to every Bill Validator, binary
data
Bytes Z1-Z27 must be sent as ASCII Characters. Zero (30H) and Blank (20H) are acceptable.
Asset Number must be sent as binary code.
15 bytes
BB-US1701
12 bytes
00K038AS3419
7 bytes
Binary code
Asset Number
Serial Number
Part Number
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 27 of 98
HOLD
Controller Command
HOLD
Code
Controller Data
38H
No data bytes
This command allows the Controller to hold Bill-to-Bill unit in a state Escrow during 10 s. After
this time the Controller should send the STACK or RETURN command. For continued holding
in an Escrow state it is necessary to resend this command. Otherwise Bill-to-Bill unit will
execute return of a bill.
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 28 of 98
CASSETTE STATUS
Code
Bill-to-Bill unit Response
CASSETTE STATUS
3BH
32 bytes: Z1-Z32
Z1-Z32
Controller Command
Data
Cassette Status 32 bytes.
Indicates the greatest number of bills that the Bill-to-Bill unit knows definitely is present in the bill
cassettes. The 32-byte string consists from 16 two-byte words. Each two-byte position in the 32-byte
string indicates the number of cassette. For example, the first two bytes sent indicate the number of
cassette 1. First byte of word has the following format:
(abc zzzzz)
If a = 0 Cassette not present.
If b = 1 Cassette hasnt any type (type NULL).
If c = 1 Cassette has type ESCROW.
zzzzz - Type of bill. This bits is valid if bits b,c = 0 and a = 1 only
Second byte of word indicates number of bills in cassette.
Unsent bytes are assumed to be zero.
DISPENSE
Controller Command
Code
Controller Data
DISPENSE
3CH
27 bytes: Y1-Y27
Y1-Y3
dispensed.
Bill Type to be dispensed - 3 bytes. A bit is set to indicate bill type to be
Byte Y1
Byte Y2
Byte Y3
bits
bits
bits
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
Bill Types to be dispensed if bits set
23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Y4-Y27
These bytes contain number of bills to dispense for those types, which are specified in
bytes Y1-Y3. Zero bytes are not sent. For example, if in bytes Y1-Y3 two bits are set, Y4
and Y5 will be sent only.
NOTE: The total number of bills to dispense must not exceed 20 bills.
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 29 of 98
UNLOAD
Controller Command
Code
Controller Data
UNLOAD
3DH
2 bytes: Y1-Y2
This command unloads the bills from the recycling cassettes to drop cassette.
Y1
Cassette number code
Y2
Iindicates the number of bills to be unloaded.
EXTRA CAPABILITIES RECYCLING CASSETTE COMMANDS
RECYCLING CASSETTE STATUS
Controller Command
Code
Bill-to-Bill unit Response Data
RECYCLING CASSETTE
3EH
1 byte: Z1
Z1
(Fyyy yyyy)
F = Recycling Cassette Full Status.
yyy yyyy = number of bills in the recycling cassette.
NOTE:
If a Bill-to-Bill unit can detect a cassette jam, defective cassette sensor, or
other malfunction, it will indicate the cassette is bad by sending a recycling
cassette full status and a count of zero.
RECYCLING
UNLOAD
CASSETTE
Controller Command
Code
Controller Data
RECYCLING CASSETTE
3FH
1 byte: Y1
Y1
(Dyyy yyyy)
If Y1 = 1yyy yyyy; yyyy yyy = Number of bills to return to customer.
If Y1 = 0; Unload one bill to recycling cassette of appropriate bill type or drop
cassette
Command for routing bills from recycling cassette. This command allows returning
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 30 of 98
customer bills in case of cancelling.
NOTE: The total number of bills must not exceed 20 bills.
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 31 of 98
SET
RECYCLING
CASSETTE TYPE
Controller Command
Code
Controller Data
SET RECYCLING CASSETTE TYPE
40H
2 bytes: Y1-Y2
Command for assigning recycling cassette bill type. If the cassette is not empty, the command
forces complete unloading of the cassette.
Y1
Y2
Number cassette code
(abc zzzzz)
If a = 1 Cassette is present.
If b = 1 Lets Cassette type NULL.
If c = 1 Lets Cassette type ESCROW.
Only one of this bit can be set. zzzzz - Type of bill. This bits is valid if bits b,c = 0
and a = 1 only
Notes: It is strongly recommended to send RECYCLING CASSETTE STATUS command before
sending SET RECYCLING CASSETTE STATUS TYPE command to assure proper cassette
type assignment.
GET BILL TABLE
Controller Command
Code
Bill-to-Bill unit Response Data
GET BILL TABLE
41H
120 bytes: Z1-Z120
Command for request bill type description.
Z1-Z120
The 120 - byte string consists of 24 five-byte words.
Byte 1 of word most significant digit of the denomination.
Bytes 2-4 of word country code in ASCII characters.
Byte 5 of word decimal placement or proceeding zeros. If bit D7 is 0, the bits D0D6 indicate the number of proceeding zeros. If bit D7 is 1, the bits D0-D6 indicates the decimal
point position starting from the right and moving to the left.
A five-byte position in the 120-bytes string indicates bill type description for the particular bill
type. For example, first five bytes correspond to bill type=0, second five bytes correspond to bill
type=1 and so on.
Example:
Den
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Den
Den
Page 32 of 98
il
l
T
y
p
e
omi
nati
on
Cod
e
First
Byte
0x1
0x2
0x5
0x5
0x1
9
o
u
n
t
r
y
C
o
d
e
3
b
y
t
e
s
I
T
L
I
T
L
I
T
L
N
L
C
omi
nati
on
Cod
e
Sec
ond
Byte
omi
nati
on
0x3
1,00
0
Lir
a
0x3
2,00
0
Lir
a
0x3
5,00
0
Lir
a
0x8
2
.05
N
L
C
0x8
2
.25
0x1
9
N
L
C
0x8
1
2.5
0x1
9
N
L
C
0x0
25
0x1
9
N
L
C
0x2
250
0
0x1
0x0
0x5
U
S
A
U
S
0x0
Cr
o
w
n
Cr
o
w
n
Cr
o
w
n
Cr
o
w
n
Cr
o
w
n
D
oll
ar
D
oll
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 33 of 98
A
1
0x1
U
0
S
A
1
0x2
U
1
S
A
Unsent bytes are assumed to be zero.
0x1
10
0x1
20
ar
D
oll
ar
D
oll
ar
DOWNLOAD
Controller Command
DOWNLOAD
Code
Controller Data
50H
1 byte: Y1
Y1 subcommand byte.
This command is not implemented in current Bill-to-Bill unit software releases and will always
return an INV response.
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 34 of 98
4
4.1
CONTROLLER/COIN CHANGER Communication Specification
Introduction.
This section defines the communication bytes sent and received by a Coin Changer. The Coin
Changers address is 02H. Unless stated otherwise, all information is assumed to be in
hexadecimal format.
The coin changer must be compatible with Controller that is designed according to the
operational rules defined earlier in this document.
4.2
Command Protocol
The commands IDENTIFICATION, GET COIN TABLE, and DOWNLOAD should be sent by the
Controller, when Coin Changer is in the following states: Power up, Initialize or Unit Disabled.
If the Coin Changer, which is not executable in its present state, receives a Controller
command Coin Changer issues ILLEGAL COMMAND message.
4.3
Controller Commands
Command
RESET
GET STATUS
TUBE
STATUS
POLL
ENABLE
COIN TYPES
DISPENSE
H
E
X
C
o
d
e
0
8
H
0
9
H
0
A
H
0
B
H
0
C
H
0
Description
Command for Coin Changer to self-reset
Request for Coin Changer set-up status
Request for Coin Changer tube status.
Request for Coin Changer activity Status
Indicates Coin Type enable or disable.
Command is followed by set-up data. See
command format
Command to dispense a coin type. Command
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 35 of 98
IDENTIFICATI
ON
GET COIN
TABLE
DOWNLOAD
4.4
D
H
0
F
H
1
0
H
5
0
H
is followed by set-up data. See command
format
Request for Model, Serial Number, Software
Version of Coin Changer, Country ISO code
Request for coin type description
Command for transition to download mode
Controller Command Format
RESET
Controller Command
Code
Controller Data
RESET
08H
No data bytes
This command is used to tell the Coin Changer that it must return to its default-operating mode.
It must abort all communication and disable all acceptance until otherwise instructed by the
Controller.
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 36 of 98
GET STATUS
Controller Command
GET STATUS
Z
1
Z
3
Z
4
Z
6
Code
0CH
Coin Changer Response Data
6 bytes: Z1 Z6
Coin Type, 3 bytes. Indicates the coin enables for coin types 0 to 23.
Coin Type Routing, 3 bytes. Indicates what coin types can be routed to the Coin
Changers tubes. Valid coin types are 0 to 23.
Coin Type
Byte Z1 bits
4 3 2 1
Byte Z2 bits
7 6 5
0 7 6 5 4 3 2 1 0 7
Coin types enabled if bits set
23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7
Byte Z3 bits
4 3 2 1
Byte Z6 bits
4 3 2 1
Coin Type Routing
Byte Z4 bits
4 3 2 1
Byte Z5 bits
7 6 5
0 7 6 5 4 3 2 1 0 7 6
Coin types can be routed if bits set
23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6
NOTE: Coin type credits sent as FFH are assumed to be Free Vend tokens and their value is
assumed to be worth one vend.
TUBE STATUS
Controller Command
Code
Coin Changer Response Data
TUBE STATUS
0AH
18 byte: Z1-Z27
Z1-Z3
Tube Full Status - 3 bytes.
Indicates status of coin tube for coin types 0 to 23.
A bit is set to indicate a full tube.
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 37 of 98
Byte Z2 bits
7 6 5 4 3 2 1 0 7 6
Tube for Coin types is full if bits set
23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6
7
Byte Z1 bits
4 3 2 1
Byte Z3
3 2 1
3
0
0
Z3-Z27Tube Status 24 bytes.
Indicates the greatest number of coins that the changer knows reliably can be paid
out. A bytes position in the 24-byte string indicates the number of coins in a tube for a
particular coin type. For example, the first byte sent indicates the number of coins in a
tube for coin type 0. Bytes not sent are assumed to be zero.
NOTE:
If a Coin Changer can detect a tube jam, defective tube sensor, or other
malfunction, it will indicate the tube is bad by sending a tube full status and a count of zero for
the malfunctioning coin type.
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 38 of 98
POLL
Controller Command
POLL
Code
Bill-to-Bill unit Response Data
0BH
1 or 2 bytes: Z1 or Z1- Z2
Indicates state of the Coin Changer and its activity. The Coin Changer may send 1or 2 of the
following data bytes:
Respo
nse
data
bytes
Z
Z2
1
1
0
H
1
1
H
1
2
H
1
3
H
1
4
H
1
4
H
1
6
H
1
7
H
1
8
H
1
9
H
1
Description
Power Up
The state of Coin Changer after power up
Initialize
The state, in which Coin Changer executes
initialization on the RESET command of the
Controller.
Idling
In this state Coin Changer waits for an
inserting of coin into its front bezel.
Accepting
In this state Coin Changer validates a coin
and determines its denomination.
Unit Disable
The Coin Changer has been disabled by the
Controller and also the state in which Coin
Changer is after initialization
Changer Busy
The Coin Changer is busy and cannot
answer a detailed command right now.
Changer Pay
Out Busy
The Coin Changer is busy activating Pay Out
devices.
Escrow
request
An escrow lever activation has been
detected.
Double Arrival
Two coins were detected too close together
to validate either one.
No Credit
A coin was validated but did not get to the
place in the system when credit is given.
Coin Routing
A coin has been validated, but did not follow
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 39 of 98
3
H
1
3
H
1
3
H
1
3
H
1
3
H
4
0
4
F
H
(0
1
0
0
x
x
x
x)
5
0
5
F
H
(0
1
0
1
x
x
x
x)
6
0
6
F
H
7
0
-
Error
the intended routing.
Generic
Acceptor Error
The Coin Changer has detected that the
validator has been removed or not
responding.
Defective
Tube Sensor
The Coin Changer has detected one of the
tube sensors behaving abnormally.
Coin Jam
A coin(s) has jammed in the acceptance
path.
Tube Jam
A tube Pay Out attempt has resulted in
jammed condition.
Coin accepted
to cash box
xxxx = coin type deposited (0 to 15).
Z = number of coins in the tube for the coin
type accepted.
Coin accepted
to tube
xxxx = coin type deposited (0 to 15).
Z = number of coins in the tube for the coin
type accepted.
Not used
Coin was
rejected
xxxx = coin type deposited (0 to 15).
Z = number of coins in the tube for the coin
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 40 of 98
7
F
H
(0
1
1
1
x
x
x
x)
8
0
F
F
H
(1
y
y
y
x
x
x
x)
type accepted.
Coin
dispensed
manually
yyy = number of coins dispensed.
xxxx = coin type dispensed (0 to 15)
Z = number of coins in the tube for the coin
type accepted.
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 41 of 98
ENABLE COIN TYPES
Controller Command
Code
Controller Data
ENABLE COIN TYPES
0CH
4 bytes: Y1 Y6
Y1 Y3
Coin enable 3 bytes
Byte Y1 bits
4 3 2 1
Byte Y2 bits
7 6 5
0 7 6 5 4 3 2 1 0 7
Coin types enabled if bits set
23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7
Byte Y3 bits
4 3 2 1
0
0
A bit is set to indicate a coin type is accepted. For example, bit 6 is set to indicate coin type 6,
bit 15 is set to indicate coin type 15, and so on. To disable the changer, disable all coin types
by sending a data block containing 000000H. All coins are automatically disabled upon reset.
Y6 Y6
Manual Dispense enable 3 bytes
Byte Y5 bits
6 5 4 3 2 1 0 7
Dispense enabled if bits set
23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7
7
Byte Y4 bits
4 3 2 1
Byte Y6 bits
4 3 2 1
A bit is set to indicate dispense enable. For example, bit 2 is set to enable dispensing of coin
type 2. This command enables/disables manual dispensing using optional inventory switches.
All manual dispensing must be disabled while in the sales mode.
DISPENSE
Controller Command
Code
Controller Data
DISPENSE
0DH
2 bytes: Y1-Y2
Y1 =
Indicates coin types 0 to 23 to be dispensed.
Y2 =
Indicates number of coins to be dispensed.
If two coin types have the same value, the highest coin type must be paid out first.
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 42 of 98
IDENTIFICATION
Controller Command
Code
Acceptor Response Data
IDENTIFICATION
0FH
19 bytes:
B
y
t
e
s
Z
1
Z
5
Z
6
Z
1
2
Z
1
3
Z
1
6
Z
1
7
Z
1
9
Z1 Z19
Description
Model No. & Model Code 5 bytes
Serial Number 7 bytes Factory assigned serial number
Version 4 bytes Current software version
Country 3 bytes ISO code
Bytes Z1-Z19 must be sent as ASCII Characters zero (30H) and blanks (20H) are acceptable.
GET COIN TABLE
Code
Acceptor Response Data
GET COIN TABLE
10H
80 bytes: Z1-Z80
Controller Command
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 43 of 98
Command for request coin type description.
Z1-Z80
The 80 - byte string consists from 24 five-byte words.
Byte 1 of word hex representation most significant digit of the denomination.
Bytes 2-4 of word country code in ASCII characters.
Byte 5 of word this byte used to determine decimal placement or proceeding zeros. If bit
D7 is 0, the bits D0-D6 indicate the number of proceeding zeros. If bit D7 is 1, the bits D0D6 indicates the decimal point position starting from the right and moving to the left.
A five-byte position in the 80-bytes string indicates coin type description for the particular coin
type. For example, first five byte correspond bill type=0, second five byte correspond bill
type=1 and so on.
Example of coin type description for 25-cent USA: 0x19USD, 0x82;
Unsent bytes are assumed to be zero.
DOWNLOAD
Controller Command
DOWNLOAD
Code
Controller Data
50H
NONE
This command is not implemented in current Coin Changer software releases and will always
return an INV response.
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 44 of 98
1
4.5
CONTROLLER/BILL VALIDATOR Communication Specification
Introduction.
This section defines the communication bytes sent and received between the Bill Validator and
the Controller. Unless stated otherwise, all information is assumed to be in a hexadecimal
format. The Bill Validators address is 03H.
4.6
Command Protocol
If a Controller command is received by the Bill Validator, which is not executable in its present
state, the Bill Validator issues ILLEGAL COMMAND message.
4.7
Controller Commands
Command
RESET
GET STATUS
HE
X
Co
de
30
H
31
H
Description
Command for Bill Validator to self-reset
Request for Bill Validator set-up status
SET SECURITY
32
H
Sets Bill Validator Security Mode. Command
is followed by set-up data. See command
format
POLL
33
H
Request for Bill Validator activity Status
ENABLE BILL
TYPES
34
H
STACK
RETURN
IDENTIFICATIO
N
HOLD
SET BARCODE
PARAMETERS
EXTRACT
BARCODE
35
H
36
H
37
H
38
H
39
H
3A
H
Indicates Bill Type enable or disable.
Command is followed by set-up data. See
command format
Sent by Controller to send a bill in escrow to
the drop cassette
Sent by Controller to return a bill in escrow
Request for Software Part Number, Serial
Number, Asset Number
Command for holding of Bill Validator in
Escrow state
Command for settings the barcode format
and number of characters
Command for retrieving barcode data if
barcode coupon is found. If this command is
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 45 of 98
sent when barcode coupon is not found the
Bill Validator returns ILLEGAL COMMAND
response.
DATA
GET BILL
TABLE
GET CRC32
OF THE CODE
DOWNLOAD
(see details for
subcommands)
REQUEST
STATISTICS
41
H
51
H
Request for bill type description
Request for Bill Validators firmware CRC32.
50
H
Command for transition to download mode.
60
H
Command for retrieving full information
about acceptance performance.
The IDENTIFICATION, GET BILL TABLE, DOWNLOAD and REQUEST STATISTICS
commands should be sent by the Controller when Bill Validator is in the following states: Power
up, Initialize, one of the Failure states (41H-47H) or Unit Disabled. Otherwise an ILLEGAL
COMMAND response will be returned.
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 46 of 98
4.8
Controller Command Format
RESET
Controller Command
Code
Controller Data
RESET
30H
No data bytes
This command is used to tell the Bill Validator that it must return to its default operating mode. It
must abort all communication, reject any bills in the validation process, return any bills in the
escrow position, and disable all other activity until otherwise instructed by the Controller.
GET STATUS
Controller Command
GET STATUS
Z
1
Z
3
Z
4
Z
6
Code
31H
Validator Response Data
6 bytes: Z1 Z6
Bill Type, 3 bytes. Indicates the bill enables for bill types 0 to 23.
Bill Security Levels, 3 bytes. Indicates the security level for bill types 0 to 23.
Bill Type
Byte Z1
Byte Z2
Byte Z3
bits
bits
bits
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
Bill types enabled if bits set
23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Bill Security Levels
Byte Z4
Byte Z5
Byte Z6
bits
bits
bits
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
Bill types set to high security if bits set
23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 47 of 98
SET
SECURITY
Controller Command
Code
Controller Data
SET SECURITY
32H
3 Bytes: Y1 Y3
Byte Y1
Byte Y2
Byte Y3
bits
bits
bits
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
Bill types set to high security if bits set
23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
A bit is set to indicate the type of bill(s), which are set to a high security level.
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 48 of 98
POLL
Controller Command
POLL
Code
Bill Validator Response Data
33H
1 or 2 bytes: Z1 or Z1- Z2
Indicates state of the Bill Validator and its activity. The Bill Validator may send 1or 2 of the
following data bytes:
Resp
onse
data
bytes
Z
1
1
0
H
Description
Power Up
1
1
H
Power Up with
Bill in Validator
1
2
H
Power Up with
Bill in Stacker
1
3
H
1
4
H
1
5
H
1
7
H
1
8
H
1
9
H
1
The state of the Bill Validator after power up
Power up with bill in the Bill Validator. After a
RESET command from the Controller Bill
Validator returns the bill and continues
initializing.
Power up with bill in Stacker (Bill was
transported too far to be returned). After the
Bill Validator is reset and INITIALIZING is
complete, status will immediately change to
STACKED(81H) (Credit Recovery feature).
Initialize
Bill Validator executes initialization after the
RESET command from Controller.
Idling
Bill Validator waits for an inserting of bill into
its bill path.
Accepting
Bill Validator executes scanning of a bill and
determines its denomination.
Stacking
Bill Validator transports a bill from Escrow
position to drop cassette and remains in this
state until the bill is stacked or jammed.
Returning
Bill Validator transports a bill from Escrow
position back to customer and remains in
this state until customer removes the bill or
the bill is jammed.
Unit Disabled
Bill Validator has been disabled by the
Controller or just came out of initialization
Holding
The state, in which the bill is held in Escrow
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 49 of 98
A
H
1
B
H
1
C
H
1
C
H
1
C
H
1
C
H
1
C
H
1
C
H
1
C
H
1
C
H
1
C
H
1
C
H
1
C
H
1
C
H
1
C
H
4
1
H
Device Busy
position after the HOLD command of the
Controller.
Bill Validator cannot answer with a full-length
message right now.
On expiration of time YH, peripheral is
accessible to polling. YH is expressed in
multiple of 100 milliseconds.
Generic rejecting code. Always followed by rejection reason byte (see
below).
60H
Rejecting due
to Insertion
Insertion error
61H
Rejecting due
to Magnetic
Dielectric error
62H
Rejecting due
to Remained
bill in head
Previously inserted bill remains in head
63H
Rejecting due
to Multiplying
Compensation error/multiplying factor error
64H
Rejecting due
to Conveying
Bill transport error
65H
Rejecting due
to
Identification1
Identification error
66H
Rejecting due
to Verification
Verification error
67H
Rejecting due
to Optic
Optic Sensor error
68H
Rejecting due
to Inhibit
Return by inhibit denomination error
69H
Rejecting due
to Capacity
Capacitance error
6AH
Rejecting due
to Operation
Operation error
6CH
Rejecting due
to Length
Length error
Drop Cassette
Full
Drop Cassette full condition
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 50 of 98
4
2
H
4
3
H
4
4
H
4
5
H
8
0
H
The Bill Validator has detected the drop
cassette to be open or removed.
Validator
Jammed
A bill(s) has jammed in the acceptance path.
Drop Cassette
Jammed
A bill has jammed in drop cassette.
Cheated
4
6
H
4
7
H
4
7
H
4
7
H
4
7
H
4
7
H
4
7
H
4
7
H
4
7
H
4
7
H
Drop Cassette
out of position
Pause
Bill Validator sends this event if the
intentions of the user to deceive the Bill
Validator are detected.
When the user tries to insert a second bill
when the previous bill is in the Bill Validator
but has not been stacked. Thus Bill Validator
stops motion of the second bill until the
previous bill is stacked.
Generic Failure codes. Always followed by failure description byte (see
below).
50H
Stack Motor
Failure
Drop Cassette Motor failure
51H
Transport
Motor Speed
Failure
Transport Motor Speed failure
52H
Transport
Motor Failure
Transport Motor failure
53H
Aligning Motor
Failure
Aligning Motor failure
54H
Initial Cassette
Status Failure
Initial Cassette Status failure
55H
Optic Canal
Failure
One of the optic sensors has failed to
provide its response.
56H
Magnetic
Canal Failure
Inductive sensor failed to respond
5FH
Capacitance
Canal Failure
Capacitance sensor failed to respond
Escrow
position
Events with credit.
Y = bill type (0 to 23).
If bill type is enabled with escrow the Bill
Validator waits command from Controller to
stack or to return bill. If during 10 sec
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 51 of 98
command will not be sent bill will be
returned.
8
1
H
8
2
H
Bill stacked
Y = bill type (0 to 23)
Bill returned
Y = bill type (0 to 23)
YH =17H(2310) corresponds to a barcode coupon.
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 52 of 98
ENABLE BILL TYPES
Controller Command
Code
Controller Data
ENABLE BILL TYPES
34H
6 bytes: Y1 Y6
Byte Y1
Byte Y2
Byte Y3
bits
bits
bits
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
Bill types enabled if bits set
23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
NOTE: Sending 000000H disables the Bill Validator.
Byte Y4
Byte Y5
Byte Y6
bits
bits
bits
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
Bill types with escrow enabled if bits set
23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
NOTE: On power-up or reset all bill acceptance and escrow are disabled.
STACK
Controller Command
Code
Controller Data
STACK
35H
No data bytes
This command causes the Bill Validator to send the bill in escrow position to the drop cassette.
NOTE: After a STACK command the Bill Validator should respond to a POLL command with
the BILL STACKED message within 30 seconds. If this command is sent when the Bill Validator
is not in ESCROW state the ILLEGAL COMMAND message is returned.
RETURN
Controller Command
Code
Controller Data
RETURN
36H
No data bytes
This command causes the Bill Validator to return bill in escrow position to the customer.
NOTE:
After a RETURN command the Bill Validator should respond to a POLL command
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 53 of 98
with the BILL RETURNED message within 30 seconds. If this command is sent when the Bill
Validator is not in ESCROW state the ILLEGAL COMMAND message is returned.
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 54 of 98
IDENTIFICATION
Controller Command
Code
Bill-to-Bill unit Response Data
IDENTIFICATION
37H
34 bytes:
B
y
t
e
s
Z
1
Z
1
5
Z
1
6
Z
2
7
Z
2
8
Z
3
4
Z1 Z34
Description
Part Number 15 bytes, ASCII characters
Serial Number 12 bytes Factory assigned serial number, ASCII
characters
Asset Number 7 bytes, unique to every Bill Validator, binary
data
Bytes Z1-Z27 must be sent as ASCII Characters. Zero (30H) and Blank (20H) are acceptable.
Asset Number must be sent as binary code.
15 bytes
FL-US1701
12 bytes
00K038AS3419
7 bytes
Binary code
Asset Number
Serial Number
Model
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 55 of 98
This command is valid in the following states only: Power up, Initialize, one of the Failure states
(41H-47H) or Unit Disabled.
HOLD
Controller Command
Code
HOLD
Controller Data
38H
No data bytes
This command allows the controller to hold Bill Validator in Escrow during 10 s. After this time
the Controller should send the STACK or RETURN command. For continued holding in an
Escrow state it is necessary to resend this command. Otherwise the Bill Validator will execute
return of a bill.
SET BARCODE PARAMETERS
Controller Command
Code
Controller Data
SET BARCODE PARAMETERS
39H
2 bytes: Y1-Y2
Used to set the barcode format and number of characters.
Y1 - bar code format. 01H = interleaved 2 of 5.
Y2 - number of characters (min 6, max 18).
EXTRACT BARCODE DATA
Controller Command
Code
EXTRACT BARCODE DATA
Bill Validator Response Data
3AH
n bytes: Z1-Zn
Z1-Zn - n bytes ASCII of barcode data, n is equal min 6 bytes, max 18 bytes. Data is sent most
significant byte first. Parameter n is assigned by command SET BARCODE PARAMETERS.
This command may be sent at any time after the Bill Validator responds to the Poll command by event
80H, 81H or 82H and the bill type indicates barcode token presence (23). Barcode data of a successful
reading is preserved until next bill will be inserted. Otherwise an ILLEGAL COMMAND response will be
returned.
GET BILL TABLE
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 56 of 98
Controller Command
Code
Bill Validator Response Data
GET BILL TABLE
41H
120 bytes: Z1-Z120
Command for request bill type description.
Z1-Z120
The 120 - byte string consists from 24 five-byte words.
Byte 1 of word hex representation most significant digit of the denomination.
Bytes 2-4 of word country code in ASCII characters.
Byte 5 of word this byte used to determine decimal placement or proceeding zeros. If bit
D7 is 0, the bits D0-D6 indicate the number of proceeding zeros. If bit D7 is 1, the bits D0D6 indicate the decimal point position starting from the right and moving left.
A five-byte position in the 120-bytes string indicates bill type description for the particular bill
type. For example, first five byte correspond bill type=0, second five byte correspond bill
type=1 and so on.
Example:
B
il
l
T
y
p
e
Den
omi
nati
on
Cod
e
First
Byte
0x1
0x2
0x5
0x5
C
o
u
n
t
r
y
C
o
d
e
3
b
y
t
e
s
I
T
L
I
T
L
I
T
L
N
L
C
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Den
omi
nati
on
Cod
e
Sec
ond
Byte
Den
omi
nati
on
0x3
1,00
0
Lir
a
0x3
2,00
0
Lir
a
0x3
5,00
0
Lir
a
0x8
2
.05
Cr
o
w
n
Page 57 of 98
0x1
9
N
L
C
0x8
2
.25
0x1
9
N
L
C
0x8
1
2.5
0x1
9
N
L
C
0x0
25
0x1
9
N
L
C
0x2
250
0
0x1
0x0
0x5
0x0
1
0
0x1
0x1
10
1
1
0x2
U
S
A
U
S
A
U
S
A
U
S
A
0x1
20
Cr
o
w
n
Cr
o
w
n
Cr
o
w
n
Cr
o
w
n
D
oll
ar
D
oll
ar
D
oll
ar
D
oll
ar
Unsent bytes are assumed to be zero.
This command is valid in the following states only: Power up, Initialize, one of the Failure
states (41H-47H) or Unit Disabled.
GET CRC32 OF THE CODE
Controller Command
Code
GET CRC32 OF THE CODE
Bill Validator Response Data
51H
4 bytes: Z1-Z4
Z1-Z4 - 4 bytes of CRC, MSB first.
This command is valid in the following states: Power up, Initialize, one of the Failure states (41H-47H) or
Unit Disabled.
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 58 of 98
DOWNLOAD
Controller Command
Code
DOWNLOAD
Controller Data
50H
NONE
Command for transition Bill Validator to download mode.
Upon receipt of this command and issuing of confirmation ACK the Bill Validator transits to
download mode. In this mode the Bill Validator receives DOWNLOAD command with subcommands only. All other commands will be ignored.
Issuing of confirmation ACK by Bill Validator to the DOWNLOAD command is delayed for up to
the time of command execution (200 ms).
This command is valid in the following states: Power up, Initialize, one of the Failure states
(41H-47H) or Unit Disabled.
Controller Command
Data
Code
DOWNLOAD
Sub-Command
50H
Bill Validator Response
00H
1 byte: Z1
(Switch to DOWNLOAD/Request Status)
Command for polling boot loader program status. This command should be send for transition
to download mode and after issuing operation command.
Z1
If Z1= 00H boot loader program is ready to execute download commands;
If Z1= E0H boot loader program has executed previous operation command successfully;
If Z1= E1H boot loader program has executed previous operation command with error.
Controller Command
Data
DOWNLOAD
Code
Sub-Command
50H
01H
Bill Validator Response
1 byte: Z1
(Request block size)
Request for memory block size. Further programming with DOWNLOAD Write To Memory
must be performed with blocks of this size. No defaults are defined for data block size, and no
assumptions should be made valid response to block size request is the only way of
evaluating the actual block size for the session given.
Z1 DATA block size index. Actual block size is 2^Z1.
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 59 of 98
Ex: if DATA block size is 512 bytes then size index is 9 (512=2^9).
Controller Command
Validator Data
Code
DOWNLOAD
1byte:Z1
Sub-Command
50H
02H
Controller Data
Bill
(n+5) bytes: Y1-Y(n+5)
(Write to memory)
Command for writing data to memory.
Y1-Y2
Length of message;
Y3-Y5
AdrLow, AdrMid, AdrHigh are the address first byte of n Data bytes;
Y6-Y(n+5) n Data bytes (following requested block size).
Z1
if Z1=E0H data received successfully
If Z1=E1H data received with error
Controller Command
Data
DOWNLOAD
Code
Sub-Command
50H
Bill Validator Response
03H
1 byte: Z1
(Exit)
Command for exiting to normal operation.
Z1
If Z1= E0H - CRC of freshly written code matched the one supplied with code itself;
If Z1= E2H - CRC of freshly written code did not match the one supplied with code itself;
REQUEST STATISTICS
Controller Command
Code
Bill Validator Response Data
REQUEST STATISTICS
60H
4358bytes: Y1-Y4358
Command for retrieving statistical data
To describe the Bill Validator performance characteristics more meaningfully all cumulative data
are grouped into three aggregates of counters. The first aggregate is formed by 16 sets of 96
counters each. The second aggregate is formed by 20 sets of 46 counters each. The third
aggregate is formed by 20 sets of one counter each. Each aggregate keeps track of Bill
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 60 of 98
Validator events on a different statistical basis.
In the first aggregate sets are averaged by 10000 inserted bills, in the second aggregate sets
are averaged by 500 inserted bills, and in the third aggregate by 50 inserted bills.
The first aggregate counters are populated after insertion of every 10000 bills is completed,
second - after insertion of 500 bills, third - after insertion of 50 bills. Aggregates contain circular
buffers, i.e. one set of counters in every aggregate always contains current results. For every
aggregate counter sets are output the most recent set last, therefore if circular buffer is not full
zeroes will precede normal statistic data.
Such organization of the statistical data allows analyzing change of the characteristics of Bill
Validator depending on number of the inserted bills for various scales with points 10000 bills,
500 bills and 50 bills. Below as an example the diagrams of change of some characteristics for
these three scales are given.
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 61 of 98
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 62 of 98
Rate of acceptance
In response to a REQUEST STATISTICS command Bill Validator sends Y1-Y4358 bytes. Y1-Y2
is length of message (see 2.3). Y3-Y4358 corresponds to the following table.
98%
97%
1.
96%
2.
95%
3.
94%
Type of Data
Numbers of bytes
Identification data
32
(Y3-Y34)
16 sets of first
16x179=2864 (Y35-Y2898)
aggregate
20 sets of second
20x66=1320 (Y2899aggregate
Y4218)
93%
4.
20 sets of third
20x1=20
(Y4219aggregate
Y4238)
5.
Table of
100
(Y4239n 2n denominations
3n 4n 5n 6n 7n 8n 9n 10n
11n 12n 13n 14n 15n 16n
Y4338)
6.
Currency names
(Y4339Diagram 20
1
block
Y4358)
Number of Returned bills by capacitance criteria
n=10000
Number of
inserted bills
Format of identification data block:
10
Description
9 B
y
8
t
7 e
6 s
Z
5 1
n=500
Country Code 3 bytes, ASCII characters
Number of
Z
n 2n 3n 4n 5n 6n 7n
13nn14n 15n 16n 17n 18n 19n 20n
inserted bills
3
Diagram 2
Z of jams
Total number
Denomination count 1 byte (number of denominations accepted), binary
4
Z
Data format version 1 byte, RESERVED FOR FACTORY USE
6 5
Last statistics reset Date and Time 8 bytes, format shown below:
5
4 Z
6
3
2 Z
1
1
2
Z
1
3
LSB of year (ex: for year 2002, its 210 decimal), 1 byte (Z6);
MSB of year (ex. for year 2002, its 7 decimal), 1 byte (Z7);
Month, 1 byte (Z8);
Day, 1 byte (Z9);
Hour (24-hour based), 1 byte (Z10);
Minutes, 1 byte (Z11);
Seconds, 1 byte (Z12).
n 2n 3n 4n 5n 6n 7n
Reserved
n=50
13nn14n 15n 16n 17n 18n 19n 20n
Diagram 3
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Number of
inserted bills
Page 63 of 98
Z
1
4
Z
2
5
Z
2
6
Z
3
2
Serial Number 12 bytes, ASCII
Reserved
Format of statistical data for one set of 1/10000 aggregate:
Z
1
Z
2
Z
3
Z
4
Z
5
Z
6
Z
4
1
Z
4
2
Z
4
3
-
Number Inserted bills
Number of Accepted bills for 1st denomination
Number of Accepted bills for 2nd denomination
Number of Accepted bills for 20 th denomination
Number of Returned bills by optical criteria for 1 st
denomination
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 64 of 98
Z
4
4
Z
4
5
Z
4
6
Z
8
1
Z
8
2
Z
8
3
Z
8
4
Z
8
5
Z
8
6
Z
1
2
1
Z
1
2
2
Z
1
Number of Returned bills by optical criteria for 2 nd
denomination
Number of Returned bills by optical criteria for 20 th
denomination
Number of Returned bills by magnetic criteria for 1 st
denomination
Number of Returned bills by magnetic criteria for 2 nd
denomination
Number of Returned bills by magnetic criteria for 20 th
denomination
Number of Returned bills by capacitance criteria for 1 st
denomination
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 65 of 98
2
3
Z
1
2
4
Z
1
2
5
_
Z
1
2
6
Z
1
6
1
Z
1
6
2
Z
1
6
3
Z
1
6
4
Z
1
6
5
Z
1
6
6
Number of Returned bills by capacitance criteria for 2 nd
denomination
Number of Returned bills by capacitance criteria for 20 th
denomination
Number of Unrecognized bills
Number of Returned bills by length
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 66 of 98
Z
1
6
7
Z
1
6
8
Z
1
6
9
Z
1
7
0
Z
1
7
1
Z
1
7
2
Z
1
7
3
Z
1
7
4
Z
1
7
5
Z
1
7
6
Z
1
7
7
Number of Failures by magnetic
Number of Failures by optics
Number of Failures of transport mechanism
Number of Failures of stacking mechanism
Number of Failures of aligning mechanism
Number of Jams in drop cassette
Number of Jams at entrance sensor
Number of Jams at both entrance and aligning sensors
Number of Jams at aligning sensor
Number of Jams at aligning and optical sensors
Number of Jams at optical sensor
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 67 of 98
Z
1
7
8
Z
1
7
9
Number of Jams at optical and exit sensors
Number of Jams at exit sensor
* - Number of denominations accepted includes both old and new denominations, if theyre
present. Order of denominations is listed in table of denominations
Format of statistical data for one set of 1/500 aggregate:
Z
1
Z
2
Z
3
Z
4
Z
3
9
Z
4
0
Z
4
1
Z
4
2
Z
6
0
Z
6
1
Z
Number of Accepted bills for 1st denomination
Number of Accepted bills for 2nd denomination
Number of Accepted bills for 20 th denomination
Number of Returned bills by verification for 1 st denomination
Number of Returned bills by verification for 2 nd denomination
Number of Returned bills by verification for 20 th denomination
Number of Returned bills by optical criteria
Number of Returned bills by magnetic criteria
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 68 of 98
6
2
Z
6
3
Z
6
4
Z
6
5
Z
6
6
Number of Returned bills by capacitance criteria
Number of Jams at bezel
Number of Jams at transport path
Total number of Jams
Format of statistical data for one set of 1/50 aggregate:
Z
1
Total number of Jams
Format of denominations table:
Z1-Z100
The 100 byte string consisting of 20 five-byte words.
Two most significant bits of first byte in every word denomination type (old or new).
Coding of a denomination type:
7th
bit
6
th
b
it
0
1
denomination
type
Old
denomination
New
denomination
Other bits of first byte hex representation of the most significant digit of the
denomination.
Bytes 2-4 of word country code in ASCII characters.
Byte 5 of word used to determine decimal placement or proceeding zeros. If bit D7 is 0,
the bits D0-D6 indicate the number of proceeding zeros. If bit D7 is 1, the bits D0-D6
indicate the decimal point position starting from the right and moving left.
Example:
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 69 of 98
Denomi
nation
Code
First
Byte
0x1
0x5
0x1
0x41
0x2
0x42
0x5
0x45
0x1
0x41
0x1
C
o
u
n
t
r
y
C
o
d
e
3
b
y
t
e
s
U
S
A
U
S
A
U
S
A
U
S
A
U
S
A
U
S
A
U
S
A
U
S
A
U
S
A
U
S
A
M
X
Den
omi
nati
on
Cod
e
Sec
ond
Byte
Denomi
nation
0x0
1 Dollar
0x0
5 Dollars
0x1
10 Old
Dollars
0x1
10 New
Dollars
0x1
20 Old
Dollars
0x1
20 New
Dollars
0x1
50 Old
Dollars
0x1
50 New
Dollars
0x2
100 Old
Dollars
0x2
100 New
Dollars
0x1
10
Pesos
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 70 of 98
0x2
0x42
0x5
0x45
0x1
0x2
0x5
N
M
X
N
M
X
N
M
X
N
M
X
N
M
X
N
M
X
N
M
X
N
0x1
20 Old
Pesos
0x1
20 New
Pesos
0x1
50 Old
Pesos
0x1
50 New
Pesos
0x2
100
Pesos
0x2
200
Pesos
0x2
500
Pesos
Format of currency names block:
Names of currencies comprise a formatted ASCII data string where currency names appear in
a sequence corresponding to the table of denominations. Currency names are separated by
slash. String is terminated with dot.
Example:
Dollar/Peso.
Command REQUEST STATISTICS is valid in the following states: Power up, Initialize, one of
the Failure states (41H-47H) or Unit Disabled.
If statistic data is not correct Bill Validator sends an error response with data field set to 31H
(INVALID STATISTIC DATA).
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 71 of 98
CONTROLLER/ Card Reader Communication Specification
Introduction
5.1
This section defines the communications bytes sent and received between Card Reader and
the Controller. The Card Reader s address is 04H.
Unless stated otherwise, all information is assumed to be in hexadecimal format. The numbers
will be sent most significant byte first.
Card Reader States
5.2
Card Readers may be viewed as state machines. These states are as follows:
1)
2)
3)
4)
5)
6)
7)
Inactive
Disabled
Idling
Ready for Transaction
Vending
Busy
Vend OK/Vend Failed
5.2.1
Inactive
This is the state of the card reader at power up or after a reset. All cards except for stored
value cards (for balance inquiry after internal initialization completes) will not be accepted. The
card reader cannot leave this state until all SETUP information is received from the Controller.
5.2.2
Disabled
The card reader automatically enters this state from the Inactive state when it has received all
SETUP information from the Controller and completes its internal initialization. It will also enter
the Disabled state from the Idling state when it receives the READER/DISABLE command.
While in the Disabled state, stored value cards will be accepted (for balance inquiries), but no
vending requests will be granted.
5.2.3
Idling
In this state, cards may be used for transactions. The card reader will remain in this state until a
valid card is read (when it will enter the Ready for Transaction state), a READER/DISABLE
command is received (when it will return to the Disabled state) or a RESET is received (when it
will enter the Inactive state).
5.2.4
Ready for Transaction
In the Idling state, when a valid card is processed, the card reader will enter the Ready for
Transaction state. This indicates that the card reader is available for vending activities. The
only structured exits from the Ready for Transaction state are:
Through the VEND/SESSION COMPLETE subcommand from the Controller (for a no-value cards,
ex. debit and credit cards; for stored value cards this command makes no sense but will not
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 72 of 98
generate an error);
Through card removal (for stored value cards only).
Other VEND subcommands will cause the card reader to leave the Ready for Transaction state
and enter the Vending state when products are purchased.
5.2.5
Vending
This state is entered from the Ready for Transaction state upon reception of a VEND/VEND
REQUEST command from the Controller.
5.2.6 Busy
This state is entered when Card Reader starts performing internal operations and exited upon
completion of internal operations. Exit is done to the state present before entering Busy, except
for error conditions appeared while in Busy.
5.2.7 Vend OK/Vend Failed
This state is entered after processing Vend Request command. When all transactions with card
and/or bank are finalized this state is returned to POLL command and cleared upon successful
readout or kept until successful readout in case of communication errors.
5.3
Command Protocol
The card reader will provide an informational response immediately with the requested data.
5.4
Controller Commands
COMMAN
D
RESET
SETUP
POLL
VEND
H
E
X
C
O
D
E
3
0
H
1
1
H
3
3
H
1
3
H
DESCRIPTION
Command for Card Reader to self-reset.
Send/Request Card Reader setup status.
Request for Card Reader activity status.
Vend state control.
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 73 of 98
ENABLE/
DISABLE
IDENTIFI
CATION
DOWNLO
AD
5.5
1
4
H
1
5
H
5
0
H
Disabled/Enabled state control.
Request for Model, Serial Number, Software
Version, Localization ISO code.
Command for transition to download mode.
Controller Command Format
RESET
Controller Command
Code
Controller Data
RESET
30H
No data bytes
This command is the vehicle that the Controller must use to tell the Card Reader that it must
return to the Inactive state. With the exception of the ACK response, it must abort all
communication, terminate any ongoing transaction (with a refund, if appropriate), eject the card
(if applicable), and go to the Inactive state until otherwise instructed by the Controller.
The Controller must follow the RESET command with the SETUP and ENABLE/DISABLE
commands to enable vending transactions. RESET command is not valid for Vending, Busy
and Vend OK/Vend Failed states. If received with any of these states active, a COMMAND
INVALID response is issued.
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 74 of 98
SETUP
Controller Command
Response Data
SETUP
11H
Y1 =
Code/Subcommand Controller Data
Y1
Z1 Z2
Controller Capabilities Level
Indicates the highest capabilities level the Controller supports. Currently, this byte is set
to 01.
RESPONSE - CARD READER CONFIGURATION:
Indicates the Card Reader is responding to a SETUP request from the Controller. This
response includes the following data:
Z1 =
Z2 =
Card Reader capabilities level
Capabilities level of the Card Reader. Currently the highest
capabilities level is 01.
Miscellaneous options
b0 Fund Restoring capable
0=
the card reader is NOT capable of restoring funds to
the users card or account. Do not request refunds.
1=
the card reader is capable of restoring funds to the
users card or account. Refunds may be requested.
b1 Continuous Payment capable
0=
the card reader is NOT capable of collecting funds
from multiple cards for single payment. Money
withdraw request will be denied if funds are
insufficient in authorized card.
1=
the card reader is capable of collecting funds from
multiple cards for single payment. Money withdraw
request will be approved even if funds are insufficient
in authorized card
Other bits are ignored (under card reader capabilities level 01) and may be
set to any value.
POLL
Controller Command
Code
Response Data
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Controller Data
Page 75 of 98
POLL
33H
No data
Z1 up to Z2
The POLL command is used by the Controller to obtain information from the Card Reader. This
information may include user actions, hardware malfunctions, software malfunctions or
information explicitly requested by the controller.
Controller may receive the following POLL responses from the Card Reader:
Respon
se data
bytes
Z1
01
H
05
H
Description
Z2
Inactive
Disabled
06
H
Idling
07
H
08
H
Ready for
Transaction
Vending
12
H
13
H
09
H
10
H
Vend OK
Vend Failed
11
H
Z2
Malfunction/
Error
Delayed
Busy
Indicates the Card Reader has been
reset/re-powered.
Indicates the Card Reader has received all
SETUP information from the Controller. Card
Reader will also enter the Disabled state
from the Enabled state when it receives the
ENABLE/DISABLE command.
In this state cards may be used for
transactions. Card Reader will enter the
Enabled state from the Disabled state when
it receives the ENABLE/DISABLE command.
Indicates the Card Reader is available for
vending activity.
This state is entered from the Idling state
upon reception of a VEND REQUEST
command from the Controller.
Transaction successfully completed.
Transaction failed for a reason not relevant
to the Controller.
The Card Reader is reporting a malfunction
or error.
Indicates that a full response to a command
is not available right now. This may occur, for
example, while card reader is dialing out to
the bank.
Card Reader is busy with internal operations
Z1 = 01H
INACTIVE:
Indicates the Card Reader has been reset, due to either an external RESET or an
internally detected condition.
Z1 = 05H
DISABLED:
Indicates the Card Reader has received all SETUP information from the Controller and
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 76 of 98
completed its internal initialization. Card Reader will also enter the Disabled state from
the Idling state when it receives the ENABLE/DISABLE command.
Z1 = 06H
IDLING:
In this state cards may be used for transactions. Card Reader will enter the Idling state
from the Disabled state when it receives the ENABLE/DISABLE command.
Z1 = 07H
READY FOR TRANSACTION:
Indicates the Card Reader is available for vending activity.
Z1 = 08H
VENDING:
This state is entered from the Idling state upon reception of a VEND REQUEST
command from the Controller.
Z1 = 12/13H
VEND OK/VEND FAILED:
This state is entered from the Vending state upon completion of a transaction.
Z1 = 09H
MALFUNCTION/ERROR:
The Card Reader is reporting a malfunction or error. This response includes the
following information:
Z2 =
Error Code = xxxxyyyy
xxxx =
0010: Card Error (e.g. stored value card removed while transaction is in progress,
or a no-value card read incomplete) 1 or 2
0100: Communications Error (checksum error/data frame inconsistent) 2
1000: Reader Failure3
Other values not defined under card reader capabilities level 01.
1Transient error Reported once.
2Non-transient error reported every POLL until cleared. Card Reader
functional after error cleared.
3Non-transient error reported every POLL until cleared. Card Reader not
presently functional.
yyyy = Manufacturer defined sub-code
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 77 of 98
VEND/BEGIN SESSION
Controller Command
Code/Subcommand Controller Data
Response Data
VEND/BEGIN SESSION
13H
Y1
none
Y1 = 10H
VEND BEGIN SESSION - subcommand.
Indicates that VMC is requesting card authentication from the Card Reader. This
command may only be issued in Idling state, otherwise a COMMAND INVALID will be
returned. If a stored value card is already authenticated, the Ready for Transactions
state will be entered immediately. For the no stored value card an invitation is issued
for the user to insert/swipe a card, and after completed, Ready for Transactions state is
entered. Its at Controllers discretion to terminate this condition if a time-out occurs
without a card being authenticated, as this state is never left on Card Readers initiative
for no stored value cards and left on Card Readers initiative when card is removed for
stored-value cards.
VEND/GET FUNDS
Controller Command
Code/Subcommand Controller Data
Response Data
VEND/GET FUNDS
13H Y1
Z1-Zn
Y1 = 00H
VEND GET FUNDS - subcommand.
Indicates that VMC is requesting a balance from the card. This command may only be
issued in Ready for Transactions state, otherwise a COMMAND INVALID will be
returned.
Z1 =
Flag indicating that a card contains stored value:
E0HE7H the card is a stored value card;
E8HEFH - the card is not a stored value card;
All subsequent data exists for stored value cards only and consists of N 8-byte blocks,
one block per each wallet with different currency in the card. Wallets are numbered
sequentially as they arrive in response to VEND/GET FUNDS, starting from 0.
Z2-Z4 =
Currency code, three ASCII characters, following ISO 4217;
Z5-Z8 =
Wallet balance in composite format, i.e. binary unsigned integer value; Z9 least
significant bits compose the fractional part to obtain the exact value Z5Z8 should
be treated as a 32-bit binary value, then divided by 10^Z9; the division result is the
integer part of funds value, the remainder stays for the fractional part.
Number of decimal places.
Z9
VEND/VEND REQUEST
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 78 of 98
Controller Command
Code/Subcommand Controller Data
Response Data
VEND/
VEND REQUEST
13H Y1 Y10
none
Y1 = 01H
VEND REQUEST - subcommand.
Indicates the customer has made a selection. The Controller is requesting vend
approval from the Card Reader before dispensing the product. The Card Reader enters
state Vending after reception of this command and keeps it until transaction is finalized
(state Vend OK is entered) or error occurs (state Vend Fail is entered). The state is
preserved until successful read-out.
Y1 = 02H
VEND REQUEST REFUND - subcommand.
Indicates the controller is requesting a refund for the given wallet with amount given.
The Card Reader enters state Vending after reception of this command and keeps it
until transaction is finalized (state Vend OK is entered) or error occurs (state Vend Fail
is entered). The state is preserved until successful read-out.
VEND REQUEST and VEND REQUEST REFUND commands are valid only in Ready
For Transaction state, otherwise COMMAND INVALID is issued.
Y2 =
Wallet number. Wallets are numbered serially starting from 0 as returned by
VEND/GET FUNDS command. If card is not a stored value card Y2 may be assigned
any value.
Y3 Y6 =
Y7 Y10 =
Amount to draw in composite format, same as for VEND/GET FUNDS command.
Accumulated amount in composite format, same as for VEND/GET FUNDS
command. This field represents amount, accumulated for the given card session (i.e. it
is set 0 prior to issuing VEND/BEGIN SESSION and incremented prior to sending
every VEND/VEND REQUEST with requested value). This value is used by Card
Reader to trace retransmissions of VEND/VEND REQUEST issued by Controller.
Separate accumulated amounts are maintained for every wallet reported by the Card
Reader.
VEND/VEND CANCEL
Controller Command
Code/Subcommand Controller Data
Response Data
VEND/
13H
Y1
Z1
VEND CANCEL
Y1 = 03H
VEND CANCEL - subcommand.
This command can be issued by the Controller to cancel a VEND REQUEST command
before the Card Reader has sent a VEND APPROVED/DENIED. The Card Reader will
respond to VEND CANCEL with a VEND DENIED or VEND CANCEL FAILED and
return to the Idling state. State preserved until successful read-out. This command is
valid only in Vending state, otherwise COMMAND INVALID response is issued.
Z1 = 06H
VEND DENIED:
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 79 of 98
Approval denied for the customers selection. Do not dispense any products/credit
services.
VEND CANCEL FAILED:
Funds are already withdrawn and may not be returned. Products/services should be
dispensed.
Z1 = 07H
VEND/SESSION COMPLETE
Controller Command Code/Subcommand
Controller Data
VEND/
SESSION COMPLETE
13H/04H
Y1 = 04H
SESSION COMPLETE subcommand.
Y1
This tells the Card Reader that the session is complete and to return to Idling state.
ENABLE/DISABLE
Controller Command Code/Subcommand
READER/DISABLE 14H
Controller Data
Y1
Any transaction in progress will not be affected and must continue to its normal completion.
Y1 = 00H
DISABLE - subcommand.
Y1 = 01H
This informs the Card Reader that it has been disabled, i.e. it must no longer accept a
customers card for the purpose of vending. Vending activities may be re-enabled using
the READER ENABLE command. The Card Reader must retain all SETUP information.
ENABLE - subcommand.
This informs the Card Reader that it has been enabled, i.e. it must be ready for
accepting cards.
Reader may be enabled from Disabled state only and disabled from Idling state only,
otherwise a COMMAND INVALID response will be issued.
IDENTIFICATION
Controller Command
Code
Card Reader Response Data
IDENTIFICATION
15H
Z1 Z34
Description
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 80 of 98
y
t
e
s
Z
1
Z
1
5
Z
1
6
Z
2
7
Z
2
8
Z
3
4
Part Number 15 bytes, ASCII characters
Serial Number 12 bytes Factory assigned serial number, ASCII
characters
Asset Number 7 bytes, unique to every Card Reader, binary
data
Bytes Z1-Z27 must be sent as ASCII Characters. Zero (30H) and Blank (20H) are acceptable.
Asset Number must be sent as binary code.
15 bytes
FL-US1701
12 bytes
00K038AS3419
7 bytes
Binary code
Asset Number
Serial Number
Model
DOWNLOAD
Controller Command
DOWNLOAD
Code
Controller Data
50H
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
No data bytes
Page 81 of 98
Command for transition Card Reader to download mode. Currently not defined and returns
COMMAND INVALID response.
5.6
Non-Response Time
The maximum non-response time for a Card Reader is 5 seconds. This is the maximum time
for which a Card Reader will not respond to a command with ACK, NAK or a data message.
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 82 of 98
APPENDIX
Example CCNET Message Sequences
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 83 of 98
6.1
Power Up & Reset sequence
Control
ler
POLL
ACK
RESET
POLL
ACK
GET
STATU
S
ACK
SET
SECUR
ITY
Power Up & Reset sequence
Bill-to-Bill unit
----->
<--------->
----->
<--------->
<--------->
<--------->
ACK
POLL
ACK
INITIALIZE
Bill-to-Bill unit is
initializing
Collect operational
parameters
BILL-TO-BILL UNIT
CONFIG.
----->
Update bill security levels
ACK
----->
<--------->
Power is switched on
Reset peripheral
----->
<----IDENTI
FICATI
ON
POWER UP
Comments
Collect asset inf.
BILL-TO-BILL UNIT
ID
----->
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 84 of 98
ACK
POLL
ACK
6.2
<--------->
----->
<--------->
INITIALIZE
Bill-to-Bill unit is
initializing
UNIT DISABLE
All bill types are disabled
Enable sequence
Enable sequence
Bill-toBill unit
Controller
ENABLE
BILL
TYPES
POLL
ACK
---->
<------->
<------->
Comments
Enable appropriate bill
types
ACK
IDLING
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Bill-to-Bill unit is waiting
accepting of bill
Page 85 of 98
6.3
Disable sequence
Disable sequence
Bill-toBill unit
Controller
ENABLE
BILL
TYPES
6.4
---->
<----
Comments
Disable all bill types
ACK
Bill Accept sequence (Bill stacked).
Bill Accept sequence
- Bill stacked Bill-toBill unit
Controller
POLL
ACK
POLL
ACK
POLL
ACK
STACK
---->
<------->
---->
<------->
.
.
.
---->
<------->
Comments
ACCEPTI
NG
Bill is accepting
ESCROW
POSITIO
N
Bill type in escrow
position
ESCROW
POSITIO
N
Bill type in escrow
position
---->
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Send bill to drop cassette
or one of the recycling
cassette
Page 86 of 98
<---POLL
ACK
POLL
ACK
CASSETTE
STATUS
---->
<------->
.
.
.
---->
<------->
---->
<----
ACK
---->
ENABLE
BILL
TYPES
---->
<----
POLL
ACK
---->
<------->
ACK
STACKIN
G
Bill is stacking
BILL
STACKED
Bill has been stacked
Collect operational
parameters
BILL-TOBILL UNIT
CASSETT
E
STATUS
Enable appropriate bill
types
ACK
IDLING
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Bill-to-Bill unit is waiting
accepting of bill
Page 87 of 98
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 88 of 98
6.5
Bill Accept sequence (Bill returned)
Bill Accept sequence
- Bill returned Bill-toBill unit
Controller
POLL
POLL
POLL
ACK
RETURN
POLL
ACK
---->
<------->
<---.
.
.
---->
<------->
---->
<------->
<------->
.
.
.
Comments
ACCEPTI
NG
Bill is accepting
ESCROW
POSITIO
N
Bill type in escrow position
ESCROW
POSITIO
N
Bill type in escrow position
Return bill to consumer
ACK
RETURNI
NG
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Bill is returning
Page 89 of 98
POLL
ACK
ENABLE
BILL
TYPES
POLL
ACK
---->
<------->
---->
<------->
<------->
BILL
RETURN
ED
Bill has been returned
Enable appropriate bill
types
ACK
IDLING
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Bill-to-Bill unit is waiting
acceptance of bill
Page 90 of 98
6.6
Bill Dispense sequence (Bill dispensed).
Bill Dispense sequence
- Bill returned Bill-toBill unit
Controller
DISPENSE
POLL
ACK
POLL
ACK
CASSETTE
STATUS
---->
<----
--->
<----->
.
.
.
--->
<----->
---->
<-
Comments
Dispensed bills to
customer
ACK
BILL
DISPENSI
NG
Bill transporting to
dispenser
BILL
DISPENS
ED
Dispense is completed.
Bills pay to customer.
Collect operational
parameters
BILL-TOBILL UNIT
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 91 of 98
---ACK
--->
POLL
--->
<----->
ACK
CASSETT
E
STATUS
IDLING
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Bill-to-Bill unit is waiting
accepting of bill
Page 92 of 98
6.7
Bill Unload sequence (Bill unloaded).
Bill Unload sequence
- Bill unloaded Bill-toBill unit
Controller
UNLOAD
POLL
ACK
POLL
ACK
CASSETTE
STATUS
Stacking all bills from
Recycling Cassettes to
drop cassette. (Unload
Bill-to-Bill unit)
---->
<----
--->
<----->
.
.
.
--->
<----->
---->
<---
Comments
ACK
BILL
UNLOADI
NG
Bill transporting to drop
cassette.
BILL
UNLOAD
ED
Unload is completed. All
Recycling Cassettes are
empty. (All banknotes
stacked in drop cassette.
Collect operational
parameters
BILL-TOBILL UNIT
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 93 of 98
-ACK
--->
POLL
--->
<----->
ACK
CASSETT
E
STATUS
IDLING
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Bill-to-Bill unit is waiting
acceptance of bill
Page 94 of 98
6.8
Set cassette type sequence
Set cassette type sequence
Bill-toBill unit
Controller
CASSETTE
STATUS
---->
<----
ACK
--->
SET
CASSETTE
TYPE
---->
<----
POLL
ACK
POLL
--->
<----->
.
.
.
--->
<---
Comments
Collect operational
parameters
BILL-TOBILL UNIT
CASSETT
E
STATUS
Cassette necessary for
setting is not empty.
Assigning cassette to bill
type
ACK
SETTING
CASSETT
E TYPE
Bills transporting to drop
cassette.
SET
CASSETT
E TYPE
Setting recycling cassette
type is completed.
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 95 of 98
--->
ACK
CASSETTE
STATUS
---->
<----
ACK
--->
POLL
--->
<----->
ACK
6.9
Collect operational
parameters
BILL-TOBILL UNIT
CASSETT
E
STATUS
Necessary recycling
cassette is empty. It is
assigned to new bill type.
IDLING
Bill-to-Bill unit is waiting
acceptance of bill
Power Up with Bill in Stacker sequence for Bill Validator
Control
ler
POLL
Power Up & Reset sequence
Bill Validator
----->
<-----
POWER UP WITH
BILL IN STACKER
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Comments
On the Power up the
validator will check if the
bill was in the process of
being stacked during the
last power down. The bill
being stacked is defined
as time between the bill
clears the exit sensor and
before the response to a
Page 96 of 98
poll command with the
Bill Stacked event is
sent.
ACK
----->
RESET
----->
<-----
POLL
ACK
GET
STATU
S
ACK
SET
SECUR
ITY
----->
<--------->
ACK
POLL
ACK
POLL
ACK
ACK
INITIALIZE
----->
<--------->
BILL VALIDATOR
CONFIG.
Update bill security levels
ACK
----->
<--------->
----->
<--------->
----->
<--------->
Bill Validator is initializing
Collect operational
parameters
----->
<-----
IDENTI
FICATI
ON
Reset peripheral
Collect asset inf.
BILL VALIDATOR
ID
INITIALIZE
Bill Validator is
initializing
BILL STACKED
Bill Validator confirmation
signal
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
Page 97 of 98
POLL
ACK
----->
<--------->
UNIT DISABLE
CashCode Company Inc
PT# MAN_CCNET Rev.2.3.1 NOV 2002
All bill types are disabled
Page 98 of 98
You might also like
- JCM Validators Basic Drivers: Current VersionsNo ratings yetJCM Validators Basic Drivers: Current Versions2 pages
- GAMING - Generic EBDS Interface Manual - 002850110 - G8 PDFNo ratings yetGAMING - Generic EBDS Interface Manual - 002850110 - G8 PDF85 pages
- Cashflow SC Series Customer Interface Manual - 002850103 - G7 PDF100% (2)Cashflow SC Series Customer Interface Manual - 002850103 - G7 PDF46 pages
- iPRO RC Operation and Maintenance Manual PDFNo ratings yetiPRO RC Operation and Maintenance Manual PDF146 pages
- Nv9 Usb Operations Manual: Intelligence in ValidationNo ratings yetNv9 Usb Operations Manual: Intelligence in Validation40 pages
- The Fujitsu F53: Multi Cassette Media DispenserNo ratings yetThe Fujitsu F53: Multi Cassette Media Dispenser2 pages
- RETAIL EBDS PROTOCOL SPECIFICATION With MPOST G2No ratings yetRETAIL EBDS PROTOCOL SPECIFICATION With MPOST G2128 pages
- Where Can The DIP Switch Function Definitions Be Found For The IVIZION Validator - SFLB .AshxNo ratings yetWhere Can The DIP Switch Function Definitions Be Found For The IVIZION Validator - SFLB .Ashx2 pages
- KITTY CASH - Setup and Configuration v1.3 - enNo ratings yetKITTY CASH - Setup and Configuration v1.3 - en40 pages
- Nternal Nformation Ulletin: M C B A STS A 4.5 ANo ratings yetNternal Nformation Ulletin: M C B A STS A 4.5 A7 pages
- SM Backload Bill Validator: Operation and Service Manual Part 1. Operation ManualNo ratings yetSM Backload Bill Validator: Operation and Service Manual Part 1. Operation Manual38 pages
- Manual Op Mo Gen JCM Wba-Series Row 1.2No ratings yetManual Op Mo Gen JCM Wba-Series Row 1.214 pages
- ENG09-438 Cash Fever Configuration Guide 1.4No ratings yetENG09-438 Cash Fever Configuration Guide 1.428 pages
- VOLCANO ISLAND - Setup and Configuration v1.1 - enNo ratings yetVOLCANO ISLAND - Setup and Configuration v1.1 - en44 pages
- Status Viewer Utility Instructions: GEN2™ Family of PrintersNo ratings yetStatus Viewer Utility Instructions: GEN2™ Family of Printers12 pages
- The Standard in Coinless Gaming: (Intelligent Ticket Handling)100% (1)The Standard in Coinless Gaming: (Intelligent Ticket Handling)2 pages
- 16-022128-02 Wms Video Service Manual & User GuideNo ratings yet16-022128-02 Wms Video Service Manual & User Guide134 pages
- Frontload Series Frontload Bill Validator: Operation and Service Manual Part 1. Operation ManualNo ratings yetFrontload Series Frontload Bill Validator: Operation and Service Manual Part 1. Operation Manual63 pages
- Technical Bulletin: Mikohn SIB2 Firmware, MS27 To SAS ConverterNo ratings yetTechnical Bulletin: Mikohn SIB2 Firmware, MS27 To SAS Converter9 pages
- Mermaid S Spell - Setup and Configuration v1.3 - enNo ratings yetMermaid S Spell - Setup and Configuration v1.3 - en41 pages
- 95-06360 REV. J INSERT-Epic 950 Spare Parts GuideNo ratings yet95-06360 REV. J INSERT-Epic 950 Spare Parts Guide30 pages
- Linux Kernel Programming: A comprehensive and practical guide to kernel internals, writing modules, and kernel synchronizationFrom EverandLinux Kernel Programming: A comprehensive and practical guide to kernel internals, writing modules, and kernel synchronizationNo ratings yet
- NCR 5942 LCD Parts Identification ManualNo ratings yetNCR 5942 LCD Parts Identification Manual24 pages
- NCR RealPOS 5954 USB DynaKey Parts Identification ManualNo ratings yetNCR RealPOS 5954 USB DynaKey Parts Identification Manual13 pages
- Rajasthan Board Class 12 Physics Ss 40 1 2018No ratings yetRajasthan Board Class 12 Physics Ss 40 1 20188 pages
- Premature Failures in Plate Bonded Strengthened RC Beams With An Emphasis On Premature Shear A Review PDFNo ratings yetPremature Failures in Plate Bonded Strengthened RC Beams With An Emphasis On Premature Shear A Review PDF13 pages
- YANMAR-YD25 Operation Manual 164100-29010No ratings yetYANMAR-YD25 Operation Manual 164100-2901020 pages
- Density, Relative Density and API Gravity: According To IP559 and ASTM D7777No ratings yetDensity, Relative Density and API Gravity: According To IP559 and ASTM D77771 page
- Cambridge IGCSE: Additional Mathematics 0606/23No ratings yetCambridge IGCSE: Additional Mathematics 0606/2316 pages
- OCT Retiview 500 Optical Coherence Tomography: FeatureNo ratings yetOCT Retiview 500 Optical Coherence Tomography: Feature7 pages
- Kahneman A Psychological Perspective of EconomicsNo ratings yetKahneman A Psychological Perspective of Economics8 pages
- Compellent Storage Center (Advanced Administration) Training Guide - IntroNo ratings yetCompellent Storage Center (Advanced Administration) Training Guide - Intro12 pages
- ELTR 270 - Diode Practice Problems and Solutions100% (1)ELTR 270 - Diode Practice Problems and Solutions33 pages
- Traditional Advanced Control StrategiesNo ratings yetTraditional Advanced Control Strategies48 pages
- GAMING - Generic EBDS Interface Manual - 002850110 - G8 PDFGAMING - Generic EBDS Interface Manual - 002850110 - G8 PDF
- Cashflow SC Series Customer Interface Manual - 002850103 - G7 PDFCashflow SC Series Customer Interface Manual - 002850103 - G7 PDF
- Nv9 Usb Operations Manual: Intelligence in ValidationNv9 Usb Operations Manual: Intelligence in Validation
- Where Can The DIP Switch Function Definitions Be Found For The IVIZION Validator - SFLB .AshxWhere Can The DIP Switch Function Definitions Be Found For The IVIZION Validator - SFLB .Ashx
- SM Backload Bill Validator: Operation and Service Manual Part 1. Operation ManualSM Backload Bill Validator: Operation and Service Manual Part 1. Operation Manual
- VOLCANO ISLAND - Setup and Configuration v1.1 - enVOLCANO ISLAND - Setup and Configuration v1.1 - en
- Status Viewer Utility Instructions: GEN2™ Family of PrintersStatus Viewer Utility Instructions: GEN2™ Family of Printers
- The Standard in Coinless Gaming: (Intelligent Ticket Handling)The Standard in Coinless Gaming: (Intelligent Ticket Handling)
- 16-022128-02 Wms Video Service Manual & User Guide16-022128-02 Wms Video Service Manual & User Guide
- Frontload Series Frontload Bill Validator: Operation and Service Manual Part 1. Operation ManualFrontload Series Frontload Bill Validator: Operation and Service Manual Part 1. Operation Manual
- Technical Bulletin: Mikohn SIB2 Firmware, MS27 To SAS ConverterTechnical Bulletin: Mikohn SIB2 Firmware, MS27 To SAS Converter
- Mermaid S Spell - Setup and Configuration v1.3 - enMermaid S Spell - Setup and Configuration v1.3 - en
- Linux Kernel Programming: A comprehensive and practical guide to kernel internals, writing modules, and kernel synchronizationFrom EverandLinux Kernel Programming: A comprehensive and practical guide to kernel internals, writing modules, and kernel synchronization
- NCR RealPOS 5954 USB DynaKey Parts Identification ManualNCR RealPOS 5954 USB DynaKey Parts Identification Manual
- Premature Failures in Plate Bonded Strengthened RC Beams With An Emphasis On Premature Shear A Review PDFPremature Failures in Plate Bonded Strengthened RC Beams With An Emphasis On Premature Shear A Review PDF
- Density, Relative Density and API Gravity: According To IP559 and ASTM D7777Density, Relative Density and API Gravity: According To IP559 and ASTM D7777
- OCT Retiview 500 Optical Coherence Tomography: FeatureOCT Retiview 500 Optical Coherence Tomography: Feature
- Compellent Storage Center (Advanced Administration) Training Guide - IntroCompellent Storage Center (Advanced Administration) Training Guide - Intro