Jump to content

Recommended Posts

Posted

Hey guys. New owner here. First time buying from GM/CHEVY. 2020 GMC 6.6 gasser. Been driving tundra whole life. Wanted a change, still have the tundra. Any idea of how reliable this truck can be or how many miles it can go? Also I heard the transmission is a reliable one for the 2020 model. Thank you. Sorry, I’m not too educated on GM products. Thank you 

Posted

Welcome - My last truck 2015 , had 95,000 when traded in . Just standerd maintance . My 2012 - 130,000 - Standerd  maintance . As long as you take care of it , it will last. 

Posted

I have a 2012 Silverado, 1500. 5.3 liter.. right now 165,000 miles. No issues, standard maintenance. 

Posted

6.6 is the 6.0's replacement and being a similar iron block/aluminum head construction, it should be a tank just like the 6.0 was.

 

6L90 is also a tank, and is GM's lowest warranty repaired transmission they have (aka, low issues rate).  

Posted

Thank you guys for your knowledge and time. Been great driving it so far. Took about two days to get used to the size but it’s been great and smooth. Love the powertrain 

Posted

I’m driving a 2002 with the previous 6.0 engine, and it has 242,000 miles.  It has been towed one time when a fuel pump went out at 195,000 miles.  I’ve had a couple of oil leak repaired, and a radiator.  I got 225,000 miles out of the original brake pads.

im looking at the 6.6 gasser as it’s replacement, but it still runs great, and I’m having a hard time letting go of the money to get a new one. 

Posted (edited)

I am looking at buying a 6.6 gas and plan on keeping the truck long for a long time.  My concern is the GDI intake valve carbon issue and how well GM has mitigated it with their built in oil/air separator in the CCV system.  Will the intake valves need periodic cleaning such as walnut blast or CRC chemical cleaning?  Does it need a catch can?  Has anyone pulled a CCV hose and seen oil passing through or has anyone borescope'd the intake after a good amount of miles?  I know the earlier German GDI engines have had the worst issues, and that other manufacturers are using a dual injection (port and direct) system.  I just wish GM would do the dual injection so I wouldn't have to worry about it.

Edited by -David-
Posted

GM has had the same basic system used on the 6.6L on the DI 5.3L and 6.2L for many years now, and I have not heard of any major issues with it.  In addition, I know GM did a lot of work managing crankcase vapor specifically on the L8T.  I don't anticipate any problems.  I could also comment that it seems to me that GM V-8's are 'tighter' than some of the competition's engines and use less oil......  

  • 3 weeks later...
Posted

We just traded our 2015 1500 LT (80k miles) on a 2020 2500HD. Pleased with the upgrade and overall feel of the truck, one of the best parts is not having the fancy engine management system from the 5.3 - cylinder cutout and descent braking. 

 

 

  • 2 weeks later...
Posted
On 7/17/2020 at 5:27 AM, R3mac said:

We just traded our 2015 1500 LT (80k miles) on a 2020 2500HD. Pleased with the upgrade and overall feel of the truck, one of the best parts is not having the fancy engine management system from the 5.3 - cylinder cutout and descent braking. 

 

 

yes i had a 19 RST and hated the auto start stop....

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Latest Articles

  • Posts

    • Did have to make 1 modification because of the WeatherTech rear mud flaps and that was needing 3 longer screws than what came with the install package. 😄
    • Picked up the liners yesterday. Installed passenger side WITHOUT any modifications. All mounting holes lined up perfectly. Rain is interfering today with drivers side. Very Happy! Will add pics when finished
    • As a matter of amusement I’ll leave this conversation with this. Do you beat the government average fuel estimate? Statistics are a guide to me. Not a rule. Someone once said I have to have the last word. If true and possible may be. I’ll blame that on working in a family business.
    • That is a fair point, and I agree that trying to log “everything in the truck” would be the wrong direction.   There are a lot of modules and a lot of traffic. If the product became a full-truck datalogger, the amount of data would get huge very quickly, and most owners would never use it.   I think the first useful version would need to be narrow: - powertrain-side event evidence - selected high-value parameters - communication / voltage / reset events - pre/post event window - short report first, raw log only as backup   One distinction I should make is between active OBD/PID polling and passive bus capture. If you are polling PIDs through OBD, then yes: the more parameters you request, the lower the effective sample rate becomes, and you are adding diagnostic traffic to a vehicle that is already busy running itself. With passive CAN capture, the recorder is not asking all the modules for data. It is listening to traffic that is already on the bus. So it does not consume vehicle bus bandwidth in the same way that a scan tool polling hundreds of PIDs would. But your point still applies in a different way.   Even if passive capture does not add bus traffic, the recorder still has limits: - processing rate - storage rate - timestamp accuracy - decoder workload - event filtering - report size - user attention span   So the answer cannot be “log everything and let the user figure it out.” The product would need to store enough raw evidence to be useful, but only decode, graph, and present the important parts around the event.   A practical report should probably show: - what triggered the capture - how much pre/post data was preserved - which selected parameters changed - how those values compared to baseline - whether the same pattern happened before - whether any voltage, reset, bus-off, lost-message, or communication fault occurred - selected graphs around the event - raw data only as supporting evidence   So I agree with you. More data is not automatically better. The real product is the reduction from raw data into a useful event report.
    • That makes sense, and I agree with most of that.   I think the product would need both: 1. a default powertrain template, so it is useful out of the box; 2. user-selected priority parameters, so the owner or shop can choose what they want to see first.   Different users are going to care about different things. One owner may care about oil pressure and voltage. Another may care about misfire trend, AFM/DFM behavior, or U-codes. A shop may want communication events and repeatability first. Your baseline point is probably the most important one. Raw data is not very useful unless the report can show what normal looked like for that vehicle under similar conditions.   The way I would think about it is: - start with a basic known-good baseline - learn normal behavior for that specific vehicle over time - allow the event to be overlaid against baseline - show whether the event was a one-time spike or a repeatable pattern - provide a simple severity level, but with clear limits on what that severity means   For example, early severity could be something like: - Info: event captured, no obvious abnormal pattern - Watch: value moved outside baseline, but not repeated - Warning: repeatable abnormal pattern under similar conditions - Critical: communication loss, voltage drop, bus-off, reset, or severe repeated event   I would not want the first version to say “replace this part.” That would be overclaiming unless there is repair-confirmed data behind it. It would be more honest to say “this pattern deserves inspection.”   On the OBD port question, I think OBD absolutely has a role. OBD is probably the right place for: - DTCs - freeze frame - VIN - calibration information - normal scan-tool parameters - Mode 6 / enhanced diagnostic data if available The reason I am still looking at an ECM-side recorder is that the failure may happen before anyone connects a scan tool. If the owner plugs in a scanner after the event, the pre-event evidence may already be gone unless the ECU happened to save it. So I do not see this as “OBD versus ECM-side.” I see it more like: - ECM-side recorder: always armed, rolling buffer, event evidence - OBD/DLC companion: DTCs, freeze frame, VIN, calibration, normal scan data - phone/cloud: status, notes, upload, report generation, notifications   I agree that phone connection and push notifications would be useful. I just would not want the phone or cloud connection to be required for capture. The recorder should save the event locally even if the phone is not connected. The phone should help with event marking, download, notes, upload, alerts, and report viewing.   For a default GM V8 event report, would this list make sense? - RPM - calculated load / MAP - throttle position - vehicle speed - gear / torque converter state if available - coolant temperature - oil pressure - oil temperature if available - battery voltage - commanded AFM/DFM state if available - actual AFM/DFM state if available - misfire counters / roughness by cylinder if available - fuel trims - relevant U-codes / communication events - bus-off / lost periodic message / module reset / voltage drop events Which of those would you remove, and what would you add?
  • GM-Trucks.com Clubs

  • Popular Contributors

×
×
  • Create New...