[tunerpro] Re: Progammatic interfaces?
- From: Brandon Cossette <bcossette@xxxxxxxxx>
- To: tunerpro@xxxxxxxxxxxxx
- Date: Mon, 12 Nov 2012 13:49:09 -0500
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()
>
>
>
>
>
>
>
>
Other related posts:
