Im looking fordward to integrate a coin acceptor into one of our divices. This specific coin acceptor CF7000 uses the ccTalk protocol I've been working with the default libraries provided from the supplier which I can use in C#, however i want to see if its possible Find and USE a C# Function equivalent to the cctalk protocol and if possible use it directly into my C# code i have been using ILSpy to open and explore the libraries provided and found this function that opens the device so it can recieve coins and store them in my code all i have to type is: in order for the device to call the following function inside the library Now what i want to do is Find the CCTalk Protocol equivalent to this library function, in order for me to interact with the device, without the need to call the function from the library, however im not so sure this is easy or possible hopefully someone here might have a little bit more experience with this
GoatZeroGoatZero
1 AnswerIn order to do what you want you have to communicate directly to the USB/Serial port and send directly the commands you want, and then build your own library or helper functions.
Hope I've helped.
MRodriguesMRodrigues
Not the answer you're looking for? Browse other questions tagged c#serial-portprotocolscctalk or ask your own question.This library aims to provide support for various peripheral devices that use the ccTalk protocolover a serial line or serial line emulation over USB. It's primary target is the EMP800 bywh Münzprüfer Berlin. At the moment this is very much a work in progress. APIThe API is object oriented and uses several proxy objects to model parts of the physical hardware. TypesCCBusA bus object is used to interface devices that share a common data line. It stores the hostconfiguration and can be explicitely or implicitely constructed (if only one device is used). new CCBus(port, config)Constructs a new bus object. Arguments:
ccBus.registerDevice(device)Adds a device to the internal list of devices managed by this host. Argument:
ccBus.sendCommand(command)Sends a command to the bus and waits for a reply. Argument:
ccBus.sendRawCommand(command)Sends a command to the bus without waiting for previous commands to be sent or the reply from the device. Mostlyfor internal use. Argument:
CCCommandAn object describing data sent to a devices or received from a device. new CCCommand(src, dest, command, data)Constructs a new command object from parameters. Arguments:
new CCCommand(buffer)Parses a new command object from raw data. Serial InterfaceArguments:
ccCommand.toBuffer()Converts the command to raw data. Returns:
CCDeviceAn object describing a generic device. It can be used to implement more high-level device proxies. new CCDevice(bus, config)Constructs a new device proxy. Optionally also create a new bus object. Arguments:
The constructor will store the bus to use in ccDevice.bus but will not call ccDevice.bus.registerDevice() yet,as additional set-up needs to be done before a raw ccDevice object can be used. new CCDevice()Constructs a new ccDevice object to use as a prototype for the implementation of a proxy object forspecific device types. ccDevice.onBusReady()Called by the bus object when the serial interface is open. ccDevice.onData(command)Called by the bus object when a reply has been received from the device. Arguments:
ccDevice.onBusClosed()Cctalk Serial InterfaceCalled by the bus object after the serial port has been closed. ccDevice.sendCommand(command)High-level API to send commands and receive replies. Arguments:
CoinDetectorFinally something useful! Implements a coin acceptor. TODO Document API DisclaimerccTalk may be a registered trademark of Money Controls or Crane Payment Innovations. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Jump to navigationJump to searchccTalk (pronounced see-see-talk) is a serial protocol in widespread use throughout the money transaction and point-of-sale industry. Peripherals such as the currency detectors for coins and banknotes found in a diverse range of automatic payment equipment such as transportation, ticketing, payphones, amusement machines, and retail cash management use ccTalk to talk to the host controller. The ccTalk protocol is one of 2 protocols specified by BACTA for use in all AWP machines with serial coin acceptors. (The other is the Host Intelligent Interface protocol developed by Mars Electronics International).[1]:20 The protocol was developed at a company called Coin Controls (hence coin-controls-talk, later called Money Controls and from 2010 Crane Payment Solutions) on the outskirts of Manchester in north-west England mainly by Engineer Andrew William Barson. The first release of the protocol was in 1996.[2] The ccTalk protocol is an open standard.[1]:13 The protocol uses an asynchronous transfer of character frames in a similar manner to RS232. The main difference is that it uses a single two-way communication data line for half-duplex communication rather than separate transmit and receives lines. It operates at TTL voltages and is ‘multi-drop’ i.e. peripherals can be connected to a common bus and are logically separated by a device address. Each peripheral on the ccTalk bus must have a unique address. Download avenir t1 45 book font free. The original protocol operated at 4800 baud with subsequent releases standardising on 9600 baud. Low cost bridge chips are now available from a number of manufacturers to allow ccTalk to run over USB at baud rates of at least 1 Mbit/s. ccTalk protocol stacks have been implemented on a range of devices from tiny Microchipmicrocontrollers with 512 bytes of ROM to powerful ARM7 32-bit processors.[1]:12-13 The protocol supports all standard operations for electronic devices such as flash upgrading of firmware, secure transfer of data and detailed diagnostic information. Advantages of ccTalk include low cost UART technology, a simple-to-understand packet structure, an easily expandable command interface and no licensing requirements. The latter affords the protocol a good deal of popularity in a crowded and highly competitive field similar to open-source software. In 2010, DES encryption was added to certain commands so that it could be made more resilient against attacks on the bus.[2]Each peripheral has its own unique DES key.[3][4] An Example ccTalk Message Packet[edit]TX data = 2 0 1 245 8
This is a message from address 1 ( the host ) to peripheral address 2 to find out what it is. RX data = 1 13 2 0 67 111 105 110 32 65 99 99 101 112 116 111 114 22
The reply from address 2 back to address 1 identifies it as a coin acceptor. Details[edit]The ccTalk protocol is a byte-oriented protocol. The series of bytes in a message -- represented above as a series of decimal numbers -- is transmitted as 8-N-1. Many devices have single electrical connector that carries both power (typically +12 V or +24 V) and the ccTalk data over a total of 4 wires. To reduce cost, for short interconnection distances CPI recommends sending ccTalk data over an unbalanced multi-drop open-collector interface: both transmit and receive messages occur on the same bi-directional serial DATA line at TTL level, driven through an open-collector NPN transistor.The pull-up resistor at the host pulls the DATA line to +5 V, so logical 1 (and idle) is nominally +5 V, and logical 0 (and start bit) is nominally 0 V.[1]:15,17For longer distances, CPI recommends sending ccTalk data over a balanced multi-drop RS-485 driver interface, also nominally +5 V and 0 V.[1]:17 Secure peripherals require all bytes of a message to be encrypted, except for the first two bytes -- the destination address byte and the.Issue 4.7
Comments are closed.
|