DEAD VOLT II

[cab]

The data-link connector (DLC) aka diagnostic test port was/is designed for just that- periodic diagnostic testing, and not meant to be used as a permanent installation. The diagnostic routines built into these tools utilize code that is capable of temporarily interrupting or interfering with the normal data traffic flow within the car that is sometimes necessary when following a diagnostic routine for typically only for relatively short periods.

However Controller Area Network (CAN) peripherals such as the Scangauge, DashDAQ and others are doing is much more than that, as they are essentially being wired-in permanently as a “gauge” that attempts to become a foreign member of the car's network. Depending on how closely the tool manufacturer has followed the GMLAN protocol (GM’s own customized implementation of CAN) these tools should typically be completely benign under most conditions and settings, but certainly CAN become overly intrusive and disrupt various data transmissions, depending on the specific implementation being used. (i.e. which modules are being accessed, how many modules are being simultaneously accessed, which data packets are being requested, and how often) This is especially true in “gauge” modes where a collection of data from more than 1 module is being requested. Even GM’s own scan tool equipment (Multiple Diagnostic Interface with GDS2 software) does NOT passively display data from more than 1 module at a time, as these gauges attempt to do so!

In this case I suspect Scangauge does NOT have a specific agreement with GM (such as DashDAQ does) to access anything other than basic ECM/TCM diagnostics and the EPA regulated “fair-use” aspects of the OBD2 legislation and therefore their tool ( likely via back-door engineered PIDs) is creating data collisions and excessive wait-states that could trigger networking fault DTCs in various modules in the car which CAN result in certain immediate functionality loss for THAT ignition/trip cycle. However these usually will reset themselves on subsequent ignition/trip cycles. It’s very possible a Scangauge (barring an agreement with GM) might not be able to clear ALL DTCs from ALL modules used in the VOLT. Even still tools/gauges such as this this typically CANNOT be permanently damaging modules UNLESS their CAN/GMLAN receiver/transmitter (RX/XMTR) hardware is somehow placing excessive voltages on the network bus (it is typically limited to 3.5VDC) and thus damaging other RX/XMTR devices in other modules.

So in the end this is a tool issue NOT a GM or Volt issue.
My advice? Switch to a DashDAQ if you really want to mess around looking at data, but you’ll also have to accept the possibility that it’s use might/will interrupt certain OnStar data collection features others might enjoy. But I’m pretty sure this is something Drew Technologies (the makers of the DashDAQ) are looking at as they have numerous contracts with GM to provide certain pieces of data acquisition equipment used in GM engineering.
So it certainly seems they have an inside line here…

That being said I somewhat disagree with the dealer fixed ops manager that wrote the response in post 14 above regarding potential airbag interference. While the airbag control module (SDM) used in ALL GM cars and trucks is technically wired into the primary high-speed GMLAN network, it operates totally autonomously when it comes to airbag deployment due to a crash. It is specifically designed correctly and properly initiate frontal and side airbag deployment regardless of any network connection or traffic. However the specific exception to this would be for a vehicle roll-over that is designed to release the side curtain airbags when a roll-over event is detected. The roll-over sensor itself is not hard-wired to the SDM and is instead a member of the GMLAN network and thus "communicates" it’s detection of a roll-over event across the high-speed GMLAN bus to the SDM which deploys the curtains. Therefore THIS AND THIS ALONE (without a prior detected crash) would represent the only loss of airbag deployment functionality if a network failure was present at the time.

WopOnTour

Great post WOT. As a software developer (OK, now a developer trapped in a manager's body), I was nodding my head on a lot of this. I do think it is important to point out (as you did) the difference between the older "regular" OBD II tools and the newer CAN stuff. The former, I would assume, are much less likely to cause issues (temporarily or permanent). There are a lot of powerful tools out there of course. I used a few BMW specific packages on my BMWs, and even those get a little scary if you don't know what you are doing!