DEX and MDB: A Primer For Vendors
Technology Basics 101: Both technologies are important but serve different functions.
MDB (multi drop bus) relates to the different payment systems interfacing together. When vending machines were electromechanical (using dip switches), bill validators and cashless systems had to run through the coin mechanisms. There were a slew of different connectors to interface to all the different types of coin mechs on the market, and it was very confusing since there was no industry standard. Even early electronic machines, which had VMC, didn’t have standard connections. They used a serial interface (such as MicroMech), but additional devices, like bill validators or cashless systems, still had to be connected to and emulate the coin mechanisms.
If it wasn’t for the NAMA and European Vending Association (EVA) getting together in the 1990s and working in a cooperative spirit to write the MDB specification, we would probably still be struggling through proprietary interfaces and the nightmare of connectors. MDB is an international standard co-authored by NAMA and EVA, and is present in almost every vending machine worldwide except for the Far East, which has its own standards.
MDB = ELECTRICAL BUS FOR INTERFACING
MDB was the first attempt by the industry to come up with a standard interface for all transactional electronic devices (i.e., coin mechanism, bill validator or cashless system) to be able to interface through an electrical bus to the VMC. This electrical bus provides one standard male and female connector, both of which are found on all MDB vending transactional electronic devices. An MDB device should have a y-MDB connection, providing for a piggyback connection from one MDB device to another.
I typically like to compare MDB to the USB port on a personal computer (PC). USB is an international electrical bus standard which supplies an electrical connection and protocol for connecting peripheral devices (such as a mouse) to a PC. Likewise, the MDB is the vending industry’s international standard for providing an electrical connection with protocol for peripheral devices (in this case, an example would be a coin mech) to the VMC.
The one thing MDB does that USB doesn’t do is that MDB provides sufficient power to operate the transactional device. (USB can power very low draw devices, but it wasn’t designed to power most PC peripheral devices.)
When an MDB device is connected to an MDB machine, the device identifies itself to the machine as to the type of device it is (coin mech, bill validator or cashless system) and the currency for which the MDB device is programmed to receive. The VMC recognizes and enables the MDB device for operation, after which the MDB device and VMC communicate constantly.
The dialogue establishes that a machine is active for taking in currency or cashless, transmitting each activity that occurs with the MDB device, such as each occurrence of a coin being accepted into a coin mechanism; a bill being accepted into a bill validator; or a credit card, tap-and-go device or keyfob being accepted by a cashless system). The machine establishes a monetary credit and shows the credit on the display.
Since the VMC is the brains of the machine, it determines if enough credit is present in the machine to enable a vend. When a vend occurs, the VMC communicates back to the transactional device MDB to complete the transaction. For a coin mech, it means pay back change; for a bill validator, stack the bill from escrow; for a cashless device, it means transmit the vend price and transactional information over to the processor or local card server (college); and for a stored value cashless system, it means writing new stored value back to the magnetic card or smart token or keyfob.
ERROR MESSAGE COMMUNICATION
One of the very nice features of MDB is that MDB devices communicate status to the VMC. This means if there is a problem with a device, the device communicates a message to the VMC indicating the error. Examples of this are bill jams, bill stacker capacity status, coin mech problems, etc. This feature is particularly useful when used with remote data collection systems, where error messages can be forwarded to field service personnel via text messages or email.
TRACKING VENDING ACTIVITY THROUGH MDB
When MDB was originally conceived, MDB communications was limited to transaction device identification and operational communications between the device and the VMC. Information such as vend selection was not available, mainly because it is internal to the VMC and does not need to be transmitted on the MDB.
Eventually, cashless device suppliers lobbied NAMA/EVA to change the specifications for the MDB to accommodate transmission of selection information on the MDB, so that information is now available.
