LEMON Manuals: Even more car manuals for everyone: 1960-2025
Home >> Mercedes Benz >> 2025 >> eSprinter Base, _NA_ >> Repair and Diagnosis (Single Page) >> TMC Recommended Practices >> Onboard Vehicle Electronics >> RP 1210D - Windows (TM) Communication API >> RP 1210D - Windows(TM) Communication API >> RP 1210 Overview For The Application Developer >> Step 2 - Which Adapter To Use? >> Notes
April 5, 2026: LEMON Manuals is launched! Read the announcement.

Step 2 - Which Adapter To Use?: Notes

The second step that an application must perform is either asking the user which adapter to use.

Although auto-detection is a nice feature for an application to have, TMC strongly recommends that the application initially bring up a VDA selection dialog box. This information should include (at a minimum) the following dialog box items (see paragraph above on the "Name" parameter in the "[VendorInformation]" section of the vendor INI file):

As J1587 makes way for J1939 and ISO15765, applications have started using these protocols in conjunction with the J1587 protocol. Applications have been presenting users the choice of protocol to use, which has caused confusion and technical support calls when a VDA does not work with the application because the wrong protocol was selected by the end-user. TMC highly recommends that an application NOT require the user to select the protocol.

As OEMs have now implemented up to three CAN channels on the diagnostic connector, it is highly recommended that application developers auto-scan all CAN channels for their ECMs, or at least allow the user to choose the CAN channel instead of relying on VDA vendors developing special cables that take CAN2 or CAN3 and place them on the pins for CAN1 (no end-user likes having to purchase CAN "crossover cables").

If an application can, or does, use different protocols, or multiple CAN channels, TMC asks that the application pre-screen (not display) an adapter if it does not support "at least" their "primary/default" protocol. The application would then look to see if the primary is the correct protocol for the component, and if not, check if the adapter selected supports the secondary protocol. If the adapter supports the secondary protocol, automatically switch to that protocol. If the secondary protocol is not supported, alert the user. This keeps down the number of "selections" that a technician has to make, resulting in less confusion.