Why do I need to use multi drop bus protocol (MDB) in vending machine and How?

Question

I have a project to build a vending machine but I am suffering from Scarce information about vending machines.

I could find some results :

• Inner protocol in vending machine and between the PC is called MDB and is specified by NAMA. This is a protocol between a master (VMC) and up to 32 slave (peripherals) and could be implemented using UART (according to protocol V3 ).
• cctalk is another protocol used for coin detector machines.
• There are lots of adapters and devices(all of which are closed source) that use this protocol.

According to this information why do I need to use the MDB protocol given that it is finally a UART connection? Why couldn't I use my own language (protocol) especially if I will build all of the peripheral by my self? What are the advantages and disadvantages?

Anyone looking for further information and resources is welcomed to read about either CCtalk or MDB .

Answer 1

If you are building a vending machine, unless there is legislation or client preferences about technology, then build it to suit the market you are aiming for and build it to maximize your profits. It's as simple as that.

On the other hand if you mean you are connecting various off-the-shelf parts together that communicate in a certain way then you'll need to find how that works.

Answer 2

The MDB protocol specifies the format for communications between the Vending Machine Controller (VMC) and the peripheral devices. The MDB protocol is more than just the serial frame types as it specifies the whole flow of a vending machine transaction amongst other things.

From a serial communications point of view, perhaps the most relevant factor is that the MDB protocol specifies 9bit serial. Specifically it's 9600 baud NRZ with 1 start bit, 8 data bits, 1 mode bit and 1 stop bit. (The mode bit is essentially just the 9th data bit). Because of this you must make sure that any UART you are using will actually support 9 bit mode. Additionally if you are interfacing with a preexisting VMC you have to be aware that the protocol specifies some hard limits on timing. Any peripheral must respond to a VMC poll within 5ms. Interfacing with computers/devices can be difficult because many serial ports and serial libraries only support 8bit serial. If you are connecting directly between a computer and a MDB VMC then you might not be able to guarantee a response within the amount of time specified in the standard, in which case a specialized device would be needed. These points (and more) were reasons for the MDB adapter project that was the designer for. Unfortunately for the purposes of the question this was a closed source project so I can't go into much more detail.

So if you plan to use pre-existing vending machine parts then using the MDB protocol might save troubles later. It should be noted that there's VMC manufacturers that are providing other interfaces than the MDB however the MDB protocol is currently the most widely supported protocol in the industry (as of the time of this answer).

If you are making something that will never be used with anything from the vending industry then feel free to use your own protocol if that provides a better ROI. If you are only connecting one device to the VMC then the MDB protocol might be overkill. If you do go down this route you might find some interesting ideas in the MDB protocol that are relevant to your design. Especially keep in mind the flow of transactions involved in a vend, this is probably one of the hardest things to get right.

Answer 3

Since vending machines handle money, they may be a target for attack, and security at all levels (mechanical, protocol, data security) then become important. Achieving these will be much easier following carefully engineered standard protocols (I am assuming the industry has put a lot of effort into this : if it hasn't, it is ripe for attack!) but it is not surprising if they are closed source.

If the vending machines are to be emptied and serviced by the usual trained staff, then either they must follow the exact same standards and protocols as other machines (and work with the same diagnostic/repair tools) - OR - you need to put in place a full training program and maintenance tool chain, and convince people that they can save money by learning something new.

Either of these are much bigger problems than actually designing and building a machine.

So it comes down to: if it's a one-off project, do what you want. But if it's a commercial project, either conform, or offer a genuine and compelling advantage.

Answer 4

The benefit of MDB is it is the most current, universal, and widely used communication system for vending machine parts. If a device for vending is made, you can rest assured that it is compatible with MDB. If you want your devices to be compatible with other machines, use MDB.

Earlier protocols include:

• Single Price Interface (Very outdated)
  • All parallel communication @ 120v, repricing was done by rearranging wires. This is a highly outdated interface that most vendors replace.
• LowLevel/HighLevel Pulse (bill validators, outdated but still in use)
  • This was in use right before MDB came out. A bit outdated, used a mix of serial and parallel communication. Still in use by outdated machines. The difference between low level and high level, is the voltage used to communicate. Low being 24v, and high being 120v.
• MicroMech (Coin Changers)
  • The protocol used alongside HLP/LLP bill validators. Basically identical except the connector looks a lot more like a smaller version of the SPI connector. Also there is a 24v version and 120v version. A 24v MM machine can use a 120v MM device if you add two jumpers to the connector, I believe the 120v versions just have solenoids designed for 120v use, which you can just supply 24v to.
• CCTalk
  • I've never used nor have I ever seen a device that uses this. Based on your wiki link, it's a contender to MDB that is vary similar but didn't quite make 1st place. I see the option to use it on most machines though.
• ID003
  • Another I have never seen, actually never heard of until I just googled it right now. It appears to be dominant in arcade games as the communications method for payment devices.

Answer 5

Why couldn't I use my own language (protocol) especially if I will build all of the peripheral by my self?

There is no reason at all.

Except for cost.

Both in time and in money.

It will take several man years, probably double digits, to develop and test each peripheral, such as coin/note/credit card acceptor.

It will take several man years to develop and test controller software.

Unless you have a production run in the thousands, you may not find any factory willing to manufacture your devices, and if you do they will still be more expensive than COTS devices, owing to economies from scale.

I am not saying that it can’t be done, but it almost certainly shouldn’t be done, unless you have a shed load of money and some major advantage which would allow you to corner a large section of the market.

Otherwise, it’s just a vanity project.