Vending Machine/Cashless Device
Thanks to pledges from our members we able to acquire a second hand vending machine.
Quick details
- Westomatic
- 6 shelves, 31 vent slots
- Missing the coin mech, about £100 off eBay to replace
- Missing lock, £12 off eBay
- Seller said there was an issue with the refrigeration unit, something about a probe (possible temperature probe --'RepRap' Matt)
- MCU is a MC68HC11E1CFN2 ('RepRap' Matt I have a few 68HC11E1CFN3's of we ever wanted to swap out for our own logic)
- All Coin mech's use a common protocol called the Mulit-Drop Bus, pdf of this here: File:MDB 3.0.pdf
- Adding RFID payment using same members cards as use for Gatekeeper
- This is made very easy due to the MDB spec
- Looks like firmware might be stores on the UV erasable EPROM chip next to the MCU
Items for sale
- This needs updating - Matt Little*
Location | Item | Description | Maker | Cost |
---|---|---|---|---|
A1 | Sugru - Red | Air setting plastic | Sugru | £2 |
A3 | Sugru - Red | Air setting plastic | Sugru | £2 |
A5 | Sugru - Red | Air setting plastic | Sugru | £2 |
A7 | Sugru - Red | Air setting plastic | Sugru | £2 |
MDB/ICP protocol
The Multi-Drop Bus/Internal Communications Protocol is a voluntary standard for vending machine communication. This is a serial bus interface working at 9600baud in a master-slave arrangement, where the vending machine controller is the master.Each peripheral is assigned a unique address and command set.
MDB has support for the following devices:-
- Coin Changer
- Bill Validator
- Cashless devices
- Communications Gateway
- Universal Satellite Device
- Coin Hopper or Tube Dispenser
In order to operate the serial line as a bus with multiple devices attached MDB uses a 9bit serial over the traditional 8bit, 9n1 vs 8n1 The master Poll's each device for activity, all communication sessions are initiated by the master addressing a slave, slaves are only allowed to respond when addressed, this prevents bus collisions.
The master indicates an address byte/start of session by setting the 9th bit, the correct slave responds as needed and on sending it's last byte it also sets the 9th bit to indicated end of it's session (although the master will ACK this)
We've started build now on own home grown Cashless Device
Vending machine dimensions
There are two sizes of slot in the vending machine. I'll call them big and small. The max dimensions are as follows:
- Big: 135mm width x 160mm high x 40mm depth
- Small: 60mm width x 120mm high x 20mm depth
We should ensure that all kits/packets to be sold are within these dimensions. A C6 envelope (designed to hold a 1/4 sheet of A4 (A6 size) piece of paper is 114mm x 162mm. This will probably fit in fine.
The labels for the slots are 19mm high (so you can do prices and other labels).
The MDB spec already takes into account cashless devices, so we simply have to build a device that conforms to the spec.
Device Level
The specification defines 3 levels of cashless devices, with more more features the higher the level. The Vending Machine (VMC) also has a level, and a device and VMC can only communicate using the highest commonly supported level. As our VMC is only level 1, we only need to implement a level 1 cashless device.
So let's look at what a level 1 device needs to do. Here we will reference commands by their plain English names. For the technical details on these commands, please refer to the specification section 7. For details on how these commands are sent/received by the VMC, refer to secitons 2,3 and 4.
States
The cashless device is basically a state machine with 5 states (7 for level 2 and 3 machines). These states are:
- Inactive
- Disabled
- Enabled
- Session Idle
- Vend
When turned on, the cashlss device enters state 1. Almost all state transistions are initiated by the VMC, with the exception of 3 -> 4, which is initiated by the cashless device on a valid card read.
If the cashless device receives a command it cannot act upon in its current state, or receives an unexpected command whilst in an uninterruptable state it must ACK(nowledge) the command, then on the next POLL from the VMC, issue a COMMAND OUT OF SEQUENCE response.
The VMC will then respond with a RESET command, putting the reader back to state 1.
Uninterruptable States
During certain command sequences, the VMC should not issue any additional commands to the cashless device. These are the Uninteruptable States. If the VMC does issue any additonal commands during one of thes states, the reader should responds with COMMAND OUT OF SEQUENCE, as noted above.
These sequences for a level 1 device are:
VMC Command | Cashless Device Response | Result |
---|---|---|
SETUP/CONFIGURATlON DATA | READER CONFIGURATION DATA | |
EXPANSION/REQUEST ID | PERIPHERAL ID | |
READER CANCEL | CANCELLED | |
VEND REQUEST... VEND CANCEL | VEND DENIED | |
VEND REQUEST | VEND DENIED | |
VEND REQUEST | VEND APPROVED | VEND SUCCESS |
VEND REQUEST | VEND APPROVED | VEND FAILURE |
SESSION COMPLETE | END SESSION |
The highlighted rows are all possible sequences in the vend state (state 5), so this state is completely uninterruptable.
Commands
Where a response is ACK, this can also be NAK (Not Acknowledged).
You will notice that some responses appear in the table twice. This is because the cashless device can respond ACK to a request for data, sending the data in response to a later POLL.
Command | Sub-command / Data | Response | Req? | Spec Page Num | Implemented? |
---|---|---|---|---|---|
Reset | (none) | ACK | Required | 102 | Yes |
Setup | Config Data | Reader Config Data | Required | 103 | Yes |
Max/Min Prices | ACK | Required | 106 | Yes | |
Poll | (none) | Just Reset | Required | 108 | Yes |
Reader Config Data | Required | 108 | No | ||
Display Request | Our VMC doesn't support this! | 108 | No | ||
Begin Session | Required | 109 | No | ||
Session Cancel Request | Required | 112 | No | ||
Vend Approved | Required | 112 + 123 | No | ||
Vend Denied | Required | 113 + 123 | No | ||
End Session | Required | 113 + 126 | No | ||
Cancelled | Required | 113 + 133 | No | ||
Peripheral ID | Required | 113 | No | ||
Malfunction / Error | Required | 115 | No | ||
Command Out of Sequence | Required | 116 | No | ||
Diagnostic Response | Required | 122 + 147 | No | ||
Vend | Vend Request | Vend Approved | Required | 123 | No |
Vend Denied | Required | 123 | No | ||
Vend Cancel | Vend Denied | Required | 125 | No | |
Vend Success | ACK | Required | 125 | No | |
Vend Failure | ACK | Required | 126 | No | |
Session Complete | End Session | Required | 126 | No | |
Cash Sale | ACK | ?? | 127 | No | |
Reader | Reader Disable | ACK | Required | 132 | Yes |
Reader Enable | ACK | Required | 132 | Yes | |
Reader Cancel | Cancelled | Required | 133 | No | |
Expansion | Request ID | Peripheral ID | Required | 138 | No |
Diagnostics | Diagnostic Response | Optional? | 147 | No |
Command Sequences
- All sequences are shown from the point of view of the cashless device.
- CHK indicate the calculated CHK byte
- * indicates the mode bit is set.
Start Up / Reset
The only difference between these two sequences is the beginning. The start up sequence begins when the cashless device receives an address command from the VMC, the reset sequence when the cashless device receives a RESET command.
The only difference between these commands is that the mode bit is set. (--'RepRap' Matt 20:12, 16 August 2011 (BST) this is incorrect)
Command Received | Command Sent | Data | Hex | Current State |
---|---|---|---|---|
For Startup only | ||||
Address | {none} | 10H* CHK | X | |
ACK | (none) | 00H* | X | |
For Reset only | ||||
RESET | (none) | 10H* CHK | X | |
ACK | (none) | 00H* | X | |
POLL | (none) | 12H* CHK | X | |
JUST RESET | (none) | 00H CHK* | X | |
For Both | ||||
SETUP CONFIG DATA | feature level, columns on display, rows on display, display info | 11H* 00H 01H 00H 00H 00H CHK | X | |
READER CONFIG DATA | feature level, country code high, country code low, scale factor, decimal places, app max response time, misc | 01H 01H 18H 26H 05H 02H 0AH 00H CHK* | X |
Not true!