2012 is Here what would you like to see from your snap on scan tool???

[SnapOnKid]

Well aside from what I mentioned in my other thread...

http://productforum.autorepairdata.com/forum/showthread.php?t=5000

Any thing else that would be help for day to day use???

Integrateing a wireless bore scope to work with the Verus would be an intresting thing. Esspecialy if you could attach the file to a specific car you worked on.

I also feel the ability to Relarn keys would be helpfull. We are not asking for any thing Illegal only to have the same function as a factory tool and some aftermarket tools such as Luanch.

Not asking for security codes to cut keys, just to be able to realern or to add a new key. In most every cases you need an existing working key in order to do this.

This also goes for factory radio's. Gm locks the radio in some of the 2003 and newer models. In order to put a factory radio back in you have to use a factory scan tool in order to reset it. It does not give you an un-lock code. It does alow you to sync it to the Vin of the vehical you install it in. Lets face it alot of people ditch the factory radio and put some thing aftermarket in but when those go out, or if some one wants to turn a lease car back in, or even just to trade in for something newer there only option is the dealer or some one that has dealer ship tools. I have heard the dealers in this area charge $150 to do this and they want you to leave it all day. The process is like 5-10 minutes.


What do the other active Scan tool users have to say ??? What would you like to see be considered???

[Bob's Garage]

Scanners need better coverage.

For scanners:

More coverage. More brands done better. More modules. More PIDS. More functional tests. Key relearns and theft relearns. Not just on the newer cars, but at least back to 1996 cars & trucks. "Backfill".

Snap-on will get more sales by having more capabilty. Once people realize that Snap-on is covering more and more on older stuff and other brands, sales will go up and less of the junk like Launch will take sales away. Right now there are too many holes and on some vehicles, the holes are huge. Subaru, Isuzu, pre 2000 Volvo, etc..

Since the economy has went bad in this country, people are keeping cars longer and the anticipated attrition of the current fleet has not come to pass. The problems are getting worse and harder to diagnose. Like Evap on a 2003 WRX? Or commanding a vent solenoid on a 2003 Vue?

Thanks, Bob

[Wheel]

pre- configured data groups issues

One thing I dislike about a lot of scanners - not just Snap On's - is the pre-configured data groups ( data packets ) they come with. I am not opposed to having this feature for those who want it like this, but I frequently run into situations where pids I want to compare are not presented in the same data group. For example, I may find some pids I want in "engine data 1", but I find some I want to compare are not there. I may find these missing pids in "engine data 2", but the ones I wanted to compare that I found in engine data 1 are not there, therefore I can't compare these at the same time. I would like the additional option of being able to select and build a custom data list from the complete pool of available pids instead of just having one smaller pre-configured group to choose from at a time. I don't know how much control the scan tool makers have over this or if it is controlled by the vehicle manufacturer, but if Snap On could give us this greater flexibility in addition to what exists, I know it would sure help me personally. I hope I didn't make a complete mess of trying to explain this. I would sure like everyone's input on this, whether for or against.

[SnapOnKid]

Thanks BOB!!! I hope more people will chime in. Some of us do not get to see all brands. So it helps to know what is missing and or needed. The more factory style coverage we can get the better. If we don't ask Snap On will never bother with it. I know some of the coverage asked for was being added to the list for future updates.

[SnapOnKid]

One thing I dislike about a lot of scanners - not just Snap On's - is the pre-configured data groups ( data packets ) they come with. I am not opposed to having this feature for those who want it like this, but I frequently run into situations where pids I want to compare are not presented in the same data group. For example, I may find some pids I want in "engine data 1", but I find some I want to compare are not there. I may find these missing pids in "engine data 2", but the ones I wanted to compare that I found in engine data 1 are not there, therefore I can't compare these at the same time. I would like the additional option of being able to select and build a custom data list from the complete pool of available pids instead of just having one smaller pre-configured group to choose from at a time. I don't know how much control the scan tool makers have over this or if it is controlled by the vehicle manufacturer, but if Snap On could give us this greater flexibility in addition to what exists, I know it would sure help me personally. I hope I didn't make a complete mess of trying to explain this. I would sure like everyone's input on this, whether for or against.

Intresting concept Wheel. Could you possibley give an example of a case were you needed this. I am in no way doubting you, but we have to remember the people writing the software are not using the tool in the same way we as repair technicians do. An example would be help full.

I had a lexus last week with an evap issue the data read in different formats in different portions of the data. I have to pull the screen shots and info so I can post it up.

[Crusty]

One thing I dislike about a lot of scanners - not just Snap On's - is the pre-configured data groups ( data packets ) they come with. I am not opposed to having this feature for those who want it like this, but I frequently run into situations where pids I want to compare are not presented in the same data group. For example, I may find some pids I want in "engine data 1", but I find some I want to compare are not there. I may find these missing pids in "engine data 2", but the ones I wanted to compare that I found in engine data 1 are not there, therefore I can't compare these at the same time. I would like the additional option of being able to select and build a custom data list from the complete pool of available pids instead of just having one smaller pre-configured group to choose from at a time. I don't know how much control the scan tool makers have over this or if it is controlled by the vehicle manufacturer, but if Snap On could give us this greater flexibility in addition to what exists, I know it would sure help me personally. I hope I didn't make a complete mess of trying to explain this. I would sure like everyone's input on this, whether for or against.

You have a very good point Wheel.

As BOB says, they need to BACKFILL the HOLES that are significant, no matter what data group, no matter what vehicle, no matter what make.
Something that was wrong, or missing 10 years ago, and is still wrong or missing today, is.....STILL WRONG!!

Sometimes an inconspicuous pid shows a small but vital clue as to what and where the vehicle is failing. Which, seemingly inconspicuous, pid will turn out to be the revealing factor is anybody's guess. That's why EVERY PID needs to be displayed and available

As BOB has pointed out regarding EGR and MAP pids, here's the FIRST SENTENCE from a 1999 Lumina P0401.
"The PCM tests the EGR system during deceleration by momentarily commanding the EGR valve to open while monitoring the Manifold Absolute
Pressure (MAP) sensor signal"
The same thing goes for HONDA's as well. They turn on the EGR and monitor the MAP sensor, so it's not just a GM strategy.
SO seems to think the MAP sensor pid isn't significant enough to include in the GM EGR data group-!! HUH?!?!?!

The pre 2006 GM EVAP data groups are ABYSMAL for the MISSING PIDS-! BMW, MB, Dodge, Nissan, as well as GM consider Engine Coolant Temperature (ECT) and Intake Air Temperature (IAT) and fuel tank level PERCENT (FTL%) in their emissions self tests.
All they need to do is LOOK at the Scan Tool Data List and they will see what pids should be in what groups.
This is from a 2009 (VERY CURRENT VEHICLE) regarding P0446...

"Conditions for Running the DTC
* DTCs P0106, P0107, P0108, P0116, P0117, P0118, P0120, P0121, P0122, P0123, P0220, P0222, P0223, P0442, P0443, P0449, P0451, P0452,
P0453, P0454, P0464, P0496, P0608, P0609, P0641, P0651, P1516, P2101, P2119, P2120, P2122, P2123, P2125, P2127, P2128, P2135, P2138
are not set.
* The ignition voltage is between 11-18 volts.
* The barometric pressure (BARO) is more than 74 kPa.
* The fuel level is between 15-85 percent.
* The engine coolant temperature (ECT) is less than 35°C (95°F).
* The intake air temperature (IAT) is between 4-30°C (39-86°F).
* DTC P0446 runs once per cold start when the above conditions are met.

Conditions for Setting the DTC
* The fuel tank vacuum is greater than 12 inches H2O vacuum for 5 seconds.
OR
* The FTP is less than -2.5 inches H2O or more than +5 inches for 60 seconds after a cold start"

If they were to actually LOOK at P0446 (for example) all the way back to 1996, they would see that GM PREDOMINANTLY uses INCHES-H2O for their scale values in EVAp testing.

OK, so now that they can see WHY I'm so adament about including MISSING PIDS, If they were to do as what i see as your idea.....Allow us to go into their pre-configured data groups, and then ALLOW US to ADD pids from a master list of ALL PIDS, so we could do exactly what you NEED to do, to compare or check pid values pertinant to whatever system you're testing.
If there is an issue with the number of pids in their pre-configured list, then let us remove some while we add others.
This way it doesn't matter if the people putting together the software understand WHY we NEED to see the pids (do they actually USE their pre-concieved lists to fix vehicles??), we can make adjustments for their oversights on the fly or as the situation requires.

There is no way you, me, or any other tech knows what pids are in a Mazda, or a Ford, or a Dodge, or a BMW, or a Toyota, or a Honda datastream.
We RELY on SnapOn to provide us that information. That's why we buy scan tools in the first place.

SnapOn's PRIORITIES should not make it impossible for us to do our jobs PROPERLY, with COMPLETE and ACCURATE data and FUNCTIONALITY.

If we can't view a pid the manufacturer's diagnostic flow tells us to, we can't do our jobs. If we can't COMMAND a function, and then view the result, we can't do our jobs.

This same concept applies to anything, including Key Relearns, or Radios, or any other function we're directed to do by the manufacturers.

New and Improved, Gltz and Glamour such as touch screens and wireless take a back seat to basic data display and functionality. What good is it to have those glitz and glamour features if the bloody thing doesn't function properly????

[ephratah service center]

Ditto Crusty I agree dont give me more gadgets give more info. For what Snap on charges for tools and the updates we should not be missing any info.

[Wheel]

Intresting concept Wheel. Could you possibley give an example of a case were you needed this. I am in no way doubting you, but we have to remember the people writing the software are not using the tool in the same way we as repair technicians do. An example would be help full.

I had a lexus last week with an evap issue the data read in different formats in different portions of the data. I have to pull the screen shots and info so I can post it up.

I can't cite a specific example at this moment, but have run across it many times in the past.

What I was asking for was an option where the data was not pre-grouped at all, rather, one had the option of seeing a list of every possible pid the scanner could pull from the car, or at least from one controller, and then being able to build your own list with any or all of them. I think the DRB3 has a feature much like I am suggesting.

[Wheel]

You have a very good point Wheel.

As BOB says, they need to BACKFILL the HOLES that are significant, no matter what data group, no matter what vehicle, no matter what make.
Something that was wrong, or missing 10 years ago, and is still wrong or missing today, is.....STILL WRONG!!

Exactly.

Sometimes an inconspicuous pid shows a small but vital clue as to what and where the vehicle is failing. Which, seemingly inconspicuous, pid will turn out to be the revealing factor is anybody's guess. That's why EVERY PID needs to be displayed and available

This is one reason I like to initially view as much scan data as I can
and narrow it down later, my reasoning for buying a Verus in preference to one of the other scanners, and why I am so adamant in my defense
of the pre-Atlas way of viewing data pids, because I could see more at once.
There ARE worthless pids out there, but I would like to be the one to cull
them out.

As BOB has pointed out regarding EGR and MAP pids, here's the FIRST SENTENCE from a 1999 Lumina P0401.
"The PCM tests the EGR system during deceleration by momentarily commanding the EGR valve to open while monitoring the Manifold Absolute
Pressure (MAP) sensor signal"
The same thing goes for HONDA's as well. They turn on the EGR and monitor the MAP sensor, so it's not just a GM strategy.
SO seems to think the MAP sensor pid isn't significant enough to include in the GM EGR data group-!! HUH?!?!?!

The pre 2006 GM EVAP data groups are ABYSMAL for the MISSING PIDS-! BMW, MB, Dodge, Nissan, as well as GM consider Engine Coolant Temperature (ECT) and Intake Air Temperature (IAT) and fuel tank level PERCENT (FTL%) in their emissions self tests.
All they need to do is LOOK at the Scan Tool Data List and they will see what pids should be in what groups.
This is from a 2009 (VERY CURRENT VEHICLE) regarding P0446...

"Conditions for Running the DTC
* DTCs P0106, P0107, P0108, P0116, P0117, P0118, P0120, P0121, P0122, P0123, P0220, P0222, P0223, P0442, P0443, P0449, P0451, P0452,
P0453, P0454, P0464, P0496, P0608, P0609, P0641, P0651, P1516, P2101, P2119, P2120, P2122, P2123, P2125, P2127, P2128, P2135, P2138
are not set.
* The ignition voltage is between 11-18 volts.
* The barometric pressure (BARO) is more than 74 kPa.
* The fuel level is between 15-85 percent.
* The engine coolant temperature (ECT) is less than 35°C (95°F).
* The intake air temperature (IAT) is between 4-30°C (39-86°F).
* DTC P0446 runs once per cold start when the above conditions are met.

Conditions for Setting the DTC
* The fuel tank vacuum is greater than 12 inches H2O vacuum for 5 seconds.
OR
* The FTP is less than -2.5 inches H2O or more than +5 inches for 60 seconds after a cold start"

If they were to actually LOOK at P0446 (for example) all the way back to 1996, they would see that GM PREDOMINANTLY uses INCHES-H2O for their scale values in EVAp testing.

OK, so now that they can see WHY I'm so adament about including MISSING PIDS, If they were to do as what i see as your idea.....Allow us to go into their pre-configured data groups, and then ALLOW US to ADD pids from a master list of ALL PIDS, so we could do exactly what you NEED to do, to compare or check pid values pertinant to whatever system you're testing.
If there is an issue with the number of pids in their pre-configured list, then let us remove some while we add others.
This way it doesn't matter if the people putting together the software understand WHY we NEED to see the pids (do they actually USE their pre-concieved lists to fix vehicles??), we can make adjustments for their oversights on the fly or as the situation requires.

There is no way you, me, or any other tech knows what pids are in a Mazda, or a Ford, or a Dodge, or a BMW, or a Toyota, or a Honda datastream.
We RELY on SnapOn to provide us that information. That's why we buy scan tools in the first place.

SnapOn's PRIORITIES should not make it impossible for us to do our jobs PROPERLY, with COMPLETE and ACCURATE data and FUNCTIONALITY.

If we can't view a pid the manufacturer's diagnostic flow tells us to, we can't do our jobs. If we can't COMMAND a function, and then view the result, we can't do our jobs.

This same concept applies to anything, including Key Relearns, or Radios, or any other function we're directed to do by the manufacturers.

New and Improved, Gltz and Glamour such as touch screens and wireless take a back seat to basic data display and functionality. What good is it to have those glitz and glamour features if the bloody thing doesn't function properly????

My suggestion was a choice between their pre-made list, or going through the COMPLETE list of every possible pid and build your own list.
We don't deal with "cookie cutter" problems all the time, and when we don't - the "cookie cutter" lists fall short.

ANYTHING Snap on can do to help the user adapt the tool (scanner, scope, whatever) to his unique need of the moment, instead of him
having to adapt to the tool, or worse yet, having to resort to an alternate tool will help us fix cars faster and help Snap On's bottom line.

[DougMontgomery]

Ford PATS relearn

[SnapOnKid]

Good suggestions!!!

[Crusty]

WHEEL; I agree with you. I look at as much input as I can when first viewing anything on the vehicle in front of me.
No one can know all the pids that a manufacturer puts in their datastream. We RELY on our equipment to tell us that. We rely on the scanners to have complete and accurate datastreams. Once I'm satisfied that a particular sensor or system is not where the problem lays, let me cull out a pid, if and when I choose to.
I look at ALL the datastream pids at first, and I'll record all the pids at first so I can review it ALL later if necessary.
Look at them ALL, Save a movie of them ALL, cull out what initially appears normal (or isn't pertinent to a particular system or code), save another movie of the slimmed down data list, Cull out a couple more pids (to speed up data points), save another movie......
Sometimes I go back to the original recording of ALL the pids and lo-and-behold there WAS something "funky" in a pid that I originally thought wasn't a "culprit"

Far too may times a pid is MISSING COMPLETELY from the datastream, no matter what YY/MM/MM, or data group.

[sbreland73]

Far too may times a pid is MISSING COMPLETELY from the datastream, no matter what YY/MM/MM, or data group.

And MISSING = BROKEN, right?

[Wheel]

WHEEL; I agree with you. I look at as much input as I can when first viewing anything on the vehicle in front of me.
No one can know all the pids that a manufacturer puts in their datastream. We RELY on our equipment to tell us that. We rely on the scanners to have complete and accurate datastreams. Once I'm satisfied that a particular sensor or system is not where the problem lays, let me cull out a pid, if and when I choose to.
I look at ALL the datastream pids at first, and I'll record all the pids at first so I can review it ALL later if necessary.
Look at them ALL, Save a movie of them ALL, cull out what initially appears normal (or isn't pertinent to a particular system or code), save another movie of the slimmed down data list, Cull out a couple more pids (to speed up data points), save another movie......
Sometimes I go back to the original recording of ALL the pids and lo-and-behold there WAS something "funky" in a pid that I originally thought wasn't a "culprit"

Far too may times a pid is MISSING COMPLETELY from the datastream, no matter what YY/MM/MM, or data group.

That sums it up nicely. If you and I had a nickel for every time this happened, our scan tools would be a moot point because we could retire.

[Crusty]

And MISSING = BROKEN, right?

Nope, can't be broken.....it's not there-!!