DEAD VOLT II

[ClarksonCote]

You mention that you can't seem to clear the codes yourself. I would suggest that, on a vehicle like this, those codes are usually there with very good reason. There is the occasional check engine light due to a bad charging voltage level (though software updates seem to have dimished that frequency), but otherwise, these codes usually mean you should have the dealer at least take a look.

Now, I can certainly empathize with your frustration. There have been a few of us that had some problems early on. It seems that problems can be inter-related at times. I suspect you'll have all the kinks worked out soon, though. Please try to be patient, and keep us updated.

If it makes you feel better, I was a real early adopter (December 2010), and as a result of some dealer negligence, had numerous problems during my first few months. During that time GM was extremely responsive, and now I'm happy to report that I am completely trouble free... and the Volt keeps putting a big smile on my face with its smooth electric drive.

[F16BMATHIS]

It may actually be the ODBII after all. My rental, a Chevy Cruse, just died. You may have guessed, that I had my Scanguage II ODBII reader connected to it. Seems to have the same issues as the Volt has. Stabilatrack, power steering, engine light... Turned the car off to reset codes, and car wont turn on again. Waited 10 minutes, then it did start, but still have a check engine light.

Could Chevy really have built $40,000+ cars that are disabled by a $100.00 ODBII reader?

[F16BMATHIS]

Here's a posting I found for another Chevy...

Chevy does NOT recommend "ScanGauge II" for Sonic

--------------------------------------------------------------------------------

Well, I just learned that my Chevy dealer thinks it's unwise to hook up my ScanGauge II to my Sonic and he has a valid reason

ScanGauge - Trip Computer + Digitial Gauges + ScanTools

For the past two months, I've been getting the monthly OnStar diagnostic reports and everything has been highlighted with yellow triangle alerts saying it couldn't process the diagnostics because a third-party device was using the OBD II port.

I use ScanGauge II because I like to see what the coolant temperature and the voltmeter is on my Sonic. It's a shame everything has "idiot lights" with the only gauge being for fuel.

Here's what the Operations Manager opinion was and I believe he may have a point:

"Tom,
Regarding the use of an aftermarket device that connects to the ALDL for monitoring performance is a little bit scary.
When this is into the connector it “over rides” the communication of the vehicle with control devices.
That being said the possibility exists that air bags will not deploy in a crash because the system thinks you are in diagnostic mode.
I recommend against its use.
GM does not make an accessory gauge package to my knowledge, and I understand your desire to monitor.
If there were an aftermarket pack that you find perhaps I could look at how it connects to the vehicle.
That is the only way I could tell you there would be no problem upon install. It might interfere with fail safes built into the ECM.
For example the oil pressure is monitored and the engine can go into a passive mode if it detects loss of pressure.
If another device is in the system I don’t know how it would work or if it would trigger a fault code.
With the capabilities of your car, the on board computers should alert you to an issue before it becomes a problem
It can detect a misfire without you or I ever feeling it and turn on the check engine light. It does more than just allow capture data to be stored."

Butch Smith
Fixed Operations Manager
Roy Robinson Inc

[Henry_FL]

Stop putting devices on your diagnostic port and problem solved. The manufacture these ODBII device have not done any verification or qualifications they won't have side effects to the internal systems operations.

Hopefully you have learned your lesson, and if not, you will when you start getting charged for service when its your fault, not the car manufactures

[F16BMATHIS]

Stop putting devices on your diagnostic port and problem solved. The manufacture these ODBII device have not done any verification or qualifications they won't have side effects to the internal systems operations.

Hopefully you have learned your lesson, and if not, you will when you start getting charged for service when its your fault, not the car manufactures

It's my lesson that GM has manufactured a new breed of vehicles that the Scangauge II will kill! Maybe this is a lesson for GM? Anyways, Since its not actually the wireless ODBII I had installed I guess I can use that one.

The big thing is that we need to get the word out that the Scangauge II will cause several codes and possibly kill the vehicle, and not just the Volt, but also the Cruse and the Sonic. Who knows what other GM products are out there with inferior ODBII ports? I really hope it doesn't act up whenever I have to get emmissions done. All they do is connect there ODBII reader up to the car and read the data. Would suck to go get your emmissions done and have the car killed! Scangauge II is very popular on the Prius and as people upgrade to a Volt, they may be in for a surprise. I've used it on every vehicle I own plus helped others out with thier cars. Its only causing problems with the new GM's.

I also still have the original problem where the EVSE was out in the rain and the next day it wouldn't charge the car and caused the codes I tried to reset.

[Fulgerite]

It may actually be the ODBII after all. My rental, a Chevy Cruse, just died. You may have guessed, that I had my Scanguage II ODBII reader connected to it. Seems to have the same issues as the Volt has. Stabilatrack, power steering, engine light... Turned the car off to reset codes, and car wont turn on again. Waited 10 minutes, then it did start, but still have a check engine light.

Could Chevy really have built $40,000+ cars that are disabled by a $100.00 ODBII reader?

Yup. That same ODB reader might also kill a BMW, Mercedes, Ford or any other car if it is a defective reader.

In other words... it may not be all Scangauge II's... Maybe it's just tour defective one?

Or it may indeed block inter-module communication and cause problems. Using the device to clear error codes might also cause a problem if the Scangauge if flipping the wrong bits. GM never promised the car was compatible with Scangauge II's. GM has no obligation to MAKE the car work with Scangauge II's. either.

It's also possible you had a legitimate problem with the EVSE... But adding 3rd party ODB devices into the equation is definitely going to make a diagnosis exponentially more difficult. I still think the best way forward is to get the car into your dealer and let the certified GM tech use the GM certified equipment to fix the car. Then drive it for a month without plugging in ANY 3rd party ODB devices and see if the car operates normally. Then if you have another EVSE issue you will know for a fact that the ODB was not the cause.

[F16BMATHIS]

I have been driving without the Scangauge II installed. It was only when the first two codes appeared that I attempted to reset them.

It is in fact an EVSE problem that was compounded by the Scangauge II

[rmay635703]

Yup. That same ODB reader might also kill a BMW, Mercedes, Ford or any other car if it is a defective reader.

In other words... it may not be all Scangauge II's... Maybe it's just tour defective one?

Or it may indeed block inter-module communication and cause problems. Using the device to clear error codes might also cause a problem if the Scangauge if flipping the wrong bits. GM never promised the car was compatible with Scangauge II's. GM has no obligation to MAKE the car work with Scangauge II's. either.

If this is true this is a real bummer, I don't think I would be willing to drive a car that was not scanguage ready, it is simply impossible to get the best fuel economy without one of these guages.

That is how I took my cobalt from 37mpg to 50+mpg.

[DonC]

It is in fact an EVSE problem that was compounded by the Scangauge II

This what I suggested a page or two ago. What I asked then was whether your car had the software upgrades done. You haven't answered this question.

The reason I ask is that there was a problem with third party EVSE units under rainy conditions, and you mentioned that both times you had the charging problem it was raining. You might want to check this out. I think WOT mentioned there was a bulletin to help dealers trouble shoot the issue.

[WopOnTour]

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