Error Code 142 And Backward Compatibility

Between the release of RP 1210A and RP 1210B, VDA vendors made remarkable progress in adapter technology (i.e., USB, wireless, etc.) and some adapters are now powered by the PC (i.e., USB). Some adapters can be powered by other means such as an internal battery, alternating current (AC), etc. These types of "non-traditionally" powered adapters caused some concerns within TMC's RP1210 Update Task Force. The question/issue that was dealt with is:

• On a non-vehicle-battery-powered device, how does an API handle the case where the "physical" connection disappears (the link to the truck) but the "virtual/logical" connection persists (VDA-to-PC application link)? Does TMC create another error code in addition to "142 ERR_HARDWARE_NOT_ RESPONDING", or does TMC work something else into the specification?

Some of the points raised during discussions on this question included:

• Many RP 1210A applications are "keyed in" to getting a 142 ERR_HARDWARE_NOT_RESPONDING code back stating that something outside of the PC has gone wrong. Adding another error code could possibly cause confusion for RP 1210A-compliant applications that are running on RP 1210B (or later) VDAs.
• There needs to be a way to tell the user, in more detail, what is going on in an RP 1210-compiliant application running on top of an RP 1210B (or later) VDA.

TMC resolved the issue as follows:

• Error Code 142 ERR_HARDWARE_NOT_RESPONDING will remain the primary error code associated with any hardware problems. This way, older applications will continue to function as normal (no need for porting or re-write).
• A new function call called "RP1210_GetLastErrorMsg"  was added. This command will allow RP 1210B (or later) compliant applications to get extended error information from the RP 1210B (or later) VDAs about the specific reason a 142 ERR_HARDWARE_NOT_RESPONDING (or any other code) was returned.

The following paragraph deals with RP 1210B (or later) applications:

• An application can determine whether it is physically connected to the databus by repeatedly calling RP1210_GetHardwareStatusEx ()  and checking the correct bits to determine if the link has been active within the past one second second (note the RP 1210D addition of the RP1210_GetHardwareSta-tusEx ()  function). If you have an RP 1210B (or later) application working with an RP1210A adapter, the operation of this is vendor specific because it was implemented differently among RP 1210A VDA vendors.
  • Note that this may not apply to protocols that are send/expect such as using OBDII/J1979 using ISO15765, ISO9141, ISO14230, J1850VPW, or J1850PWM. The keep-alive message (J1979 request of Mode 1, PID 0) should at least provoke incoming message traffic every 5 seconds or so.
• RP 1210B (or later) applications should no longer depend solely on receiving the 142 Error Code and should use the RP1210_GetHardwareStatusEx ()  function.

Also refer to RP1210_GETERRORMSG ()  on RP1210_GETLASTERRORMSG .