My intent here to produce an inexpensive tool for tweaking the signals from
the sensors before they are read by the PCM. The sensors are themselves not
mapped, as you know the mapping occurs in a data table residing in the PCM.
I would love to interface with the PCM directly but I do not know anything
about it's communication protocol.
I've considered reading the EPROM's and attempting to get some useful data
in a binary format. On a few projects I've found ASCII text in with the data
that gave me some clues to what the EPROM's data was doing.
With regard to speed, I haven't got a clue how fast I will need to scan the
IO but I do have access to the fasted PLCs made. I can write code in C++
and run a multi-tasking mutli-threaded application in the PLC and interface
through high speed IO designed for Data logging. This PLC can run up to 256
PID loops with out affecting scan time. Scan times for 1000 lines of code
are way under 1ms.
Thanks for the link. That will help me get started.
Patrick O'Day
----- Original Message -----
From: "Shane Moseley" <smoseley@ix.netcom.com>
To: <dakota-truck@buffnet.net>
Sent: Thursday, March 01, 2001 12:00 PM
Subject: Re: DML: Modifing pulses and analog signals to the PCM
> WOT or waiting at a Red wrote:
>
> > I've been reading all the post, current and archive, to try to
understand
> > the PCM in my Dak better. The reason I am interested is I have been
> > considering the possibility of using a small PLC (programmable logic
> > controller) to interface key sensors to the PCM. Coupled with a simple
OI
> > (operator interface) you could take the incoming signals, buffer them
(read
> > change them) and send them on there way to the PCM.
>
> While I do agree with the reasoning behind wanting to do this - I'm not so
sure
> if a PLC can make it easy to get there. I mostly say this because I am
just
> ignorant when it comes to PLCs. Don't they just map a set of inputs to a
> selectable set of outputs? More importantly, what kind of speeds (of
conversion
> - or latency from in-to-output) can it achieve? Is this a 2D mapping
because
> you'll more than likely need at least a 3D-type mapping. If the speed is
> adequate, what about after implementing a 3D (or greater) type of kludge -
will
> the speed still be there?
>
> I personally have been working on a similiar solution - not with a PLC but
a
> full-blown custom-fabbed micro-based approach (see www.diy-efi.org section
on
> efi332). My reasoning is that I want TOTAL control.
>
> Don't let me discourage you in any way as I have even heard of people
having
> success in fuel-injecting motors using not much more than a 555 timer
IC...
> (don't laugh - remember you can do EFI with only 1 input - TPS - called
AlphaN -
> I see it at the dragstrip all the time - winning most of the time!).
>
> For a list of all sensors - check my writeup at the following URL:
>
> http://home.netcom.com/~smoseley/DodgePCM.txt
>
> Latr,
>
> Shane
>
> --
> '96
IndyRam-HisIndy-MPI/TB/Pulleys/AccelCoil/MPComp/HookerSuperComps/CompTAs
> '96 IndyRam-HerIndy-numbered(#142)"Track Truck"
> '74 Triple-Black Dodge Challenger Rallye 360 home-brew EFI R&D vehicle
> '68 Black Corvette Convertible 427 (For Sale)
>
>
This archive was generated by hypermail 2b29 : Fri Jun 20 2003 - 11:59:53 EDT