Alberici AL66 FG ARM Pulse, Руководство оператора

Страница: 14 / 36

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