Vending Machine/Cashless Device: Difference between revisions
No edit summary |
|||
(6 intermediate revisions by 5 users not shown) | |||
Line 1: | Line 1: | ||
===MDB/ICP protocol=== | ===MDB/ICP protocol=== | ||
Line 73: | Line 18: | ||
We've started build now on own home grown [[Vending Machine/Cashless Device|Cashless Device]] | We've started build now on own home grown [[Vending Machine/Cashless Device|Cashless Device]] | ||
The MDB spec already takes into account cashless devices, so we ''simply'' have to build a device that conforms to the spec. | The MDB spec already takes into account cashless devices, so we ''simply'' have to build a device that conforms to the spec. | ||
Line 254: | Line 189: | ||
[[Category:Projects]] | [[Category:Projects]] | ||
[[Category:Projects (complete)]] | |||
[[Category:Network]] | [[Category:Network]] | ||
[[Category:Instrumentation]] | [[Category:Instrumentation]] | ||
[[Category:Vending machine]] |
Latest revision as of 20:28, 20 January 2023
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
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!