6.2.4
Data
There is no limitation in use of data formats. Data could be BCD (
B
inary
C
oded
D
ecimal
)numbers, Hexa numbers or
ASCLL strings. Intrepretation as well as format is specific to each header use, and will be explained in separate chapter.
6.4.5 Checksum
Message integrity during transfer is checked by use of simple zero checksum calculation.
Simple checksum is made by 8 bit addition (modulus 256) of all the bytes in the message. If message is received and
the addition of all bytes are non-zero then an error has occurred (See Error handling).
For noisy environment or higher security application it is possible to use more complex, 16 bit CRC CCITT checksum
based on a polynomial of:
x16 + x12 + x5 + 1
and initial value of CRC register
0x0000
.
Hopper are using simple checksum, but they could be set to operate with CRC-16 checksum on customer demand.
6.5
Timing specification
The timing requirements of cctalk are not very critical but there are some recommendations (i.e. more than 100 mili sec
for solenoid testing).
6.5.1
Time between two bytes
When receiving bytes within a message packet, the communication software must wait up to
50 ms
for next byte if it is
expected. If time out occurs, the software should reset all communication variables and get ready to receive next
message. The inter-byte delay during transmission should be ideally
less than 2 ms
and
not greater than 10 ms
.
6.5.2
Time between command and replay
The time between command and reply is dependent on application specific for each command. Some
commands return data immediately, and maximum time delay should be within
10 ms
. Other commands
that must activate some actions in device may return reply after the action is finished
6.5.3
Start-up time
After the power-up sequence Hopper should be ready to accept and answer to a cctalk message
within time period of less than 250 ms. During that period all internal check-up and system settings
must be done, and Hopper should be able works fine.
6.4
Error handling
If slave device receive the message with bad checksum or missing data no further action is taken and receive buffer will
be cleared. Host software should decide to re-transmit message immediately or after a fixed amount of time. In case
when host receive message with error it has same options.
6.5
Command headers
Command header set, that host could use in communication with coin selectors AL55 and AL66 is given in the table 6.2.
254
FE
Simple poll
228
E4
Modify master inhibit status
253
FD
Address poll (broadcast)
227
E3
Request master inhibit status
252
FC
Address clash (no broadcast)
226
E2
Request insertion counter
252
FC
Address clash (broadcast)
225
E1
Request acceptance counter
251
FB
Address change (not supported in coin acceptors)
210
D2
Modify sorter paths
249
F9
Request polling priority
209
D1
Request sorter paths
248
F8
Request status
197
C5
Calculate ROM checksum
246
F6
Request manufacturer id
196
C4
Request creation date
245
F5
Request equipment category id
195
C3
Request last modification date
244
F4
Request product code
194
C2
Request reject counter
242
F2
Request serial number
193
C1
Request fraud counter
241
F1
Request software revision
192
C0
Request build code
240
F0
Test solenoids
188
BC
Request default sorter path
237
ED
Read input lines
184
B8
Request coin id
236
EC
Read opto states
170
AA
Request base year
232
E8
Perform self test
4
04
Request comms revision
231
E7
Modify inhibit status
3
03
Clear comms status variables
230
E6
Request inhibit status
2
02
Request comms status variables
229
E5
Read buffered credit or error codes
1
01
Reset device
Table 6.2 cctalk instruction header list
Summary of Contents for AL66 FG ARM
Page 1: ...AL66 FG ARM Pulse mod ccTalk COIN ACCEPTOR Operator s Manual Rev 2 01 User Manual...
Page 2: ......
Page 34: ......
