[tunerpro] Re: Progammatic interfaces?
- From: Jason H <scorp1us@xxxxxxxxx>
- To: "tunerpro@xxxxxxxxxxxxx" <tunerpro@xxxxxxxxxxxxx>
- Date: Tue, 13 Nov 2012 15:56:52 -0800 (PST)
Ok, I'm now getting dupes....
Sigh.
________________________________
From: Jason H <scorp1us@xxxxxxxxx>
To: "tunerpro@xxxxxxxxxxxxx" <tunerpro@xxxxxxxxxxxxx>
Sent: Tuesday, November 13, 2012 11:02 AM
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!
>Igot 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:
