![background image](http://html1.mh-extra.com/html/suzohapp/flow-18-cctalk/flow-18-cctalk_product-manual_1408277009.webp)
Manual 18-ccTalk
Version 0.6
Page 8
6.1. Serial Communication: More control over the devices
The machine controls the devices by sending data over the network, just like the famous RS232
communication network. The data consists of bytes that are grouped together to form ccTalk
messages. Each device has it's own set of command messages and has it's own unique ccTalk
address. If the machine sends a message to a hopper, it's will put the hopper's address into the
message and send it over the network to the hopper. The ccTalk protocol defines all messages that
are used to communicate with all devices. There are messages to start the hopper, stop the hopper,
return coin level, etc. So much more control over each device is achieved by using device control
messages.
6.2. Serial Communication: Fraud elimination?
The traditional way of hopper fraud would be to drill a hole into the machine cabinet and put 24V on
the proper wire of the hopper cable.
With a network, each device is controlled using serial data communication. Now you need a PC and
knowledge about the ccTalk command messages to start a hopper.
In order to make hopper fraud very difficult, some hopper manufacturers use sophisticated encrypted
pin codes in their commands in order to start a hopper. Others use simple codes in their commands to
start a hopper.
6.3. Serial Communication: Hopper responsibilities
Each ccTalk hopper is equipped with a microcontroller implementing the ccTalk protocol.
You have to define exactly what the hopper should do when it receives a command.
If the hopper receives a payout command, the hopper should start a payout only if the pin code is
correct. When it has paid the requested amount of coins it should stop automatically. It is the
responsibility of the hopper to stop when the requested amount of coins is paid.
6.4. Serial Communication: Bookkeeping
Some hoppers also count the number of coins paid and the number of coins unpaid and even have
short term and long term running counters. However is it practical to store all these numbers into the
hopper? The machine itself also has it's own copy of all running counters. How do you maintain
hopper data and machine data consistent? What happens with the data during a system reset or a
power down event? In general only the number of coins paid is the one that is most practical. If the
hopper is commanded to pay 10 coins and a power down event occurs, then after the power has
returned, the host machine should check how many coins the hopper has paid just before the power
failed. The machine should check this number with it's own records and take appropriate action.
During a power down, use the Emergency Stop command to stop the hopper if possible. This
command returns the number of unpaid coins for the current payout. Store this result in the memory of
the machine.
For hopper maintenance, the total number of coins dispensed during it's life would also be a useful
number.