So I started writing this post back in October 2014 when I was developing hardware for use in vending machines at work. To be honest I forgot this post existed and since I've been cleaning up my blog I lately I figured this was worth posting even 5 years later.

There's vending machine all over the place that do a whole heap of different things (especially in Japan! They do some super creative vending there), from dispensing snack food to keeping track of safety equipment and consumables in factories and even dispensing insurance policies at airports. While the machines themselves do lots of different things the peripherals that deal with things like accepting payment are far more standardized and interchangeable. The Vending Machine Controller (VMC) has to communicate with the peripherals via some sort of interface including:

• The Multi Drop Bus protocol (often referred to via the acronym MDB)
• ccTalk
• Proprietary protocols

The MDB protocol, due to historical reasons, was very common in vending machines due to the standardization of the protocol across multiple Vending machine manufacturers. This is a distinctly pre-internet type of protocol. The specification of the MDB protocol itself can be found on the NAMA site: The MDB 4.2 specification (Note that version 4.2 was the most recent in 2014 and is still the most recent as of this post in June 2019) This protocol is somewhat easy to work with once you know how (assuming you have designed your software the right way for this mostly real time domain), but getting to know how to use is a bit tricky due to the lack of materials out there.

Back then I spent a bunch of time looking at the protocol both theoretically and how that practically translated to real equipment in the field. I created a microcontroller based translator for the Multidrop Bus protocol for connecting vending machines to embedded linux devices. This enabled modern embedded linux devices to connect to vending machines directly. there's a few things that came up while making this that I figure are worth mentioning:

• The standard is for 9bit serial (yes nine bits, this is not a typo), so make sure that your hardware can deal with it.
• The data line isn't RS232 or RS485, it's a 5volt transmission protocol. Additionally the levels on the Tx and Rx are not the same in both directions. The Tx line is standard, Rx line inverted.
• If you are making the circuit electrically isolated as suggested in the MDB specification then make sure that the devices you choose can handle the data rate.
• Don't send NAK from a peripheral. The standard doesn't really make this clear but you get annoying race conditions with multiple peripherals if the addressing byte gets garbled resulting in 2 devices thinking the message is addressed to them. One gets the message correctly but the other does not which then can cause one device to ACK and another to NAK at the same time. Because it is a bus setup the VMC can't tell which device NAKed or ACKed which leads to further problems.
• The way to deal with bad data from the VMC is just to ignore it, the VMC will attempt to resend it when no ACK is received.
• There's a limit on the response time for various commands, make sure you can respond in time. In practice the acknowledgement messages should be responded to within 5ms if you want to ensure wide compatibility with VMCs. If you are running an operating system that's not a real time operating system this timing requirement can lead to issues where the VMC assumes the device is offline if latency is too long in responding. It is also worth noting that all messages to the cashless device can either be responded to immediately or on the next poll.

Hopefully this helps you with your Vending Machine related projects!