[tunerpro] Re: Progammatic interfaces?
- From: Jason H <scorp1us@xxxxxxxxx>
- To: "tunerpro@xxxxxxxxxxxxx" <tunerpro@xxxxxxxxxxxxx>
- Date: Tue, 13 Nov 2012 11:01:41 -0800 (PST)
Ok. so if you have classes already (or come up with them) that allow easy
access to the stuff in the "tree" then it should be cake.
This stuff though all depends on your bin/xdf. So my OD_TPV5_v250.XDF
determines the tree. Example:
TunerPro - Library
ÂÂ ECU - Values from ECU object
ÂÂÂÂÂÂ 0D Parameters-
ÂÂÂÂÂÂ Air fuel mode words
ÂÂÂÂÂÂ Engine constants
ÂÂÂÂÂÂ ....
ÂÂ Application
ÂÂÂ ÂÂÂ Various application objects. (Dunno what is useful)
The ECU section is the parameter tree, we need an object to jsut map to the
groups and the group maps to items of flag, scalar table objects.
So:
ECU.group("IAC Parameters").scalar("Park Position for IAC") would refer to a
scalar object (or value). For me it is 150 steps.
ECU.group("IAC Parameters").flag("Closed loop Idle") would refer to a flag
object (or boolean value). For me it is false.
ECU.group("IAC tables").table("IAC Counts vs. Desired Airflow") would refer to
a table object. Table objects are a little tricker as you might want to select
columns not by index, but by value but a generic interface is still doable. But
these things would also be useful COM objects if any kind of COM automation was
to be exposed. From those COM interface files, you could use SIP and get both
interfaces of the price of one. But gor gearheads Python is a lot easier to
hack as you don't need a compiler and developer experience. It'd just be a text
file.
________________________________
From: M Mansur <mmansur@xxxxxxxxxxx>
To: tunerpro@xxxxxxxxxxxxx
Sent: Tuesday, November 13, 2012 1:33 PM
Subject: [tunerpro] Re: Progammatic interfaces?
From the bottom of http://www.tunerpro.net/
Â
â Development and
Other Info
TunerPro is developed in C++ Win32
API (without MFC/ATL/COM) using Visual Studio 2010 (IDE & Compiler) on
Windows 7. As of October 2010, TunerPro (version 5) in its entirety, including
all custom controls, comprises 103,000 lines of code (just code lines - no
comments or whitespace). The source code is not available. From: Jason H
Sent: Tuesday, November 13, 2012 10:29 AM
To: tunerpro@xxxxxxxxxxxxx
Subject: [tunerpro] Re: Progammatic interfaces?
 It
really isn't that 'hard' if you use SIP. The sip tool will use your C++
headers.
If you have good classes and use model-view architecture, this would be
surprisingly easy to add. Now, this is based on the assumption that it is
programmed in C++.
Would you mind divulging what it is developed in? I
realize you might want to keep it secret but it might help with me explaining
things.
Â
________________________________
From: M Mansur
<mmansur@xxxxxxxxxxx>
To: tunerpro@xxxxxxxxxxxxx
Sent: Tuesday, November 13, 2012 1:18 PM
Subject: [tunerpro] Re: Progammatic
interfaces?
Â
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!
>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:
