Language: The ActiveX control is in C++ (ATL, not MFC for the control container). This just made it easier to force finicky timings, etc. (I wanted a background thread for repetitive polling so the UI wouldn't crawl with the slower protocols like 9141). Also, a base class with virtual members worked well for 'protocol'.

The test app and the top level plug-ins are in Visual Basic. I don't normally work in it, but all the plug ins are going Open Source and we wanted to show different languages (I'm doing another plug in for an open ECU all in MFC).

Turning other things into plugins: Again, ours are all going open source and we're doing a new SDK for LogWorks 3. You could experiment with the LW2VDev control that gets installed now (it actually makes it quite easy to add channels to LogWorks), but the LW3 version is slightly different (support for bit channels and some other new LW3 stuff).

There is also an existing SDK that makes it pretty easy to drop our hardware into other loggers.

I'm not sure what you envision for your Logger. Supplying functionality as a LogWorks plug-in is certainly welcome, but you are more than welcome to integrate support for our acquisition hardware into your own logger as well.

Specific Params: see protocols.xml in the installation directory. You can add parameters, change conversion formulas, and so on. There is a comment block at the top of the file. There is no concept of 'virtual' channels (some loggers let you create a mathmatically combined channel, but I didn't bother in the plug-in because LogWorks can already generate math channels based on other channels).

I hope that helps.
-jjf

 

I do have plans to integrate the Innovate MTS stuff into my app. But I had a feeling yours already does most of what I need, so If there is a standard interface for the plugins, I'd add it to mine so it can pass data to Logworks.

I'll give it some time to see what everything looks like when I recieve my package.

 

I openned the protocols.xml file with notepad and found out that Load is only from 0 to 160. I do not think this is going to work since the tables go to 260 load.

<datachannel id="#1C" name="Engine Load" units="%" min="0" max="160" expr="x*0.625" type="0"/>

If I change the max numbers to 260 as reflected in the rom tables, would it work?

There is also no mention of Knock Sum. Is it possible to write a formula for Knock Sum and add it to the xml file? What would the formula be?

jfitzpat, can you help with this?

 

NJ,

1C is the request for the ECU load which goes up to 160, so the maximum of 160 is correct. You can't just change that to 260 or some higher number. That specific request just ends at 160.

As far as knock, yes, we could write our own line in the .xml file, similar to the way it is in Mitsulogger or EvoScan. I don't have anything in front of me right now or I would give you the line.


Eric

 

Both correct. The ECU returns a value of 0 to 255. 255 * .625 = 159.375. So I made the gauge 0-160. If you change 160 to 300, the gauge in LogWorks will go up to 300, but the ecu will never return a value that high.

If you need to log higher load values, there may be other ECU params to query. Alternatively, you can calculate load in LogWorks from other values (ex. RPM and MAF).

Yes, you are free to add lines. The parameters in the XML file for each protocol are either ones from specs or ones I could test myself based solely on forum searches. I only had a very limited time with real SSM and MUT vehicles, and my wife's Lexus only supports OBD-II PIDs up to 0x1F. I could have 'lifted' params from other people's efforts, but even though this is open source, that just didn't feel right. Being a commercial vendor it seemed natural to me for some people to suspect our motives (see Evo4Mad's comments earlier in the thread). So I thought it was important to provide stuff to the open ECU communtities without giving any perception of plagerizing their work.

Of course, if people are inspired to buy mountains of LC-1s (I think one per cyl with 15 or 20 spares is a great way to go ) we won't refuse their money!

-jjf

 

Thanks Eric. This is what I came up with for Knock Sum based on Evoscan and Mitsulogger

<datachannel id="#26" name="Knock Sum" units="count" min="0" max="50" expr="x" type="0"/>

This is Evoscan:

<DataListItem DataLog="Y" Display="Knock Sum" LogReference="KnockSum" RequestID="26" Eval="x" Unit="count" MetricEval="" MetricUnit="" ResponseBytes="1" GaugeMin="0" GaugeMax="50" ChartMin="0" ChartMax="50" Notes=""/>

This is Mitsulogger:

<Request LogReference="KnockSum" RequestID="26" Eval="x" Unit="count" Logged="y" Response="2"/>

I am assuming that "Eval="x" in Evoscan/Mitsulogger is the same as "expr="x" in Logworks.

Would this work?

 

Looks to me like its formatted correctly..

 

I also added a formula for Airflow. This is the first step to calculate Load based on airflow/rpm*852. Here it is

<datachannel id="#1A" name="AirFlow" units="Hz" min="0" max="1603.95" expr="x*6.29" type="0"/>

The one for Mitsulogger/Evoscan:

<Request LogReference="AirFlow" RequestID="1A" Eval="6.29*x" Unit="Hz" Logged="y" Response="2"/>

<DataListItem DataLog="Y" Display="Air Flow Hz" LogReference="AirFlow" RequestID="1A" Eval="6.29x" Unit="Hz" MetricEval="" MetricUnit="" ResponseBytes="1" GaugeMin="0" GaugeMax="1650" ChartMin="0" ChartMax="1650" Notes=""/>

THE BIG QUESTION:

Where would I place the complex formula for calculating load in the protocols.xml file?

Mitsulogger has this:

<!-- Place all Complex requests below this line -->

and we place the complex formulas below it.

In Evoscan the complex LoadCalc formula is placed AFTER the formulas needed to calculate load.

I assume that I should follow the Evoscan model?

Here is the LoadAF formula:

<datachannel id="#00" name="LoadAF" units="measure" min="0" max="260" expr="AirFlow/RPM*852" type="0"/>

 

Step 1. Select the channels you want to calculate on for logging (ex. AirFlow and RPM)

Step 2. Rename your data channels for AirFlow and RPM so that they have no spaces or funny characters in them ("AirFlow" and "RPM" sound good to me!)

You can do this on the Live Dashboard before you log (Channels/Configure Channel) or after you save your sessions (Chart view, Channels/Configure).

Step 3. From the chart view of your log select Tools/Formula Calculator

Step 4. In the formula calculator enter:

MC(LoadAF;measure;0;200) = Throttle/RPM*852

NOTE: "Throttle" and "RPM" are the names of data channels. So the line above means 'Make Channel (MC) named 'LoadAF', using units 'measure', with a scale of 0 to 200 (the last two params are option). Populate the channel by taking Throttle measurements and dividing them by RPM then multiplying by 852.

Step 4. Hit the 'Calculate' button.

The trace will appear. The reason it is done this way (instead of my plug in) is two fold:

First, ECU data is kind of steppy (at least with OBD-II). It is often helpful to smooth the channels (right click on the trace and select "smooth <channel>") before calculating. Second, this allows calculations based on both ECU extracted channels and MTS device channels (ex. airfuel combined with x).

I hope the above is clear. Note, you can save your formulas for quick access. You can also write formulas that prompt your for channels and other numeric values.

-jjf

Edit: Channel values, the only thing I would double check is HEX vs. decimal. In the post above, "#26" is a hex value (base 16) in my plugin. The other lines do not specific. If they assume hex, then the line is fine. If not, then the pound sign is not needed. I'd find another common value (like RPM) to check.

 

Shouldn't the formula be

MC(LoadAF;measure;0;260) = AirFlow/RPM*852

The max load on an Evo 8 is 260 and why was Throttle thrown into the equation????

 

Yes, the formula should be airflow. I had a senior moment. I tried the actual steps to make sure my recollection of syntax was correct, but the log I opened had no AirFlow channel. So I substituted a channel name I did have and picked a range that would give me a nice visual curve. I copied and pasted into my post, but did not remember to change the channel name, or the range, to be consistant with the example at hand.

Sorry,
-jjf

 

I have the same problem, is there any update here??

 

The latest version of the plug in is included in the LogWorks installer, which can be downloaded here:

http://www.innovatemotorsports.com/s...rks2-setup.exe

If you still have problems after installing this, please let me know.

-jjf

 

Joe / MJ / Others -- I need to buy a wideband and MAP sensor and have been considering Zeitronix and Innovative. The LC-1 seems to be a great wideband, but what would I need to log boost in Mitsulogger or Evoscan and how much would it cost? (I know what I need with the Zeitronix setup.) Finally, what are the pros / cons of each? Thanks & Merry Christmas!

 

Let me give you the pricing breakdown on my set-up:

LM-1 = $350 I just found one on e-bay for $299

LMA-2 = $99. This will hook up to the LM-1 and will allow you to hook up to five sensors. I have mine hooked up to pick RPM, Boost.

GM 3 Bar Sensor with harness = $75 I have had zero problems with this sensor. Some would have you believe that it is inaccurate. But if it is good enough for Malibu Jack, it is good enough for me. You can also pay more and use the more expensive AEM 3.5 bar sensor.

XD-16 gauge = $200 off ebay. Here is one. Here is another

Total cost = $724

The ability to create a ONE log that includes ALL the tuning data that you want:

PRICELESS