[tunerpro] Re: Progammatic interfaces?
- From: Wayne <fatboy.tyso@xxxxxxxxx>
- To: "tunerpro@xxxxxxxxxxxxx" <tunerpro@xxxxxxxxxxxxx>
- Date: Tue, 13 Nov 2012 12:15:23 +1100
Yeah got it thanks mate
Regards
Wayne Tyson
0428668290
On 13/11/2012, at 12:05 PM, Jason H <scorp1us@xxxxxxxxx> wrote:
> 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()
>
>
>
>
>
>
>
>
>
>
>
>
>
Other related posts:
