Now let’s make same tests with a coin acceptor. On my bench I have an old SR3 from Moneycontrols. There are some differences from bill acceptor handling but they work pretty much in the same way:
- See if a coin acceptor is connected
- Read some info about it
- Find the number and type of coins accepted
- Check it’s health
- Enable the coins you want to be accepted
- Master enable the coin acceptor
- Poll for events
On a bill acceptor you have an option to keep a bill in escrow until the host instruct the bill acceptor to route or reject the bill with Header 154 – “Route bill” Usually a coin acceptor cannot keep a coin in escrow. It either reject or accept the coin. This can allow an unwanted coin to be accepted before he host can disable the coin acceptor. On some coin acceptors there is a different mechanism with Header 135 – “Set accept limit” which instructs the slave to disable itself after a specified number of coins.
Also for the coin ID there is a exponential format but the most common is still CCVVVR two characters for country , three for the value and one for the revision. Notice that there are only three chars for the value. For 1 Eur revision A the coin ID would be EU100A and for 10 cents revision B EU010B.
It is less common in coin acceptors to have more or less than two bytes inhibit mask ( 16 coin channels) , some are using only 12 coin channels like SR3 that we will use in this post.
Also , I noticed that Header 228 – “Modify master inhibit status” is not implemented on SR3 , tough , the Header 229 – “Request master inhibit status” is, and answers always on. That’s why we will skip step 6 and keep in mind not to rely even on headers specified in “minimum acceptable implementation” and always read the products ccTalk documentation.
For coin acceptors a slightly different mechanism is used to avoid accepting coins while the host is not available. Usually the coin acceptor is enabled on power on but if not polled for events for few seconds it disables itself. On the next pool the coin acceptor turns on the acceptance without having to issue a master enable command.
To read the event queue a different header is used , header 229 – “Read buffered credit or error codes” and also for coin value the header is different, header 184 “Request coin id”
If you’re not familiar with Realterm settings and ccTalk cable needed see previous posts
We’re using slave address 2 for coin acceptors
1. See if a coin acceptor is connected using header 254 , “simple pool” , send data: 2 0 1 254 255 answer 1 0 2 0 253 ACK where 2= slave address – coin acceptor, 0 = data field length 1 source address – master , 254 header – “simple pool” and 255 checksum as the total sum modulo 256 to be zero (simple checksum). The answer is the typical acknowledge with no data field and header field set to zero.
2. Read some info about it “Request manufacturer id” , Header 246 send 2 0 1 246 7 answer 1 14 2 0 77 111 110 101 121 32 67 111 110 116 114 111 108 115 115 ,translated into ASCII the data field ( byte 5 to byte 18) is “Money Controls“.
“Request equipment category id” Header 245, send 2 0 1 245 8 , and the answer in ASCII will be “Coin Acceptor”
3. Find the number and type of coins accepted.
First we use header 230 – “Request inhibit status” not to really see the inhibit status , just to see how many coin channels we have. Send 2 0 1 230 23 and receive 1 2 2 0 255 15 237. There are two data bytes 255 and 15. We see that the coin channels 1 to 12 are already enabled , I know that SR3 have 12 coin channels available , on this one only four are programmed.
Now we use header header 184 “Request coin id” with one byte data field meaning the coin position from 1 to 12 to find the coin value for each coin position. Since the answers data field is in ASCII I will keep only the data field but the answer is also in the same format: source , data length , destination ,header zero as in all answers from the slave except for busy or NACK, data field and checksum.
coin 1 -send 2 1 1 184 1 67 – answer – EU100A
coin 2 -send 2 1 1 184 2 66 – answer – EU050A
coin 3 -send 2 1 1 184 3 65 – answer – EU010B
coin 4 -send 2 1 1 184 4 64 – answer – EU005A
coin 5 -send 2 1 1 184 5 63 – answer – ……
coin 6 -send 2 1 1 184 6 62 – answer – …… and so on
To be continued
ccTalk tutorial 