E 10210 12 - 2005
Protocols:
MODULAR X6 CCTALK VALIDATOR 38
the Machine to carry out the request at a speed faster than the introduction of coins and not
lose any information of credits or events.
Send:
[Dir] [0] [1] [229] [Chk]
Reply:
[1] [11] [Dir] [0] [Data 1] [Data 2] ... [Data 11] [Chk]
-> ACK with 11
data
Where
Dir = address of the corresponding validator
Data 1 = event counter: 0 – on or reset, 1 to 255 – counter.
Data 2 = result 1A: 0 – there is an error, 1 to 16 – credit (output code of the
coin).
Data 3 = result 1B: 1 to 255 – error code, 1 to 5 – path of sorter......
Data 10 =result 5A
Data 11 =result 5B
A new event makes the data rotate in the buffer, and the last event is lost.
The event counter indicates to the Machine any new event that happens in the validator, and
for each request it should compare the counter with the last known value.
The event counter is incremented each time that a new credit or error is added to the buffer.
When the counter reaches 255, the following event makes the counter take the value 1. The
only way the event counter is at 0 is that there has been a power or reset. It is a good way of
informing the Machine of a fault in the power supply.
Each event is represented by two bytes (x = 1, 2, 3, 4, and 5):
-
result(x)A: indicates that a error has occurred (value = 0)
code of the coin that has been introduced (value = 1 to 16)
-
result(x)B: error code (if result(x)A = 0). See Table 8.
= 0 if there is not an error.
