OneEng
Home | Reviews and Features | Special Reports | Forums |

Results 1 to 15 of 15

Thread: OneEng

  1. #1
    Deanril Guest

    OneEng

    Well I dont know if you know but I have 2 jobs at one establishment.

    #1 is Automotive Technician ,whereas I do mostly Diagnostic work ,smogs ,ALOT of computer diagnostics ,and unfortunately some times Genral repair (brakes waterpumps ect....)

    #2 within same facility I have my Computer shop ,me and boss are partners.


    So which EXACTLY are the systems you design ,I may have worked with them ect.

    We work on most anything with 4 wheels (which is tough ,alot tougher then a dealership that works on all the same vehicles).
    I use my Snap-on scanner quite frequently to communicate with the various onboard computer systems ,they have values and parameters in order to detect problems but 50% do almost nothing in the way of fixing the actual problem.

    The biggest thing I hate is the customer that comes in thinking we are greese monkeys and all we do is hook up the car to this big computer and it tells us what to do ,like we have it in the back and we pray to it or something "please please tell us what to do we are stupid" you know like that ,thats what people think...........

    My main area of expertese is the computer controlled area ,in which ofcoarse there are actuaters and sensors (inputs and outputs) then you have the Proms for each computer ,which can be changed for fixes or making your car go faster ect.


    If I remember correctly they were using 486 computers for awhile (not really comp. just boards with ram and prom and a few other do dads)I believe they are using 586 now with the newer cars ,the Baud rate have certainly increased alot ,as my scan data updates ALOT quicker.

    You also must have knowledge of OBD-II ect...

    Im just curious as to your part in this industry........

    [This message has been edited by Deanril (edited 05-09-2001).]

  2. #2
    Join Date
    Jan 1999
    Location
    MI
    Posts
    4,144
    LOL, I never would have guessed.

    We have done work on the GM Tech2, a little on Chryslers DRB3 tool, and are currently working on an update for a red tool with black handels which I can't name due to NDA. I will be able to tell you more when the product is released.

    We have designed a revolutionary Kernel for embedded applications and a GUI database driven PC applications that can create a hardware independent binary format that can be used to drive any system be it embedded or PC. Our goal is to revolutionize the industry by allowing information to port seamlessly from one generation of tools to the next.

    The hardware is the simple part (that is a relative statement since I have been up to my eyeballs lately in hardware issues). Porting information from every vehicle from 1980 to present from every manufacturer that has a vehicle that can communicate for every module on those vehicles is a nearly unemaginable task. Most old tools used assembly language and hard coded everything. Some few actually re-wrote for C and provided portions of the information within a database but used code generators that were quite ineffecient and required a huge integration effort with the hard coded portions of the code.

    Our system allows information to move from platform to platform without being changed at all. Authoring diagnostics for a PC based tool is identical to authoring diagnostics for a small hand held or even a PDA.

    The vehicles don't really use 386,486, etc chips. Vehicles use embedded micro-controllers. These are CPU's that have built in features for I/O, programmable pins (such as quadrature decode, missing tooth calculation,etc), built in communications functions (GM CLASS II, CAN, etc), built in RAM and ROM. The obveous goal here is to make a system on a chip to reduce costs. While 80% of Americans have a home computer, nearly 100% own a car with most households haveing several cars. Each car houses multiple controllers each having an embedded micro in it.

    For example:
    Ford ( I worked there for 5 years) used an Intel EPIC chip for years that was designed specifically for Ford. This was used from around 1989 and is still in use today in many vehicles. As you can emagine, it isn't very powerful compared to modern processors and isn't very integrated requiring external RAM and ROM and perferial support for vehicle interface circuits.

    Ford's new processors are based off of Motorola's Power PC design. If you look on Motorola's web site and search for MPC555 you can read up on what a modern vehicle CPU looks like. I am a big fan of the PPC in vehicles. It is a great design. Ford refers to the MPC555 internally as the "Black Oak" project.

    Other manufacturers use differing processors ranging from Motorola to Siemens (now Infenion). All modern processors for vehicle communications have similiar features, but Motorola is definately in the lead in this area. Intel was once a force to be reconned with, but decided to drop out of the race to persue their more lucrative PC processors.

    Another one of my favorite chips is the Motorola 68HC332 (32 bit micro). You can get these puppies for $8.50 in volume. For the very megar modules that really don't need a 386 class power processor Motorola offers the HC12 (16 bit micro) which has variants that include CAN controllers.

    I design both hardware and firmware kernels as well as the PC Interface program which I actually fathered years ago. I have since been religated to management and don't frequently do any meaningful work other than answering the questions of people that DO work and go to meetings with customers and internal executives.

    If you have any further questions feel free to e-mail me. I can likely give more complete answers in an e-mail than I can on a public forum

    ------------------
    With greater knowledge comes greater understanding!
    With greater knowledge comes greater understanding!

  3. #3
    Deanril Guest
    Just a couple responses .......

    Ford ........ well Ford up until somewhere around 90-92 (depending on vehicle some 89) you could not get scan data ,just the codes via KOEO or KOER ,pain in the butt ,when you need to test most of the sensors to pinpoint the problem , with the codes ,they were sloppy ,hell my 87 cougar woulnt set a code or turn on a CE light if I wanted it to.

    Alot of the Japanese vehicles same way ,but they have less problems ,and in General they make pretty good onboard computer systems.

    The one thats red with big handles is very good ,I can go back to like 80 GM with it ,we get cartridge updates from time to time ,to bring us up to the latest year,not by our choice but the state makes us ,we usually dont see a new car till 3 -4 after release ,they usually go to the dealer.

    I have used the GM one it was nice years ago when I used it.Dodge computer systems are FUNKY ,they tie alot of junk to their Powertrain control module ,like even the dash ,with the guages ,and ofcoarse the airconditioner (cadilac has the most complicated ac comp controls).

    We dont do much as far as the computers we ,ofcoarse have to diagnose a bad one which is tuough at times ,but then we pull the prom and pop it in a replacement comp.I have replaced more GM computers then any ,most of the time you can smack -em and the car will die .This is ofcoarse after complaints of rough running ect..]


    The best part about the red one is the trouble shooter section ,it helps out alot ,if you can imagine there are alot of different make vehicles ,and sure some things are alike but most arent ,the trouble shooter section is very good ,and its built right into the scanner ,it will help you track down the problem or most likely ,with codes or just symtoms.


    Cool cya......

  4. #4
    Join Date
    Jan 1999
    Location
    MI
    Posts
    4,144
    The TS is indeed cool. You wouldn't believe the work effort that goes into getting all that experience into data.

    You also wouldn't believe what a pain in the *** it is to integrate with 10 year old assembly code!

    I thought Ford had vehicle data as early as 1988. You may be right though. The data was provided on the DCL link in conjunction with Ford's End of Line (EOL) project that started in Wixom on the Contental....1992 I believe. I worked on this project from 1993 to 1997.

    Ford offered a pretty big list of tests they could run that didn't require a data stream. They had computed timing, base timing, fuel pump test, wiggle test, cylendar balance test, koeo, koer, and an output control test availible on most vehicles from the early 80's on.

    Chrysler had the best on board system from 1989 to around 1996. A simple UART based protocol that featured standard item requests, standard fault lists, and standard output controls. Additionally, they offered a high speed (64Kbaud) data read mode that was way ahead of its time.

    GM offered their "Low Baud" protocol in the early 80's (80, 110, 160 baud). It was essentially a blind send from the vehicle vs. the 2 way communications on todays vehicles.

    Later GM went to their ALDL protocol (Assembly Line Data Link). Which speed up to 8192 baud and was a true request responce protocol that could be used for output commands and other vehicle interactions unlike Low Baud. Still at 8192 it isn't exactly a speed demon. It is at least a UART based protocol and doesn't require pin polling in order to decode it!

    You are right about the Cadies. Very complex communication system. While communicating with the powertrain module, you have to send out background messages to all the other modules to "not listen" in order to keep them from going goofey.

    The Tech2 is one of the finest pieces of hardware I have ever worked with. I have worked closely with the HP and GM original lead design engineers (both of them are now middle managers). They are really sharp guys.

    Have you ever worked with the master tech or the Mind Reader or the Monitor 4000?

    ------------------
    With greater knowledge comes greater understanding!
    With greater knowledge comes greater understanding!

  5. #5
    Deanril Guest
    Master Tech yes offered by Mack tools,I didnt like it though ,for one reason they intergrated a Scope Feature into it ,and the scope sucked big time,the resolution on the display screen was horrible and with a scope thats a no go.

    The other two ,I can imagine one of those might be a bargain scan tester the $400 one ,that many tool companies offer ,they give it like 20 different names ,Im sure there fine ,and would make a good "Tech scanner" but most shops provide a scanner they are like $2000 + ,I have lots of tools probably $30K worth ,but dont need to buy a scanner ,when one is provided at all shops.

    Snapon is the best in my oppinion ,especially with the TS ,and I do sit there and appreciate the effort that is put into that part ,its all very well done ,and has saved my butt more times then I care to remember.We work on everything and believe me its no small feat ,its extremely difficult to bounce from one system to the next ,but then again in the eyes of the customer were a bunch of greese monkeys.

    Some guys like to buy the snapon Voltec or something like that ,it has scope function ect ,but again no need ,shop has $50k Smog machine with awesome scope ,just not portable.

    AS for the Tech1/2 we had them in school but usually in the field only GM Dealers use them ,I remember the blue screen ,i think it was blue....

    And in all reality ,scopes are not used as much as one would think being on your side of the fence ,there are plenty of "real world tests" that we the techs make up as we go along.

    Im really not into all the high tech of the industry as I use to be ,I went to school and went for the best position ,that being the high tech Drivability Diagnostic tech (thats where the money is ,not in changing shocks) but in doing so you must know all the basics ,because the comp may set a code ,but it may be non computer related ,you have a internal combustion motor under all those sensors and 60% of the time ,there lies the problem.

    For instance you may get a code for an o2 sensor with a lean trend ,well that dont mean jack didly ,it tells you that the engine is in a lean trend not necassarily the o2 has failed lean ,most of the time its a vacuum leak ,and the computer has reached its limit as far as pulse width and now sets the code.In addition there are TONS of things you learn on experience ,like GM MAF sensors may set a code but you still get an acurate reading (in the scanner) thats because its making it up from what is normal at this TPS reading and this MAP reading ect.Its a profession you have to have a good memory so you dont get bit in the butt twice on the same problem ,and you must be able to think,and interprit alot.

    In actuallity what gets you through is thinking ,then there is SMOG ,which is a whole other ball game ,you have to examine the evidence and come up with a solution ,and its all chemicals ,after all thats the MAIN goal of a computer and thats why they started putting them in cars: 14.7:1 lambada Im sure your aware at 14.7:1 the Cat can most effectively convert all 3 harmful gases CO,HC,Nox ,into perea (carbonated water)
    In cadilacs that on the bottom of the list ,lol but all cars thats #1 priority 14.7:1 .........

    Those early comp controlled carbs did ok ,but as the fed tightened the limits out came more precision (fuel injectors) ,as I was saying I use to really get into all the comp stuff but ,only after 7 years Im a bit burned out on cars period ,thus I opened the comp store ,in hopes of being a 50/50 guy and not work on cars so much.I use to get all the magazines for techs ,and read them ,I think I stopped reading all that stuff is when I bought my first decent comp (a used p75) ,yeah thats when it was.......

    Well anyway ,thats why I know like consumer and limited info on cpu's because Im not an engineer or anything like that ,I just read what I can and try to learn ,but you give me a car question ,and Ill give you an inteligent answer.

    Damn thats my longest post I think.......rambling


  6. #6
    Deanril Guest
    Oh yeah ,heres one for yeah ,this is a good one ,depending on the vehicle type......

    What do you think happens when Sally asks neighbor bob to give her a jump start and wonderful know it all about cars neighbor bob (every neighborhood has a neighbor bob)hooks the cables up backwords ,Im just interested from an engineering standpoint ,what you think would happen.


    Also above you mentioned Quadrature ,GM uses Quad Drivers ,is that what you are refering to? Im not sure if they do anymore ,but those things were knda stupid ,because ,you get the code "Quaddriver 1 failed" something like that ,so you gotta track it down ,because there is 4 things being driven by quad driver 1 ,you can also have 4 things wrong on quad driver 1 and it only lets you fix one at a time ,so you have to fix one problem ,and retest and ect ,I had one with 3 problems on one Quad driver ,no big deal ,but you try and tell the customer all this.........

  7. #7
    Join Date
    Mar 2000
    Location
    Nanaimo,B.C. Canada
    Posts
    2,162
    Originally posted by Deanril:

    What do you think happens when Sally asks neighbor bob to give her a jump start and wonderful know it all about cars neighbor bob (every neighborhood has a neighbor bob)hooks the cables up backwords ,Im just interested from an engineering standpoint ,what you think would happen.


    Yours was probably a rhetorical question ?,but

    From what I remember from Grade 12 Mechanics ,it produces 24Volts instead of 12volts,as it should be.Pretty much frying the electricals?


    Win 7
    Asrock Z68 Extreme3 Gen3
    I5 2500k @4ghz
    8Gb DDR3 2133Mhz
    Crucial M4 128Gb SataIII SSd
    Sapphire Radeon 6870
    Samsung 931bf 19" LCD

  8. #8
    Join Date
    Jan 1999
    Location
    MI
    Posts
    4,144
    I think that if you hook up battery cabels bacwards, you would draw enough current through the cables to melt the insulation off the jumper cables. It could quite possibly result the cables actually catching on fire.

    Quadrature decode is a function that is used with position sensors. Emagine having two input pulses. (The thumbwheel device is a good example). When the TW moves up, pulse A goes first followed by Pulse B. When TW moves down, pulse B goes first followed by pluse A.

    A quadrature decode function creates a counter in a register that you can read to get the relative position of the TW without all that polling of pulses.

    The Quad driver you mentioned sounds like something else. It could be something to do with the 4x4 option on a truck, or alternately it could refer to injector driver chips internal to the ECU. I don't know about GM, but Ford has proprietary ASIC's (Application Specific IC) for injector driver control. At Ford they are called "GASP" chips. I don't remember what thw acronym stands for. Each chip houses 4 drivers. Perhaps GM calls theirs a Quad driver.

    Interesting insight on the tools Deanril. Do you mind if I forward your comments to some exec's at Snapon? I am certian that they get quite a bit of field feedback, but every little bit helps.

    You are absolutely right about your O2 example! Interpreting data is the most important step in diagnosing vehicle problems.

    In my job I constantly have to argue with OEM exec's and some after market execs about what kind of tools techs need. There are 2 distinct opinions on this:
    [list=1][*]A tool that not only reads the information, but that interprets the information in some way (case based reasoning, rule based reasoning, etc) and actually gives the tech what it thinks is wrong with the vehicle.[*]A tool provides the tech with information from the vehicle and from the specifications for the vehicle and allows the tech to determine the cause based on his/her observations.

    Experienced based diagnostics uses input from people like you that actually work on the vehicles. If a certian year,make,model,engine vehicle experiences a problem frequently, it is recorded in the data of the tool and then others can look at this issue first to quickly fix the vehicle.[/list=a]

    I strongly favor the latter. I think designing a program that attempts to diagnose a vehicle is an exersize in futility. There are many inputs necessary to correctly diagnose the problems and only a few of them are availible to the tool.

    I believe that a well trained tech and a good source of vehicle data and vehicle specifications is all you need to fix any vehicle problem.

    Unfortunately, a nice graphical screen on a windows machine showing how a technition could simply hook up a vehicle and have the computer zero in on the exact problem and tell the operator what to fix is an impressive demo. Suits are easily impressed and don't realize that in the field this tool would incorrectly diagnose the vehicle 3 out of 5 times. The tech's would quickly loose faith in the tool and it would end up gathering dust in the corner.

    Another fight I have is that everyone wants to make the "Super Tool" do it all PC lugable device. We are talking about a super VGA screen device with web and RF capabilities that can coordinate the vehicle data with on-line schematics and information.

    Again, while impressive in a demo, the reality is that most techs can fix a vehicle with a simple scanner that collects codes. Sometimes (driveability issues like you are an expert in in particular) you have to read data and interpret issues from that.

    I have nothing against the "Big Box" scanner idea except that it doesn't make a good hand scanner replacement. It takes forever to boot up, the battery dies too quickly, and it costs so much money that virtually no one would buy it.

    My current trend is to offer a cheep hand scanner (relatively cheep ... less than $2500.00) that can use RF to interface with a PC to get schematics, web info, update cartridges, etc.

    If you keep using your red scanner with black handles, you may get to see my handywork in the not too distant future.

    ------------------
    With greater knowledge comes greater understanding!
    With greater knowledge comes greater understanding!

  9. #9
    Join Date
    Jun 1999
    Location
    Minneapolis, MN
    Posts
    2,860
    I think that if you hook up battery cabels bacwards, you would draw enough current through the cables to melt the insulation off the jumper cables. It could quite possibly result the cables actually catching on fire.
    hmmm... 24 volt source though a very low amount of resistance = high current. Couple that with the fact that even car batteries are capable of putting out tremendous amounts of power(even if for just a short time). I think it's safe to say both batteries would output their max power.

    I'm no expert on the design of car batteries OneEng, but wouldn't the batteries fry, or explode, or do something? Having that much current flowing back into them cannot be good.

  10. #10
    Deanril Guest
    In actuality what happens ,most of the time ,is the MAIN fuse blows on the recieving car ,but some times it blows every diode in the car,now picture all those electronics running with blown diodes..ofcoarse this all happens in nano seconds ,as the big spark generally scares the crap out of neighbor bob ,and he quickly disconnects.

    Sometimes it takes out weak control type modules ,like special modules for headlights ect.

    Generally the car may run but its hell to track down ,but a good indication is when you see 2 huge burned chunks taken out of the 2 led battery cable posts ,customers never tell you what really happened ,you have to extract that info from them ,and they always say "im selling the car anyways" we have customers that have been selling thier cars for 5 years ,with no for sale signs!

    Yeah send my Imput ,that is very minor I can give more ,as this is a subject I enjoy.Again Snap-on IMHO makes the best scanner ,we also have another type of scanner I forget the name ,but we hook it between the cars computer and wiring harness ,and we can lab scope every computer circuit in the car ,and it does sweeps and stuff ,has a good gui ,we bought it from Sun/Snap-on ..... its pretty hardcore ....

    I have seen software with I/O cables that can run on a laptop ,let you scan ect ... Ive never used ,probably wouldnt be too bad.....

    They do a great job with the red one ,I cant see much need for improvement ..... I enjoy the button on it ,you dont have to hook it to the vehicle ,it has like a 9volt battery ,and you hit the button and punch in the vin and it tells you where the aldl or diagnostic port is ,before OBD II they liked to hide them ,now they must be under the dash .... Also OBD II is better in that its more uniform across the different makes ,I believe thats why they have it ,but it also seems to diagnose it self MUCH better then older systems ,alot of times and 02 sensor code ends up being an 02 sensor and so on..

    Kewl ,I wouldnt mind seeing the other end of the spectrum ,like some of these guys in Detroit ,I would actually like to make some of those suits come and remove a part from a car ,there are so many stupid design flaws in cars ,they just buture your hands ,and they dont care about the poor guy that has to remove their part when the time comes.

    Yeah when your project is all done ,let me know what it is ,and Ill check it out ,knowing you it should be worth wild



    [This message has been edited by Deanril (edited 05-11-2001).]

  11. #11
    Join Date
    Jan 1999
    Location
    MI
    Posts
    4,144
    OBDII is much more standardized that before OBDII, but there are still differences.

    Generic OBDII only provides 32 common PID's (screen data items). This is practically useless so you still have to use the OEM communication standard.

    The OEM physical layers (the actual hardware circuit needed to talk to the vehicl) are very different.

    Ford uses a differential signal. One line floats high, the other low. A "1" bit is indicated when the signals change position. This is neat because a differential amp can be used and any noise picked up between the vehicle and the tester is eliminated in the difference amp! Differential signals can reach much higher speed with much less occurances of errors due to noise. Ford transmitts their data at 41.6Kb (not too shabby as far as baud rates on vehicles go). Ford also supports a mode called "Rapid Data". In this mode, you can define what data you want the vehicle to give you, and it will start sending it to you as fast as it can (6 byte packet every 3 ms). Since the tester does not have to request items over and over again, the bandwidth is doubled.

    GM and Chrysler both use a single ended design. Their physical layer also uses a different bit level encoding called Variable Pulse Width. Where in a Ford, a high is a 1 and a low is a 0, VPW tries to minimize the transitions. The VPW OBDII transmitts at 10.4K baud. Neither GM or Chrysler support "Rapid Data" like ford, but GM does support "Packetized" data. You can get a 6 byte packet that contains many PID's (6 1 byte values for instance) with a single request.

    Earlier chryslers didn't even use the VPW circuit. They used a simple UART signal between 12V and ground. This protocol required 5 ms between every byte, and 55ms between every message. Every item was request responce in nature. This is BUTT SLOW and often the source of speed complaints on tools. You have to do clever coding like only requesting the data that shows on the screen plus one line below and above for the appearance of fast scrolling. It is a real pain in the ***.

    What is somewhat standard is the actuall meaning of the bytes transmitted (thank God something is standard). So a message like this:

    C0 F1 10 03 CS

    where the bytes are a priority byte, source id of the message, target id (which module you are talking to), and then the mode byte (03) followed by a check sum of the message should work on any OBDII vehicle (this one clears codes if memory serves). The thing is that the standard OBDII modes do not cover all the vehicle capabilities and you have to use the proprietary modes and data to get it to do many things anyway. The SAE (Society of Automotive Engineers) specification for J1850 (OBDII) specifications leaves many modes open for OEM use (the same for pids and faults).

    It isn't nearly as bad as it used to be, but it still is no bed of roses trying to make a tool that communicates with all vehicles.

    It would be nice if it were more like TCPIP and was completely standard ..... but it isn't.

    I'll pass along your comments to Keith Kreft (VP of OEM relations at Snapon .... and a fine guitar player too by the way).

    As for your comments on serviceability of vehicles, I agree. It is often very difficult to service the parts. Here is why.

    When a vehicle is designed, service is not nearly as important as manufacturability. It is all about fast, reilable ability to make a car. If servicability is ever in contention with manufacturability, it loses every time .... guarenteed. I have been in the meetings. Don't let anyone tell you different. If they do, they are just full of it.

    You, my friend, are the least of an OEM's worries. Once the vehicle gets to you, the warrently is likely over. OEM's don't care what it costs to fix after the warrently period is over. I have even seen design issues shipped from the plant since the failures would occur AFTER the warrenty period expired!

    I know this is frustrating for aftermarket repairmen, but you can surely see that it is how it is. Why would Ford care about you? It doens't make them any money (at least not figures you can show in granit).

    ------------------
    With greater knowledge comes greater understanding!
    With greater knowledge comes greater understanding!

  12. #12
    Deanril Guest
    All that is very Familiar ,We techs know that at the Dealer using Dealer scan tools it a different story compared to what we are recieving using Snap-on scan tools.

    And yes MOST design engineers only care about the magic 50K warranty period.

    But still I would at times like to grab a hold of one of these guys ,throw some tools at him and say change it!!

    We also realize they could give a rat *** about the end -tech ,Some manufacturers are concious of this ,toyota is one ,at times you can pop a hood on a couple of these and see most of the common parts are easily changeable ,o2 ,starter ,oil filter ,alternator.

    And most cars as far as failures are predictable ,thats why dealership tech have it easy ,they have great support in addition ,they know what fails and the condition around the failure ,where as I dont enjoy this luxury ,I must test alot ect ,then after I see a couple I can say ,Oh yeah these tend to fail ,and head right for it and forgo all the other testing.

    Dealership techs are good for the most part ,but if you take a GM tech and throw him into a Toyota he will freak out and not know what to do ,We the aftermarket /Independant shop tech are actually better techs ,we work on everything and work hard subsequently because of it,and probably dont make as much.......oh well...



  13. #13
    Join Date
    Jan 1999
    Location
    MI
    Posts
    4,144
    Actually, the engineers have little to say about WHAT design decisions are made. The parameters of the design are a given from upper management. Sort of like a coder being given a flow chart. He/She can code it how they like as long as it follows the spec provided. The architecture isn't up for debate though.

    I agree that aftermarket techs are much more talented than their OEM counterparts. It is a much bigger world when you don't have a single OEM to work on and you can't just call up the OEM engineers when you get stuck.

    On a side note, I was working on that red tool for most of the day today. Ever notice how ABS is it's own decision tree in GM...... Not any more.

    ------------------
    With greater knowledge comes greater understanding!
    With greater knowledge comes greater understanding!

  14. #14
    Deanril Guest
    Dont get to many ABS problems ,but when I do you can count on it being GM.They have a ton of trucks using RWAL (rear wheel anti-lock) ,even if a brake light bulb goes out it trigers the light (indash abs light).Rwal doesnt work half the time anyway ,it really screws up alot ,it was a complete failure ,they use to have these ride hieghth mechanical sensors they were so problamatic....


    I often have wondered the chain of design events and how they come down the pipe..

    I mean ,they must design the body first ,and have specs for engine compartment ,then figure out the engine/tranny specs and go from there.....ofcoarse you have all the body electrical ,and then engine compartment electrical ,then cooling system,then AC is for the most part last on the agenda (from what Ive seen).

    What the funniest stuff Ive seen design wise is mid 80's GM and some fords,they were in a mad panic to lower emissions with Electronically controlled carbs and what not ,the whole engine compartments are a pile of hoses ,it a real mess ,they didint have time to perfect the routing ,stuff every where ,to do a valve cover gasket you literally have to peel all these hose layer off to get down to the damn cover ,just a mess.

    Yeah you have that section where you can choose abs or engine ect... it use to be pin H on the aldl ,you could ground it and get flashing codes out of the Brake light .

    The biggest failures out of all the newer vehicles are O2 sensors ,mainly the downstream O2 sensors (behind the cat).The heater lines tend to blead over onto the signal line ,they have 4 wire O2 pretty sophisticated ,a cold car can now get into close loop rather quickly with these and thats ofcoarse is the goal.

    Alot of techs had problems with downstream O2's because they just didnt think a bit ,I luckily read an article before OBDII became mainstream ,because an O2 fluxuates from typically 100mv to 900 mv rather quickly ect ,and the ones behind the cat tend to sit at 800mv on a fully warm vehicle ,indicating a rich condition.

    But thats what they are suppose to do ,because an O2 reads O2 and if your cat is functioning properly and burning off all the HC then in that process it uses up all the oxygen ,thus behind the cat 800mv low oygen content .


    The only thing I can think of that is needed more in the current scanner is more functional test ,most have some ,like Chrysler has a good many ,but typically gm lacks a bit ,some kindof funtional test for ignition modules and cam/crank sensors ,I realize this would be hard ,but its a real pain when you get a car with no spark ,what could it be module ,crank sensor,computer...special doodad that they put in that year only ect...

    If they were able to send current down to the sensor ,like an ohms/resistance value function ,so you wouldnt have to get all crazy and start backprobing all this crap.Yeah that would be good ,for the most part the computer would have to be ready to do this ,and I realize todays car computers do ,do this sort of thing to an extent ,but not exactly how I mentioned it.

    It could be in the function tests section ,like they have all the relays ect ,but like get a resistance value for pin a/b on the crank sensor ect ,and ofcoarse have fast track normal values so you could know whats good or bad ,quickly so you dont have to go to mitchel and open that up and print out a completely useless diagnostic flow chart only to get your answer at the very end..........

    In the last ,I would say 4 years the sophistication has really boomed ,I see some ford that have like 3-400 trouble codes ,thats alot compared to 60 or so they had for years ,then I read the parameters inwhich has to be met before the trouble code is set ,and I see alot of sophistication ,again this does help ,the 96 on back would set codes that didnt help out alot and were misleading at times ,but they have improved quite drastically as of late ,I would say some where in the 90% acuracy rating as far as the code is correct ,to what part failed.Cheers to technology.......

  15. #15
    Join Date
    Jan 1999
    Location
    MI
    Posts
    4,144
    Yea, the o2 sensors are natorious for failing, but then you spend a few years in an exhaust pipe ... bet you fail too

    You have it right about the sofistication. It is pretty bad and getting much worse. 7 years ago a typical vehicle had 1 module, today it goes upwards of 30 or more on some vehicles.

    As for functional tests, there will be more in the future. I can't really say more than that.

    It is interesting to hear that the codes are becomming more accurate. I would guess that without a trouble shooter of some kind, most techs would still have a problem with many of the codes since some of the desctiptions are quite vague, and it isn't like you can look at the vehicle strategy to see exactly what condition the computer found to set the code.

    ------------------
    With greater knowledge comes greater understanding!
    With greater knowledge comes greater understanding!

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •