Custom diesel PCM? QBasic? Microcontrollers? Insane Idea?
Thread Starter
|
Lead Driver
Joined: Jan 2006
Posts: 6,267
Likes: 5
I think that using these less advanced chips is a "downgrade" in terms of raw processing power, but the learning curve and ease of use would make it worth while.
Thread Starter
|
Lead Driver
Joined: Jan 2006
Posts: 6,267
Likes: 5
Indeed. When I looked at doing this back in the dark ages, I was instructed that less than 10% of the code in the PCM was actually used to fire the injectors and run the engine; the rest of it was troubleshooting, error correcting, signal conditioning, and other such "mundane" stuff not related to generation of horsepower.
Yes, I'm sure there will be lots of mundane programming to make it work, but it should be a lot easier to understand!
Writing simple code to control fueling IS relatively straightforward, and rather simple in terms of what you're actually doing.
The complexity comes from handling error conditions. What happens when you miss a CMP signal only ONCE? The program craps out (and your engine dies), without error-handling.
The injector controller will count between signals and identify missing signal, bad injector etc...
What happens when your alternator dies, (and you don't know it), and 30 minutes after failure, all your voltage needs go haywire because you don't have a steady 12-volt reference signal? The list of possible failure modes (and thus the code required to deal with them) is nearly endless.
The PCM and equipment has will have a power supply, it will run fine until theres no power, then just shut off.
Writing code for a simple speed-density fuel injection controller is what the Mega-Squirt is all about; but when you try to work on an engine with more than four sensor inputs (in this case, TPS, MAP, temp, and trigger), the complexity goes haywire.
Theres lots of sensors, but lots are backups or doubles. Using these cool new chips, reading sensors should be a very simple process. And with QBASIC coding, using their values to make decisions will be fairly easy.
The reason why there aren't several hundred PCM alternatives out on the market is because truly mission-critical fuel injection programming is NOT easy. You're talking several THOUSAND lines of code.
(Factory engineers aren't stupid; they just have to answer the questions given with answers that almost by necessity don't match YOUR answers.)
-blaine
Yes, I'm sure there will be lots of mundane programming to make it work, but it should be a lot easier to understand!
Writing simple code to control fueling IS relatively straightforward, and rather simple in terms of what you're actually doing.
The complexity comes from handling error conditions. What happens when you miss a CMP signal only ONCE? The program craps out (and your engine dies), without error-handling.
The injector controller will count between signals and identify missing signal, bad injector etc...
What happens when your alternator dies, (and you don't know it), and 30 minutes after failure, all your voltage needs go haywire because you don't have a steady 12-volt reference signal? The list of possible failure modes (and thus the code required to deal with them) is nearly endless.
The PCM and equipment has will have a power supply, it will run fine until theres no power, then just shut off.
Writing code for a simple speed-density fuel injection controller is what the Mega-Squirt is all about; but when you try to work on an engine with more than four sensor inputs (in this case, TPS, MAP, temp, and trigger), the complexity goes haywire.
Theres lots of sensors, but lots are backups or doubles. Using these cool new chips, reading sensors should be a very simple process. And with QBASIC coding, using their values to make decisions will be fairly easy.
The reason why there aren't several hundred PCM alternatives out on the market is because truly mission-critical fuel injection programming is NOT easy. You're talking several THOUSAND lines of code.
(Factory engineers aren't stupid; they just have to answer the questions given with answers that almost by necessity don't match YOUR answers.)
-blaine
I bet the truck could be running with 5 kb of code.
After that, provisions could be made to log data, create error handling, etc.
Thread Starter
|
Lead Driver
Joined: Jan 2006
Posts: 6,267
Likes: 5
CAN232 - The Original CAN to RS232 converter
Serial port to CAN adapter.
I wonder just what these commands will look like over the CAN network while the truck is running .
I suppose if the CAN commands could be learned, there would be no need to make a IDM module.
Anyone have any clue where to start leaning about that? Searches going nowhere.
Serial port to CAN adapter.
I wonder just what these commands will look like over the CAN network while the truck is running .
I suppose if the CAN commands could be learned, there would be no need to make a IDM module.
Anyone have any clue where to start leaning about that? Searches going nowhere.
Thread Starter
|
Lead Driver
Joined: Jan 2006
Posts: 6,267
Likes: 5
A friend just had a great idea.....
Parallax Memory Stick Datalogger - RobotShop
Just monitor key values on the homemade PCM, like EGT and EOT/ECT and boost, and log the rest to USB stick !
Monitor all the sensors, and every second, write them all to the file with a time / date stamp. If you have any issues, just toss the USB stick in your pc and take a look.
This would be truly the best, because it keeps the truck simple, but allows you to look at detailed data if you need to.
Parallax Memory Stick Datalogger - RobotShop
Just monitor key values on the homemade PCM, like EGT and EOT/ECT and boost, and log the rest to USB stick !
Monitor all the sensors, and every second, write them all to the file with a time / date stamp. If you have any issues, just toss the USB stick in your pc and take a look.
This would be truly the best, because it keeps the truck simple, but allows you to look at detailed data if you need to.
Thread Starter
|
Lead Driver
Joined: Jan 2006
Posts: 6,267
Likes: 5
LOL , I like that !
I meant asides from the IDM.
The IDM will read the timing sensors and count cycles to time till injection event. It will also send info to the pcm about gaps between injections to calculate a bad injector so such problem.
All the PCM will need to do is tell the IDM how much advance, and how much fuel.
Thats the good thing about QBASIC; it doesn't take a lot of code to get a lot done.
I meant asides from the IDM.
The IDM will read the timing sensors and count cycles to time till injection event. It will also send info to the pcm about gaps between injections to calculate a bad injector so such problem.
All the PCM will need to do is tell the IDM how much advance, and how much fuel.
Thats the good thing about QBASIC; it doesn't take a lot of code to get a lot done.
Cargo Master
Joined: Jun 2008
Posts: 2,752
Likes: 5
From: Stillwater, OK
I wonder just what these commands will look like over the CAN network while the truck is running .
millions of lines of seemingly random (and sometimes non-printing) characters if viewed in Hyperterminal.
You will also not see any of the processing done by the CAN modules themselves... only the messages sent out on the CAN-Bus. For instance, the throttle position request doesn't have to be sent constantly... only when there is a change. Once the modules that use the throttle position request receive the message, they can run their process with that data until a new request comes along...
after the throttle position request is received by the actuators, the throttle position is actually set, and the "actual throttle position" is sent to the Bus (the request and the settling position won't necessarily match, but they will stay within an acceptable range of difference). Some modules that use throttle position will ignore the actual position and only pay attention to the request (or vice-versa), some will use both.
As far as deciphering the CAN-Bus messages, unless you can find access to the SAE standards that this particular application uses, you'll have to shell out the several thousand dollars required to get your own copy of the standards... which are just a few thousand pages of text explaining that particular protocol and the heirarchy of the messages available to be sent...
Lead Driver
Joined: Nov 2007
Posts: 5,139
Likes: 209
I think you'd have your hands so full you'd throw your computer out the window. I admire your intentions, but think you'd waste a lot of time just getting the motor to start.
FTE Stories
Ford Trucks for Ford Truck Enthusiasts
10 Things Every Truck Owner NEEDS (2026 Edition)
Michael S. Palmer
Rezvani's Latest Post-Apocalyptic Monster Is a Ford F-150 Raptor Underneath
Verdad Gallardo
Top 10 Most Expensive Ford Trucks Ever Sold on Bring a Trailer
Joe Kucinski
2027 Ford Super Duty Buyer's Guide (Every Model, Engine, & Package)
Brett Foote
Top 10 Ford Truck Tragedies
Joe Kucinski
AEV FXL Super Duty - the Super Duty Raptor Ford Doesn't Make
Brett Foote
Lobo Vs Lobo: Proof the F-150 Lobo Should Be Even Lower!
Michael S. Palmer
Ford's 2001 Explorer Sportsman Concept Looks For a New Home
Verdad Gallardo
10 Best Ford Truck Engines We Miss the Most!
Joe Kucinski
Thread Starter
|
Lead Driver
Joined: Jan 2006
Posts: 6,267
Likes: 5
millions of lines of seemingly random (and sometimes non-printing) characters if viewed in Hyperterminal.
You will also not see any of the processing done by the CAN modules themselves... only the messages sent out on the CAN-Bus. For instance, the throttle position request doesn't have to be sent constantly... only when there is a change. Once the modules that use the throttle position request receive the message, they can run their process with that data until a new request comes along...
after the throttle position request is received by the actuators, the throttle position is actually set, and the "actual throttle position" is sent to the Bus (the request and the settling position won't necessarily match, but they will stay within an acceptable range of difference). Some modules that use throttle position will ignore the actual position and only pay attention to the request (or vice-versa), some will use both.
As far as deciphering the CAN-Bus messages, unless you can find access to the SAE standards that this particular application uses, you'll have to shell out the several thousand dollars required to get your own copy of the standards... which are just a few thousand pages of text explaining that particular protocol and the heirarchy of the messages available to be sent...
You will also not see any of the processing done by the CAN modules themselves... only the messages sent out on the CAN-Bus. For instance, the throttle position request doesn't have to be sent constantly... only when there is a change. Once the modules that use the throttle position request receive the message, they can run their process with that data until a new request comes along...
after the throttle position request is received by the actuators, the throttle position is actually set, and the "actual throttle position" is sent to the Bus (the request and the settling position won't necessarily match, but they will stay within an acceptable range of difference). Some modules that use throttle position will ignore the actual position and only pay attention to the request (or vice-versa), some will use both.
As far as deciphering the CAN-Bus messages, unless you can find access to the SAE standards that this particular application uses, you'll have to shell out the several thousand dollars required to get your own copy of the standards... which are just a few thousand pages of text explaining that particular protocol and the heirarchy of the messages available to be sent...
I thought the CAN bus was used for IDM, PCM, TCM and ABS , the throttle and sensors look fairly simple.
Cargo Master
Joined: Jun 2008
Posts: 2,752
Likes: 5
From: Stillwater, OK
the CAN-Bus is what connects all of the electronic components together. The sensors send a signal to their respective CAN controller... one of which contains an A/D converter to turn that signal into a Byte (or bytes). The CAN controllers put the formatted messages on the CAN-Bus while listening for others... Even the Radio head unit is connected to the CAN-Bus.
Thread Starter
|
Lead Driver
Joined: Jan 2006
Posts: 6,267
Likes: 5
OK but all the engine sensors are all read by the PCM, and I can't find anything about the CAN bus, unless the can controllers for them are integral to the PCM.
I thoought CAN bus was for engine-tranny-cluster communication only
I thoought CAN bus was for engine-tranny-cluster communication only
Lead Driver
Joined: Sep 2007
Posts: 8,180
Likes: 669
From: Scio, OR
With the 6.0L, the CAN bus connected the ECM (Engine Control Module) and TCM (Transmission Control Module), which were two separate computers and related components, housed together and called the PCM (Powertrain Control Module). It connected those to the FICM, and to the ODB-II connector. That's all that CAN was used for. There were 3 other data busses used for the 6.0L.
This apparently all changed in 2008 with the 6.4L.
This apparently all changed in 2008 with the 6.4L.
Thread Starter
|
Lead Driver
Joined: Jan 2006
Posts: 6,267
Likes: 5
With the 6.0L, the CAN bus connected the ECM (Engine Control Module) and TCM (Transmission Control Module), which were two separate computers and related components, housed together and called the PCM (Powertrain Control Module). It connected those to the FICM, and to the ODB-II connector. That's all that CAN was used for. There were 3 other data busses used for the 6.0L.