Two of the most oft-mentioned and misunderstood technologies in our industry are MDB (multi-drop bus) and DEX (digital exchange). It amazes me how frequently I hear people confuse MDB and DEX, as if they are related. Allow me to end that rumor right here. The only correlation between DEX and MDB is that they are two separate and distinct technologies that happen to reside in modern day vending machines.
DEX BRINGS IMPROVED AUDIT
DEX was brought to the industry in the late 1980s to provide better audit capabilities. The bottlers brought DEX, a uniform commercial code set up across many industries, to vending when they implemented DEX for communications between a route handheld and a grocery store’s computer system. Since many bottler route drivers performed direct store delivery (DSD) as well as service of can/bottle machines, it made sense for their handheld to communicate with the vending machines they serviced as well as the stores. As often happened due to their size, resources and commitment to implementing technology, the bottlers took the leadership position, and the National Automatic Merchandising Association Technology Committee (made up mostly of engineers and industry suppliers) followed suit, adopting DEX as our industry standard.
VENDING USAGE INFORMATION
So what is DEX? DEX is our standard for an ASCII code-based electronic audit file, a way to communicate information such as sales, cash in bill validators, coins in coin boxes, sales of units by selection, pricing, door openings, and much more. It is created either locally by the VMC (Vending Machine Controller often called the “brain” of an electronic machine) or created by a retrofit DEX device in older electromechanical (dip switch) machines.
DEX is the result of the VMC storing information on an interval basis (the interval of time since the last DEX reading) and cumulative basis (since the VMC was first installed or the machine went into service). The VMC accumulates the data and transmits it in DEX format (see sidebar) over the DEX port when requested.
DEX data is quite useful and extensive. It eliminates the need for route people to write what they loaded into a machine on a route card. It also makes it unnecessary to manually input this information into a handheld. But the feature of DEX that gets most companies excited and starting to “DEX” their machines is the accuracy of cash accountability. There is no more second guessing what was to be collected out of the machine.
DEX IMPROVES ROUTE ACCOUNTING
DEX data is downloaded to a handheld device or transmitted via a remote monitoring device over to software that can parse the information into useful reports. DEX is downloaded using a 0.25-inch stereo plug (exactly like the one with your old stereo headphones from the 70s). When downloaded to a handheld, DEX is parsed and compared to planogram information unique to that machine that was stored in the handheld. This informs the route driver how many units of each product he/she has to load back into the machine to bring it back up to par.
Remote monitoring devices (wireless, LAN or telephone) can forward DEX, usually via the Internet, to a central computer where the software performs the same tasks as the handheld, but from the headquarters. This gives vendors the opportunity to pre-assemble items for locations before drivers leave and efficiently pack route trucks with only the necessary products.
Approximately 60 to 70 percent of the machines currently deployed have “native” DEX, meaning the machines come with a VMC that produces DEX. Sometimes a newer version of firmware for the VMC and a DEX download cable are required to be added to enable DEX.
Older electronic and electromechanical machines not equipped with DEX can be retrofitted with either a new VMC that provides DEX (and many of the features found in new machines) or with a retrofit DEX audit device.
DEX File Interpretation Chart - View this chart in PDF format.
MULTI DROP BUS RELATES TO PAYMENT
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.
Some cashless and remote data communication providers choose to bypass DEX and derive audit information from MDB communications. While it is possible to derive sales and selection choices, the information produced by MDB is not as detailed as DEX, because it was never intended to be.
DEX and MDB are clearly distinct technologies. DEX allows product auditing, cash accountability and possible pre-kitting, while MDB is the means in which various transactional devices operate and communicate with the brains of the vending machine. DEX is used with a handheld unit or remote monitoring, of which the MDB is an internal component. Both DEX and MDB were meant to make it easier to deploy useful technology in vending equipment.
