[tunerpro] Re: Progammatic interfaces?
- From: "M Mansur" <mmansur@xxxxxxxxxxx>
- To: <tunerpro@xxxxxxxxxxxxx>
- Date: Tue, 13 Nov 2012 10:18:11 -0800
Hi Jason,
Yes, thanks for the scripting suggestion. I appreciate you taking the time to
lay it out. Obviously this wouldnât be quick and easy to implement, but there
are interesting implications and advantages to scripting. When Iâm ready to sit
down and work exclusively on the auto-tuning functionality, Iâll consider the
information youâve provided.
-Mark
From: Jason H
Sent: Tuesday, November 13, 2012 8:02 AM
To: tunerpro@xxxxxxxxxxxxx
Subject: [tunerpro] Re: Progammatic interfaces?
It is for a GM 16197427 ECU (PCM - 1994/5 C/K truck) crammed onto a IH 345.
Now Mark, any response to the programmatic interface proposal?
--------------------------------------------------------------------------------
From: M Mansur <mmansur@xxxxxxxxxxx>
To: tunerpro@xxxxxxxxxxxxx
Sent: Tuesday, November 13, 2012 10:55 AM
Subject: [tunerpro] Re: Progammatic interfaces?
Thanks for the suggestion, Ryan.
-Mark
From: Ryan Eaton
Sent: Tuesday, November 13, 2012 6:43 AM
To: tunerpro@xxxxxxxxxxxxx
Subject: [tunerpro] Re: Progammatic interfaces?
I got the attachment as well. What type of engine is that spreadsheet for?
Also, I would like to see a manually entered delay or delay algorithm for some
of the sensors readings built into TPRT. I know my WB O2 is terrible at
matching to the RPM and timing, especially at throttle changes. That's fine
when I do a single pull, because i can just shift the entire readout a few
cells. Although when I try to create a cruise log (to see that I'm in pretty
good shape for regular trims) the sudden throttle changes throw off the WB
readings for certain RPM and can disturb the averages pretty significantly for
particular cells.
-Ryan
On Tue, Nov 13, 2012 at 3:58 AM, Carl-Otto Rustad <carl-otto@xxxxxxx> wrote:
Thank You Jason!
I got the first one with the attached file.
It went through and made it all the way
to Norway, at the speed of light I guess.
I'm looking at it now, looks nice and must
have taken some time to come up with.
Carl.
------ Original Message ------
Received: Tue, 13 Nov 2012 02:19:47 AM CET
From: Jason H <scorp1us@xxxxxxxxx>
To: "tunerpro@xxxxxxxxxxxxx" <tunerpro@xxxxxxxxxxxxx>
Subject: [tunerpro] Re: Progammatic interfaces?
If not here it is http://www.filedropper.com/scorp1us-blm-worksheet-spark
Sorry for the emails - it looks like it didn't go out and I had to go to the
other computer to get it again.
Once again, USE AT YOUR OWN RISK
It may cause impotence, inconitnence and conflatulation.
Bearing may lose their bearing. Rods may become springs and pistons might not
pis.
------------------------------------------------------------------------------
From: Jason H <scorp1us@xxxxxxxxx>
To: "tunerpro@xxxxxxxxxxxxx" <tunerpro@xxxxxxxxxxxxx>
Sent: Monday, November 12, 2012 8:05 PM
Subject: [tunerpro] Re: Progammatic interfaces?
Did everyone get the attachment?
------------------------------------------------------------------------------
From: Jason H <scorp1us@xxxxxxxxx>
To: "tunerpro@xxxxxxxxxxxxx" <tunerpro@xxxxxxxxxxxxx>
Sent: Monday, November 12, 2012 3:45 PM
Subject: [tunerpro] Re: Progammatic interfaces?
Yes, however I've realized my file on this computer does not have the spark
calculation as well.
I'll try to attach the version with the spark table math later. **NOTE** I do
not take my math as gospel. The more dialed-in your readings are, the finer
adjustments you make. I went through several iterations, so you'll probably
have to adjust the correction factors while you get dialed-in. Failure to
adjust quickly enough can lead to engine damage, USE AT YOUR OWN RISK.
Really, it is simple, but it took some time. The PCM's map/rpm cells do not
line up with the logged cells, so you have to do some averaging to fill in the
gaps. The number of cells on a 12xxxx ECU is even smaller, so the sheet can't
be used directly (which is why we should have an algorithm do this). Since I am
super lazy, what I did (and you'll see this) is I take a copy/paste, then
iterate it each step to get the biggest cell table then cut it down for pasting
back into tunerpro.
------------------------------------------------------------------------------
From: Brandon Cossette <bcossette@xxxxxxxxx>
To: tunerpro@xxxxxxxxxxxxx
Sent: Monday, November 12, 2012 3:25 PM
Subject: [tunerpro] Re: Progammatic interfaces?
Jason,
Do you have a spreadsheet for the 16197427 PCM's? If so can you share it with
me?
On Nov 12, 2012 3:06 PM, "Jason H" <scorp1us@xxxxxxxxx> wrote:
Thanks for your offer, but I already have that too. :-) I am an excel wiz.
I am just a really lazy excel wiz. Copy/pasting varies between ECUs as not all
have the same RPM and MAP cells, so one spreadsheet does not fit all, but one
algorithm can (or can be conditionally executed)
There are other applications that you can do of course, that was a trivial,
yet cool example. I needed something people could follow.
Given the plethora of python libraries out there, it would be trivial to
turn these into web services as well.
Imagine developing your own dash (true a 1-second delay would be a problem,
but if the event based interface was used this would not be a problem)
integrating 3rd party libraries, (statistics, etc) logging data to common
databases... Tunerpro turns into a gateway drug. You could have your ipad,
phone etc, tap into it.
If an ARM/Linux version of tunerpro (just he ALDL data+python, forget the
GUI) could be produced, then you can run the whole thing on a in-dash LCD and
use Python or a webservice to monitor any parameter int he car with a touch
interface. Tunerpro would develop a vertical market based on tunerpro. I
mention ARM because of Raspberry Pi, a $25 ARM board that you can couple with a
touchscreen. I don't know of any intel (XP) capable boards for that kind of
money.
----------------------------------------------------------------------------
From: Brandon Cossette <bcossette@xxxxxxxxx>
To: tunerpro@xxxxxxxxxxxxx
Sent: Monday, November 12, 2012 1:49 PM
Subject: [tunerpro] Re: Progammatic interfaces?
Jason,
I have developed an excel macro 70% that takes blm's according to your
datalog (with a wideband) and automatically makes corrections to your ve table.
You can copy and paste from a generated VE Table to and from Excel and
TunerPro. There's an import button on the front sheet to pull in a .csv
datalog. Message me for more info.
On Nov 12, 2012 12:59 PM, "Jason H" <scorp1us@xxxxxxxxx> wrote:
As a software developer myself, I would be able to probably write an auto
tune module if TunerPro exported it's readings. This is likely not going to
happen, however it would be immensely cool for me to be able to load a script
into TunerProand access and write the values as needed.
For this I would recommend Python, which has an "embedding" module (
http://docs.python.org/2/extending/embedding.html ), probably use SIP (
http://www.riverbankcomputing.com/software/sip/intro )to interface between the
C/C++ runtime (I'm guessing TunerPro is in C/C++) and provide python objects.
If you can't follow this, this is how it would play out.
Tunerpro would take a command line script argument (myfile.py) or a menu
would allow a specification of script with a file-select dialog.
Depending on how the hand-off to python is implemented, the script would
be called at some time (either by registering functions on a particular event
or a time interval)
The python script would run, and on completion control would be reverted
back to TunerPro.
Example code (assuming a timer starts the script every second)
import tunerpro # creates the tunerpro C++/Python interface object
def checkSparkTable(): #declare a function that
does the following:
for rpm in tunerpro.ecu.rpm_graduations: # returns a list of [400,
600, 8000, 1000, 1200, 1400, 1600.. etc - specific to each ECU]
for map in tunerpro.ecu.map_graduations: # returns a list of MAP
graduations [0, 20, 40 ... 100]
rcell = tunerpro.tables("average spark retard").rpm(rpm).map(map) #
for brevity pick out retard cell and hold onto it.
scell = tunerpro.tables("main spark").rpm(rpm).map(map) # for
brevity pick out spark cell and hold onto it.
if rcell.samples > 5 and rcell.value > 0: # if we have a 5
samples and we have retard
scell.value = scell.value - 1 # decrease timing 1
degree
rcell.samples = 0 # reset the retard
cell so we don't do this again until we have 5 more readings
rcell.value = 0 # reset the retard
cell so we don't use old data
checkSparkTable() #invoke the function
This will watch the average spark retard table and bump the main spark
table. This will be invoked and process the whole table every second. TunerPro
would have to come up with and publish the object model (or rather, this stuff
might be assigned by your definition file)
Instead of fixed-time invocations of this script, TunerPro could develop
a call-back model for events:
tunerpro.tables("main spark").onWrite.addHandler(checkSparkTable)
Where the python logic above is invoked every time the TunerPro updates
the values in the table from from the datastream. This is a little more
complicated because the C++ program needs to directly support calling python
functions, whereas a timed invocation just happens.
Similarly:
tunerpro.ecu.flags(flagname).value = true or false
tunerpro.ecu.list(listname).at(value) = some value
If we come up with a library of functions, we can distribute that and
people can use the functions as:
import tunerpro
import jasonslibrary
import daveslibrary
jasonslibrary.checkSparkTable()
daveslibrary.adjustBLMs()
Visit the TunerPro web site at http://www.tunerpro.net/ To unsubscribe, email
tunerpro-request@xxxxxxxxxxxxx with "unsubscribe" in the Subject, or visit
http://www.tunerpro.net/mailingList.htm.
Other related posts:
