Logworks plugin for SMEC/SBEC/LM

[risen]

Here it is, finally, 4 months overdue. This is the initial release of my logworks plugin with smec/sbec support. This will read the data from your ECU and publish it into logworks for integration with the output from your wideband o2. I've tested it on a 88 t1 smec on the bench and it's stable (had it running for 3 or 4 hours today). I haven't had any chance to test it on a sbec or an lm yet, but it should work on those 2. Please let me know if anyone has problems with it, but please try and follow the directions below before having me chase a user error :) . There are still plenty of other features that I'm still working on (auto-id being one).

So, what do you need to use this thing?

1) an Innovate LM-1 or LC-1 and Logworks2 (I've had reports of logworks3 working, I haven't confirmed)
2) a serial or USB interface for you SMEC/SBEC/LM

That's it for needed hardware. Here's the basic instructions on how to use the software.
a) You need to install logworks2, default settings are fine.

b) You will need to hook your wideband output to one of the serial ports or USB ports on your laptop. You need to know which com port your Wideband is hooked up to.

c) You will need to hook your ECU up to another USB or serial port on your laptop. Yes, you need 2 ports, both always connected. You will also need to know which com port your ECU is connected to.

c) You need to extract the lw2_lm_vdev.exe file from the zip in this thread somewhere to your hard disk. When you open the .zip file it will be under the Release directory.

d) Run the program you extracted. This is the logworks plugin that will read the data from your ECU and publish it into logworks for integration and graphing with the wideband output. You will now need to configure the plugin.
d.1) You need to select your type of ECU. It cannot be autoid.
d.2) You need to select your com port, this must match the com port your ecu is connected to.
d.3) You need to select your ram map. This must match the cal you're running.
d.4) You need to select which variables you want to log by placing a check box next to them. If you select a variable and it's address is FF, it will not be logged because the address is unknown.
d.5) You can now hit start. You should see the status line change, then start flipping rapidly and all the boxes should become greyed out.

e) You will now need to start logworks. You need to know which serial port your wideband is connected to and select it from the dropdown menu.

f) At this point, if all has gone well, you should be able to add some guages and watch the realtime guages with your wideband. You can also start a realtime log, which will log and graph the values together.

Notes of caution, items worth mentioning:
You cannot stop the plugin while logworks is running. If you want to make changes you need to close logworks, close the plugin, then restart the plugin select the changes and restart logworks. I wish there was a way around this, but between the plugin's current architecture and logworks, it's not possible ATM.

You cannot start logworks before the plugin.

If you botch something (like mistakenly edit an address) you can hit reset, and it will reset all the values to defaults.

Changing ram maps will also change the variables addresses. So, if you edit one map, then change to another, your edits will be gone.

Your last sessions' settings are saved to the windows registry and reloaded upon next run of the program. If you like this feature buy Jeff C a beer for requesting it :) .

Autoid doesn't currently work. It will in a future release since I now have a working bench rig.

Variables with address of FF are ignored, even if you select them.

Source code is included, however It's still got a *long* way to go. If you want to mess with it I would appreciate being able to provide any improvements to everyone.

[thefitisgay]

awesome... now if only i had a car worth logging

[TommyT]

Excellent! Thanks for sharing this with all of us!

[roachjuice]

so i cant get this to work. i unzip it and go to the release file then it asks me if i really wanna run it then i click run and it doesn't open. wtf?

[risen]

so i cant get this to work. i unzip it and go to the release file then it asks me if i really wanna run it then i click run and it doesn't open. wtf?

Ok, try this before we go too crazy. Save the zip file somewhere, like to your desktop and close your browser. Then right-click the .zip file and say extract to somewhere (like your desktop). Then, once you open the folder that was extracted, navigate to the Release subdirectory. In there you'll see a .exe file with a funny squiggle as it's icon (it's supposed to be a lambda symbol, but I have the artistic abilities of a 3rd grader with Parkinson's). Double click that .exe file and you should be presented with the main screen for the plugin.

[turbovanman²]

Wow, awesome. Where do you get the serial interface for the SMEC?

[roachjuice]

Ok, try this before we go too crazy. Save the zip file somewhere, like to your desktop and close your browser. Then right-click the .zip file and say extract to somewhere (like your desktop). Then, once you open the folder that was extracted, navigate to the Release subdirectory. In there you'll see a .exe file with a funny squiggle as it's icon (it's supposed to be a lambda symbol, but I have the artistic abilities of a 3rd grader with Parkinson's). Double click that .exe file and you should be presented with the main screen for the plugin.

lol yea i go a little ape shyt on stuff sometimes :D ill try that and report back. thanks.

[roachjuice]

k i did everything u said and still when i click on the lambda symbol it acts like it opening but nothing pops up? i had it open ONCE then it never opened again. no clue what happened. lol

[risen]

Wow, awesome. Where do you get the serial interface for the SMEC?

You can either use one of the interfaces that Rob is selling (if he's gotten to them) or use the dlp-txrx-g USB module I have in the KB article on LM datalogging.

If you use the dlp interface you'll need to set the tx/rx inversion switches in mprog (which is actually much easier than I just made it sound). For the car side, you will need to hook up the green sci wire to the pin with arrow pointing twards the black connector and hook the pink sci wire up to the pin with the arrow pointing twards the USB connector on the device.

The KB article gives a pretty good walk through of the software side, the sci usage is really the only item I need to be more explicit with.

Maybe tomorrow after my dentist's appt I'll get to that stinking KB article.

[risen]

k i did everything u said and still when i click on the lambda symbol it acts like it opening but nothing pops up? i had it open ONCE then it never opened again. no clue what happened. lol

What version of windows are you running? And are you running any antivirus software?

[roachjuice]

windows vista. and no anitvirus. maybe widow$ defender? but i had it open ONCE and closed it. then tried to open it again and nothing. :confused2: ive deleated it and downloaded it like 8 times. same result. also had another problem with winlog. rpm reads way different. boost is maxed out at idle. throttle position is at 50 at idle and goes to 100 at 50% lol. and there are two different rpm things for the lm plug in on that. bbs60 only and 2 byte. whats the difference? which do i need? i have a T-LM cal. im using franks dash too. the rpm reads 15rpm. yes 15. not 1500 lol. and goes up from there. but not to 1xxx just stays in 2 digit numbers. maybe im doing something wrong? the only logger that seems to work perfect for me is lm log. but it doesnt have the gauges like i like. :D thanks for responding. :nod: if need be i can take a video of whats going on and post it on youtube. maybe video will explain alot more.

[CSXRT4]

wow this came at a perfect time. Hopefully my dad and I can get our hybrid project going soon and test this plug-in out :)

thank you for setting this up dude! :amen:

[roachjuice]

wow this came at a perfect time. Hopefully my dad and I can get our hybrid project going soon and test this plug-in out :)

thank you for setting this up dude! :amen:

lol at ur advatar:thumb:

[risen]

windows vista. and no anitvirus. maybe widow$ defender? but i had it open ONCE and closed it. then tried to open it again and nothing. :confused2: ive deleated it and downloaded it like 8 times. same result. also had another problem with winlog. rpm reads way different. boost is maxed out at idle. throttle position is at 50 at idle and goes to 100 at 50% lol. and there are two different rpm things for the lm plug in on that. bbs60 only and 2 byte. whats the difference? which do i need? i have a T-LM cal. im using franks dash too. the rpm reads 15rpm. yes 15. not 1500 lol. and goes up from there. but not to 1xxx just stays in 2 digit numbers. maybe im doing something wrong? the only logger that seems to work perfect for me is lm log. but it doesnt have the gauges like i like. :D thanks for responding. :nod: if need be i can take a video of whats going on and post it on youtube. maybe video will explain alot more.

Ok if you use winlog you need to scale the rpm by 32 as long as you leave it at the defaults. You can use either RPM address for T-LM, I believe it still has the tweak for the 1 byte RPM. Although, the 1 byte will be faster. Multiply the 1 byte by 32 that and it should look sane (both logworks and winlog will do this automatically for you once you configure them to). You'll need to do the same in logworks, actually. All the values will return 0-255 in the guages, you just need to setup the mappings. All of the scaling/mapping will be taken care of in the future, but for now, most of the values are easy enough to map.

TPS is a little tricky, here's the basics. 0 throttle will equal 0, 100% throttle will equal 255. But, your throttle position sensor never actually hits 0% or 100% of their voltage range (ever noticed how you have to twist the sensor a little when you put it on the throttle body?). So you need to map your closed throttle (50 in your case) to 0%. Now, the maximum throttle can normally be found by taking the minimum value (50) and subtracting it from 255, which should give you 205 as your 100% throttle point. If you use that scaling in winlog, TPS should look sane.

There's some thread around here with the info on how to setup the scaling for winlog, it's probably in the winlog plugin thread.

I don't know what's going on with the logworks plugin. I assume you've tried to reboot? And does it give you a error message about the program needing to close because of an error?

[roachjuice]

Ok if you use winlog you need to scale the rpm by 32 as long as you leave it at the defaults. You can use either RPM address for T-LM, I believe it still has the tweak for the 1 byte RPM. Although, the 1 byte will be faster. Multiply the 1 byte by 32 that and it should look sane (both logworks and winlog will do this automatically for you once you configure them to). You'll need to do the same in logworks, actually. All the values will return 0-255 in the guages, you just need to setup the mappings. All of the scaling/mapping will be taken care of in the future, but for now, most of the values are easy enough to map.

TPS is a little tricky, here's the basics. 0 throttle will equal 0, 100% throttle will equal 255. But, your throttle position sensor never actually hits 0% or 100% of their voltage range (ever noticed how you have to twist the sensor a little when you put it on the throttle body?). So you need to map your closed throttle (50 in your case) to 0%. Now, the maximum throttle can normally be found by taking the minimum value (50) and subtracting it from 255, which should give you 205 as your 100% throttle point. If you use that scaling in winlog, TPS should look sane.

There's some thread around here with the info on how to setup the scaling for winlog, it's probably in the winlog plugin thread.

I don't know what's going on with the logworks plugin. I assume you've tried to reboot? And does it give you a error message about the program needing to close because of an error?
very good info! yes ive rebooted. and gives no message. the only time anything gives me an error is winlog when i try to configure the device the second time. the first time im able to do everything i want. then i can go in again and it will shut down and give an error message.

[roachjuice]

ok just to clarify what he is talking about by "scale" u go into edit>device config>logic mod driver> then example: click on rpm. click settings then import then find the correct readme (rpm or engine speed cant remember) and click open and WAHLAH its scaled! took me about 20min to figure out what the hell he was talking about lol. but i got it.

[roachjuice]

update. scaling worked for winlog. :D but if i go to configure it again after ive configured it. it just crashed and shuts down lol.

[risen]

update. scaling worked for winlog. :D but if i go to configure it again after ive configured it. it just crashed and shuts down lol.

Hmm, I thought I fixed that with winlog. Well, I need to update that plugin to support smec and sbec ecus, so I'll put it on the list of things to check. I believe that if you want to adjust the winlog plugin settings you can remove the driver and hit ok, then add the driver back in. That should give everything a clean initialization and you should be able to do what you want.

Now, the logworks plugin, there's 2 things we can try. The first is that you can run the program in windows xp compatibility mode. You can set it do this by right clicking on the program and selecting properties. On the properties page there should be a tab where you can tell it to run in compatibility mode. Try an set it to XP.

The second is you can try and remove the registry keys the program creates. I can give you the place to remove them from, but if you're not comfortable with regedit, this may not be a good option.

[roachjuice]

k hold on ill try the xp thing.

[roachjuice]

k i tried the xp thing and still the same results? i just don't understand why in the hell it worked the first time i had it on this computer and now nothing lol. i also tried it on my parents computer and same results.

[risen]

Well, it's down to the registry entries. That's the one thing it does on the 1st startup. Are you comfortable with regedit?

[roachjuice]

Well, it's down to the registry entries. That's the one thing it does on the 1st startup. Are you comfortable with regedit?

sure i guess lol. as long as it doesn't mess with my operating system im good. :thumb:

[risen]

sure i guess lol. as long as it doesn't mess with my operating system im good. :thumb:

It won't mess with anything. You need to go to the HKEY_CURRENT_USER branch, then open software. You should see an entry for 'Turbo Mopar Logworks Plugin' . You can delete that key and all subkeys (right click and hit delete). That should be it. After you do that, try and run the plugin again.

[roachjuice]

did that and found the key. deleted it. then started all over again. downloaded the zip file and everything. still nothing. oh well. i'll just use winlog. thanks anyway for helping lol.

[risen]

Ok, there's something else going on, and I can't see why it wouldn't work but 1 time. If you want to troubleshoot it futher pm me.

[roachjuice]

Ok, there's something else going on, and I can't see why it wouldn't work but 1 time. If you want to troubleshoot it futher pm me.

k no problem. :thumb:

[CSXRT4]

Ok I am almost ready to test this out.

First I have a question on the ecu type. Im using T-SMEC so I think I set this to the DRB-II right? Is there any way to set the plugin up to work with the "High speed datalogger" mod of T-SMEC by changing baud rates?

Also what program did you write this with? Visual studio? Is there any way to set it up to remember your settings so when you open it back up everything is checked and all the ECU stuff is selected as you last had it?

also, do you think this cable would work??? http://www.xenocron.com/xeno-usb-datalogging-kit-p-72.html


Thanks

[risen]

Ok I am almost ready to test this out.

First I have a question on the ecu type. Im using T-SMEC so I think I set this to the DRB-II right? Is there any way to set the plugin up to work with the "High speed datalogger" mod of T-SMEC by changing baud rates?

I believe that the logger mod will set the baud rate to 9600. If you leave the stock options for the cal, it should work out of the box with the DRB-II baud rates of 7812/62500. Someone tested it with a baudmod cal (high baud set to 9600) and had good results. I'm not 100% sure that the high speed logger mod and the baud mod are the same, but I'd try it with the regular settings first.



Also what program did you write this with? Visual studio? Is there any way to set it up to remember your settings so when you open it back up everything is checked and all the ECU stuff is selected as you last had it?

'
Yes, the code was all written in visual studio (2002) using visual C++.

The program will save your settings after you hit the start button. If you make changes and close the program without hitting start they will not be saved. Also, if you stop the plugin, you will have to restart it and logworks. There isn't anything I can do about that, it has to do with the nature of the control used to put the data into logworks. You also have to start the plugin before logworks, again, has to do with how Innovate setup the software.



also, do you think this cable would work??? http://www.xenocron.com/xeno-usb-datalogging-kit-p-72.html


Thanks
I think that cable will work, but you'll still need to change the inversion settings using the mprog utility. I haven't ever tested one, so I can't say for sure. I can say, with certainty, that the dlp txrx-g adapter will work. I've used it on the bench and on my car to log and it's always been good to me. The instructions on how to set it up have been posted 2x or 3x (I still need to do a KB article). The dlp adapter is 10$ cheaper, but you'd need a USB cable (one for a digital camera or phone will work, has to be A to mini-b).

[CSXRT4]

I believe that the logger mod will set the baud rate to 9600. If you leave the stock options for the cal, it should work out of the box with the DRB-II baud rates of 7812/62500. Someone tested it with a baudmod cal (high baud set to 9600) and had good results. I'm not 100% sure that the high speed logger mod and the baud mod are the same, but I'd try it with the regular settings first.


'
Yes, the code was all written in visual studio (2002) using visual C++.

The program will save your settings after you hit the start button. If you make changes and close the program without hitting start they will not be saved. Also, if you stop the plugin, you will have to restart it and logworks. There isn't anything I can do about that, it has to do with the nature of the control used to put the data into logworks. You also have to start the plugin before logworks, again, has to do with how Innovate setup the software.


Ok ill make sure it works with the standard baud settings and then play with the high speed logger stuff and let you know what my results are.

Ive used other plugins for logworks so I have an idea of how everything works. Hopefully I can get this SMEC plugin going well and I will be ecstatic. Ive always tuned with logworks and I believe its the best datalogging program out there :D

Thanks

[ShelGame]

FWIW, I doubt it will work with the 'high speed logger' mod in T-SMEC. That routine uses a specific simplified protocol. UNless he put specific support into the plugin (I didn't think so), then the DRBII protocol will not work.

That said, the hi-speed logger mod was originally intended for the T2 SMEC (DRBI protocol). The DRBI protocol has a slower logging speed than the DRBII. I only included it because Jason's logger program was what I used,; he designed the hi speed routine to work with his program.

Theoretically, the DRBII logging protocol should easily log 100 samples/sec (total). That's 10 samples/sec for 10 channels - should be fast enough for just about anything you'd want to measure. You could possibly log faster with the hi-speed logger routine. But, there is a risk that you will interrupt the normal program flow doing that, so it's not recommended.

Risen - have you ever tested the max logging speed with your plugin? Just curious what the actual max throughput is...

[risen]

FWIW, I doubt it will work with the 'high speed logger' mod in T-SMEC. That routine uses a specific simplified protocol. UNless he put specific support into the plugin (I didn't think so), then the DRBII protocol will not work.

That said, the hi-speed logger mod was originally intended for the T2 SMEC (DRBI protocol). The DRBI protocol has a slower logging speed than the DRBII. I only included it because Jason's logger program was what I used,; he designed the hi speed routine to work with his program.

Theoretically, the DRBII logging protocol should easily log 100 samples/sec (total). That's 10 samples/sec for 10 channels - should be fast enough for just about anything you'd want to measure. You could possibly log faster with the hi-speed logger routine. But, there is a risk that you will interrupt the normal program flow doing that, so it's not recommended.

Risen - have you ever tested the max logging speed with your plugin? Just curious what the actual max throughput is...

I didn't put support in for anything other than the standard vanilla request an address - get a value type setup. So that's a negative on the high speed logger routine.

I haven't tested the max speed, but I have plans to (it should be easy to do with portmon, grep, and wc -l). I should mention that currently I have to issue 2 requests to the com port to get the proper value back on the T2 smec I have here, so that's what's in the code. Jeff C had the same issue with stability of return values on his car when testing it. At some point I'd like to figure out how to get it down to one read, but I've tried 4 or 5 different ways and there's always some instability in the values when I use the value that's 1st returned. It seems that the only way to ensure they're stable is to request the same location 2x and use the 2nd value returned.

Also, I believe that the innovate hardware only updates 12 times/s on the serial line. So it's very possible that the values from the smec can update fatser. That's the main thing I'm interested in testing is to see if logworks clamps the updates from the smec to the speed of their hardware. But I'd need a real in-car test to check that, since I don't have a LC-1 for bench testing or a smec in my car.

[jpcturbo]

One value obviously worked fine. Two had some issues. LMLog and SMECLog both throw out the first two Rx chars after sending an address request. I always wondered if Geoff or anyone figured out a truly sync method of communication.

[risen]

One value obviously worked fine. Two had some issues. LMLog and SMECLog both throw out the first two Rx chars after sending an address request. I always wondered if Geoff or anyone figured out a truly sync method of communication.

One value works fine because it is always a valid return. Everyone else can think about it this way (since you've already fought with this): if you're always requesting map, it doesn't matter if the return value was from 1 request ago or 20. Basically what was happening is when the program would request the value for the MAP memory location after requesting RPM but the 1st response would be RPM, sometimes. So, you'd get all sorts of invalid data. The one thing that I haven't tried is to send the next char to read *before* receiving the previous response. You can see the trouble with trying to do that, though. I had solved it on the winlog plugin by reading from the port, then writing the next value requested , then updating the values for winlog. So that the delay the update introduced was enough to keep in sync with the returns from the ecu. At least it was for a LM.

Maybe the tracing function in the MP Editor software will be enough to get this sorted out.

Rob, how did you handle it in your Palm software? Or did you not even have that sort of problem?

[ShelGame]

Rob, how did you handle it in your Palm software? Or did you not even have that sort of problem?

I don't remember losing values like that or having to repeat requests to get a valid value. But, I did have a hard time getting the coms established correctly. I think I added a 25 or50ms wait after sending before trying to read the data byte. It really shouldn't be necessary seeing as the instructions are like 10 bytes apart in the SMEC code. But, it must have something to do with the routine that the 0x12 command logger is in. It's in with the fan and A/C control running off of TOC1. As far as I can tell, this routine runs every 479us (roughly 0.5ms - very fast I think). So, it really shouldn't be necessary to wait 25-50ms, but it was the only way I could keep communications working in the 0x12 routine. The hi-speed logger never had a problem - thought it does seem to drop bytes every 5 sec or so. Which could simply be a product of the slight baud mis-match (9600 vs. 9613).

[vprtech]

I don't know if this helps any with the earlier SMEC and SBEC I stuff, but from what I've seen, even the slowest of the slow scan tools put SBEC II and later JTEC / SBEC III ecu's into mode 12 when polling various pids. The problem with most scan tools is that they wait 50-150 ms between requests, which allow for a very poor sample rate. I do not believe that the F tables are available if you are not in mode 12 (someone correct me on this?) On the later ecu's I have been able to poll a little more than four hundred request/answers a second.

At that rate, using a USB-TTL adapter, my dual core laptop is reaching it's limits, and I've seen the processor usage go over seventy percent. Ideally, I would like to have an interface that has an internal cache to handle the data and then send the data to the pc in packets The timing is very critical on these ecu's, and the usb to ttl seems to be the limiting factor. From what we have seen it appears that you can poll as fast as the ecu can send the data, which is usually under two ms, but sometimes slightly longer. Again, this applies mainly to the later ecu's as that's what I've been working with, but they use similar, if not the same commands, such as command twelve, and the same baud rates.

[CSXRT4]

Ok im having issues with this. I bought this cable, http://www.ftdichip.com/Products/EvaluationKits/TTL-232R.htm. Its from FTDI so I thought it would work. I set it up using MPROG like your article says, I also had to change the com port in the device manager to something under com10 (I tried com3 and com5). I updated the drivers with the FTDI drivers, and the hardware description comes up as "USB Serial Port (COM3)" under the "Ports" catagory in the device manager.

Originally (With the com port at 13) I would hit "start" and it would immediately say "Unable to init serial port". Then I changed the com port in the device manager to com3. With it on com3 I hit start and now the status will say "initializing serial comms" for a second or two before the box that says "Unable to init serial port" pops up again. :(

Any ideas???

[risen]

I don't know if this helps any with the earlier SMEC and SBEC I stuff, but from what I've seen, even the slowest of the slow scan tools put SBEC II and later JTEC / SBEC III ecu's into mode 12 when polling various pids. The problem with most scan tools is that they wait 50-150 ms between requests, which allow for a very poor sample rate. I do not believe that the F tables are available if you are not in mode 12 (someone correct me on this?) On the later ecu's I have been able to poll a little more than four hundred request/answers a second.

At that rate, using a USB-TTL adapter, my dual core laptop is reaching it's limits, and I've seen the processor usage go over seventy percent. Ideally, I would like to have an interface that has an internal cache to handle the data and then send the data to the pc in packets The timing is very critical on these ecu's, and the usb to ttl seems to be the limiting factor. From what we have seen it appears that you can poll as fast as the ecu can send the data, which is usually under two ms, but sometimes slightly longer. Again, this applies mainly to the later ecu's as that's what I've been working with, but they use similar, if not the same commands, such as command twelve, and the same baud rates.

Those scantools are probably limited by the speed of their hardware.

I think there's 2 seperate issues here. One, is whatever software your pc is running is causing the cpu to spike to that figure. Your pc is orders of magnitude faster than the uC in a ECU (even a relatively modern one). To read the data from a network card at 100mbit/s or even gigabit speeds takes a whole lot more power than most microcontrollers have, and I'm sure your pc can more than handle that. Also, packing the data into packets will only really lower the interrupt rate of your pc, which may have a positive effect, but it probably won't be noticable. If you're reaching the maximum throughput, bundling the data won't do any good because you still have the same amount of data to handle. I'd suggest stripping down what you're doing to eliminate the overhead caused by graphing or displaying the data to see if the polling rate stays high.

The FTDI adapters are good to around 1 megabit/s. And, if you do hit the max throughput on the adatper, it should not cause excessive cpu utilization (it should actually act as a cap). I've had 2 adpaters running at 115.2k and it wasn't taxing my system at all or dropping data. Plus, I'm pretty sure others (like the moates hardware) has gotten the ftdi chips up very close to 1 megabit. I'm pretty sure that the quarterhorse, demon and ostrich all use the ft232rl chip from ftdi. After seeing a quarterhorse in action I'd be surprised to hear of anyone hitting the limits of the ftdi hardware.

Certainly for a smec/sbec/lm they're more than adequate. And at 62.5k (as fast as it goes for a sbec/smec) baud, these adapters aren't even being asked to run at 1/10th of their max possible rate.

If you want more buffering, you can bring up the buffer on your serial port under the windows settings. That should allow you to hold more data on the PC side. But, expanding the buffer really won't do anything if your pc can't keep up with what it's already being asked to do.


Ok im having issues with this. I bought this cable, http://www.ftdichip.com/Products/EvaluationKits/TTL-232R.htm. Its from FTDI so I thought it would work. I set it up using MPROG like your article says, I also had to change the com port in the device manager to something under com10 (I tried com3 and com5). I updated the drivers with the FTDI drivers, and the hardware description comes up as "USB Serial Port (COM3)" under the "Ports" catagory in the device manager.

Originally (With the com port at 13) I would hit "start" and it would immediately say "Unable to init serial port". Then I changed the com port in the device manager to com3. With it on com3 I hit start and now the status will say "initializing serial comms" for a second or two before the box that says "Unable to init serial port" pops up again. :(

Any ideas???

Can you give me the exact model of the cable you bought? Also, for a smec you'll need to make sure that the inversion boxes *ARE* checked. If you have them unchecked, you'll need to change that. Although, I'm a bit puzzled by the differences in com ports having an effect on the software. I'll add that to the list of things to check.

As a side note, anyone who can't get the program to even open, could you tell me what your screen resolution is?

[CSXRT4]

Can you give me the exact model of the cable you bought? Also, for a smec you'll need to make sure that the inversion boxes *ARE* checked. If you have them unchecked, you'll need to change that. Although, I'm a bit puzzled by the differences in com ports having an effect on the software. I'll add that to the list of things to check.

As a side note, anyone who can't get the program to even open, could you tell me what your screen resolution is?

Its the 5v one, TTL-232R-PCB shown in the picture

http://www.ftdichip.com/Images/TTL-232R1.jpg


Ive always had an issue with connecting to devices if the com port is higher than 10, so its not just this. But com ports below 10 have always worked fine, its like this on both of my computers.

I hooked the SMEC-Rx to the USB-Tx and the SMEC-Tx to the USB-Rx, do I still have to check the invert boxes with it setup this way?

I tried doing a loopback test and I couldnt get that to work. I thought maybe it wasnt looping back because of the ttl level conversion or something. Does yours loopback???

Also I had a small issue of screen size on my laptop, this doesnt have anything to do with connectivity but I thought I would bring it up. The window is so large that I cant see everything at once, and it wont let me maximize :(

[risen]

Its the 5v one, TTL-232R-PCB shown in the picture

http://www.ftdichip.com/Images/TTL-232R1.jpg


Ive always had an issue with connecting to devices if the com port is higher than 10, so its not just this. But com ports below 10 have always worked fine, its like this on both of my computers.

I hooked the SMEC-Rx to the USB-Tx and the SMEC-Tx to the USB-Rx, do I still have to check the invert boxes with it setup this way?

I tried doing a loopback test and I couldnt get that to work. I thought maybe it wasnt looping back because of the ttl level conversion or something. Does yours loopback???

Also I had a small issue of screen size on my laptop, this doesnt have anything to do with connectivity but I thought I would bring it up. The window is so large that I cant see everything at once, and it wont let me maximize :(

I just wanted to make sure that you didn't get the 3.3v one. I think you're good.

Yes, you do have to check the inversion boxes. The inversion means that 0v = 1 and 5v = 0. Crossing tx and rx doesn't affect which level signifies each bit type.

The green smec wire should to to TX of the adapter and the pink should to to RX of the adapter.

I've looped mine back before, but it's not exactly the same as what you're using. You've probably already tried this but here's what I did. Hook the tx of the adapter to the rx of the adapter. You can then open hyperterm, connect to the serial port you have the device configured on and type some stuff. You should see that same stuff pop up.

I think I have to do something about the way the window is setup. There's a lot of information on that window and it takes a sizable desktop to show it all. It's fine on my laptop, but I run at 1680x1050. I think that's the problem people are having where the window doesn't even show up. I'm either going to have to tab the data, or make it resizable with a small startup size (like 320x200 or something).

[CSXRT4]

It works!!!

I uninstalled my usb drivers with the FTDI Clean Utility like it said to do here (http://www.xenocron.com/install/USB-Board.htm). I restarted my computer and plugged in the cable, the "install new hardware" window came up and I directed it to install the drivers (http://www.ftdichip.com/Drivers/CDM/CDM%202.06.00%20WHQL%20Certified.zip) I downloaded from the FTDI website. Then i inverted the Rx and Tx in MProg like you said.


Now the only thing I have an issue with is scaling all the inputs. Do you have a list of all the scalings?? I know MAP is -14.7-29.4 but thats the only one I have so far. I think I can use the scalings from the tables in D-Cal right? But what do I scale advance as?? Or Knock volts?

[zin]

Just thought it would be appropriate to throw a big "Thank You" out here, for Risen and everyone! With all the tools being developed/perfected, the community will soon have a full service ECU tuning and data logging, and while I'm not quite there yet, I really appreciate all the work that will have come before me, and all the headaches that have been endured for me! :thumb::thumb:

Mike

[lotsaboost]

^^:amen:. Unfortunately, I couldn't get my rpm's to display accurately:( Using the '87 LM.

[risen]

It works!!!

YAY!!


I uninstalled my usb drivers with the FTDI Clean Utility like it said to do here (http://www.xenocron.com/install/USB-Board.htm). I restarted my computer and plugged in the cable, the "install new hardware" window came up and I directed it to install the drivers (http://www.ftdichip.com/Drivers/CDM/CDM%202.06.00%20WHQL%20Certified.zip) I downloaded from the FTDI website. Then i inverted the Rx and Tx in MProg like you said.


Now the only thing I have an issue with is scaling all the inputs. Do you have a list of all the scalings?? I know MAP is -14.7-29.4 but thats the only one I have so far. I think I can use the scalings from the tables in D-Cal right? But what do I scale advance as?? Or Knock volts?

I believe advance is a signed value and I forget how to map it from the in-memory value to the human readable format at the moment. You can try and map 0-127 to be multiplied by 2 and 128-256 to be multiplied by -1/2 (this probably isn't 100% correct). Otherwise, we may need to use a table lookup in logworks for advance. Maybe Rob's got another trick up his sleeve for this one?

For most of the values you can use the min/max x values from dcal if that variable is used for the table input. Coolant and charge temp are 2 more that are a little tricky as charge temp isn't linear. RPM is 0-8192. I think if you look in the winlog plugin thread there's a good selection of values are in there.

I'd like to, eventually, include a definition file for logworks with the plugin that way we don't have to re-hash this every time someone gets it working :). All in due time, I suppose.

[risen]

^^:amen:. Unfortunately, I couldn't get my rpm's to display accurately:( Using the '87 LM.

Was it a T2 LM? And are you running a turbonator cal or a factory cal?

[ShelGame]

It works!!!

I uninstalled my usb drivers with the FTDI Clean Utility like it said to do here (http://www.xenocron.com/install/USB-Board.htm). I restarted my computer and plugged in the cable, the "install new hardware" window came up and I directed it to install the drivers (http://www.ftdichip.com/Drivers/CDM/CDM%202.06.00%20WHQL%20Certified.zip) I downloaded from the FTDI website. Then i inverted the Rx and Tx in MProg like you said.


Now the only thing I have an issue with is scaling all the inputs. Do you have a list of all the scalings?? I know MAP is -14.7-29.4 but thats the only one I have so far. I think I can use the scalings from the tables in D-Cal right? But what do I scale advance as?? Or Knock volts?

Advance is 0-128deg
Individual knock retards are 0-128deg
Knock volts is 0-5v
O2 volts is 0-5v
rpm is 0-8192rpm
Speed is 0-1024mph
Coolant temp is (-200)-260F (the scale in most of the D-Cal table files is wrong)
Injector PW is 0-49152ms
MAP is (-14.7)-29.4psi (for 3-bar MAP sensors)
Boost Target is 0-44.1psi (for 3-bar MAP sensors) because Baro is added to it before it is compared to MAP
Baro is (-14.7)-29.4psi (same as MAP)

[ShelGame]

Its the 5v one, TTL-232R-PCB shown in the picture

http://www.ftdichip.com/Images/TTL-232R1.jpg


Ive always had an issue with connecting to devices if the com port is higher than 10, so its not just this. But com ports below 10 have always worked fine, its like this on both of my computers.

I hooked the SMEC-Rx to the USB-Tx and the SMEC-Tx to the USB-Rx, do I still have to check the invert boxes with it setup this way?

I tried doing a loopback test and I couldnt get that to work. I thought maybe it wasnt looping back because of the ttl level conversion or something. Does yours loopback???

Also I had a small issue of screen size on my laptop, this doesnt have anything to do with connectivity but I thought I would bring it up. The window is so large that I cant see everything at once, and it wont let me maximize :(

Glad to know this cable works. I have the same one, but have yet to try it with LogWorks. It is only about $20 or so from Mouser/Digikey. It will be much cheaper as a DIY solution than my SCI cable.

[lotsaboost]

Yes, it is T2. The cal is from FWD(Cindy).
Was it a T2 LM?

[CSXRT4]

Glad to know this cable works. I have the same one, but have yet to try it with LogWorks. It is only about $20 or so from Mouser/Digikey. It will be much cheaper as a DIY solution than my SCI cable.

Yeah its really nice because its so compact. I actually ended up putting a stereo audio jack on the end of it (I didnt know when I bought it that they sold it like that), then I mounted a female audio jack in the car and now its easy to just plug it in at both ends and go :)


also, I moved my code routine down by the other "mod" routines and called it from the main loop and I think its working now. Thanks for the help with that, it must have been overflowing into the EEPROM area like you said.

[wowzer]

ok - that is the same cable i have but cannot for the life of me get it to work. jason, would u take a screen shot of the mprog screen and post it (i also used their new ft_prog utility). when i tried running the clean utility it wouldn't work. it wanted a PID. what did u use for that! i assume you tapped into the orange and yellow wires for the tx/rx respectively? i can do a loop back just fine! send the word hello and it will echo back hello. how do i test the voltage output? i.e. maybe i was sent a 3 volt one vs a 5 volt like i ordered. i bought this around 3 years ago already. when i have it hooked up i can use the various ftdi utilities and it will find it and enumerate it properly. as before, any help is appreciated. worst case i buy a new one.


****update****
giggling like a little girl!!! i finally made some progress on my 3 month old issue. turns out my HPTUNERS program i use to tune my camaro also uses ftdi for its usb cable connection. somehow there is a conflict. i uninstalled the hptuners stuff, then the ftclean program worked, reinstalled the driver, and i have progress. did some scanning with the unit. unfortunately at this point it just returns some weirdness but its at least responding. thank goodness!!
i'll keep u informed on the progress.

jason - I would still like a screen shot of your mprog/ftprog setup screen.

also, what did u, OR ANYBODY ELSE, set up for latency, transfer sizes etc in the device manager advanced screen?

[CSXRT4]

ok - that is the same cable i have but cannot for the life of me get it to work. jason, would u take a screen shot of the mprog screen and post it (i also used their new ft_prog utility). when i tried running the clean utility it wouldn't work. it wanted a PID. what did u use for that! i assume you tapped into the orange and yellow wires for the tx/rx respectively? i can do a loop back just fine! send the word hello and it will echo back hello. how do i test the voltage output? i.e. maybe i was sent a 3 volt one vs a 5 volt like i ordered. i bought this around 3 years ago already. when i have it hooked up i can use the various ftdi utilities and it will find it and enumerate it properly. as before, any help is appreciated. worst case i buy a new one.


****update****
giggling like a little girl!!! i finally made some progress on my 3 month old issue. turns out my HPTUNERS program i use to tune my camaro also uses ftdi for its usb cable connection. somehow there is a conflict. i uninstalled the hptuners stuff, then the ftclean program worked, reinstalled the driver, and i have progress. did some scanning with the unit. unfortunately at this point it just returns some weirdness but its at least responding. thank goodness!!
i'll keep u informed on the progress.

jason - I would still like a screen shot of your mprog/ftprog setup screen.

also, what did u, OR ANYBODY ELSE, set up for latency, transfer sizes etc in the device manager advanced screen?


glad to see you got it figured out too :)

The latency and everything I left standard. With ftclean I didnt put a PID in I just hit "clean system" and it worked, I rebooted and reinstalled the drivers that I got from FTDI's site. I wired the orange(USB-TX) to the SMEC-RX(pin-31), the yellow(USB-RX) to the SMEC-TX(pin-51) and the black to chassis ground, I used a stereo audio jack (female on the car side, male on the cable side) to make it a quick plug-and-play deal.
http://www.turbo-mopar.com/forums/attachment.php?attachmentid=18713&stc=1&d=1258432575


Also note that you have to have the key on or the engine running to start logging or it will give you the "unable to init serial comms" message

the weirdness you are seeing may be what im dealing with now also, that being what to scale everything to. Try doing this, set it up to log the "MAP" and start logging, open logworks and go to "channels-->configure channel-->MAP" and set it up like this.

http://www.turbo-mopar.com/forums/attachment.php?attachmentid=18711&stc=1&d=1258431213

Hit "ok", now set up a gauge or start a realtime log or something. Your "MAP" reading should look normal now. You have to set up scaling for everything you log, but you should only have to set it up once and then logworks will remember the scalings


I used risen's walk-through in the knowledge center to setup MProg, the only thing I did different is check the "invert TXD" and "invert RXD" boxes(risen said it has to be that way for the SMEC). Also when I checked the "use fixed serial number" it would check and everything but after I programmed it and read it back that box would be unchecked and it would be using the "serial number prefix" box again. It works with it like that though so whatev I guess lol

http://www.turbo-mopar.com/forums/attachment.php?attachmentid=18712&stc=1&d=1258432278

[risen]

Yes, it is T2. The cal is from FWD(Cindy).

Ok, I can't guarantee that the vendor cals will work because I don't know what the ram maps are. If they can tell you what year/model cal yours was based upon one of the maps included with the plugin might work. Or, if you want to ask them for the ram map (location of the RPM/MAP/TPS/etc variables) I can explain to you how to add them.

[risen]

giggling like a little girl!!! i finally made some progress on my 3 month old issue. turns out my HPTUNERS program i use to tune my camaro also uses ftdi for its usb cable connection. somehow there is a conflict. i uninstalled the hptuners stuff, then the ftclean program worked, reinstalled the driver, and i have progress. did some scanning with the unit. unfortunately at this point it just returns some weirdness but its at least responding. thank goodness!!
i'll keep u informed on the progress.

jason - I would still like a screen shot of your mprog/ftprog setup screen.

also, what did u, OR ANYBODY ELSE, set up for latency, transfer sizes etc in the device manager advanced screen?

So the program wouldn't open until you uninstalled that other software? Or did you have to do something else to get the plugin to pop up? It's certianly odd, but I don't know how I'm going to reproduce it so I hope this is a one-off. The plugin should just bomb out with an error screen if it can't use the serial port or change any of it's settings.

I've never had to change any of the settings in the advanced settings other than forcing a com port. I don't think it's going to matter much because the baud rate isn't very high and any relatively modern pc or netbook should be OK.


glad to see you got it figured out too :)

Also note that you have to have the key on or the engine running to start logging or it will give you the "unable to init serial comms" message


This will always be the case. The hep triggers the interrupt in the smec that the plugin uses to get data back.




I used risen's walk-through in the knowledge center to setup MProg, the only thing I did different is check the "invert TXD" and "invert RXD" boxes. Also when I checked the "use fixed serial number" it would check and everything but after I programmed it and read it back that box would be unchecked and it would be using the "serial number prefix" box again. It works with it like that though so whatev I guess lol


One of these days I'm going to do a much better job putting up a FTDI article in the kb. I swear. :)

The serial number checkbox issue is a bug of some sort in mprog, I believe. It's happened to me a few times but I can't seem to figure out why it doesn't always happen.

[CSXRT4]

Advance is 0-128deg
Individual knock retards are 0-128deg
Knock volts is 0-5v
O2 volts is 0-5v
rpm is 0-8192rpm
Speed is 0-1024mph
Coolant temp is (-200)-260F (the scale in most of the D-Cal table files is wrong)
Injector PW is 0-49152ms
MAP is (-14.7)-29.4psi (for 3-bar MAP sensors)
Boost Target is 0-44.1psi (for 3-bar MAP sensors) because Baro is added to it before it is compared to MAP
Baro is (-14.7)-29.4psi (same as MAP)

How can I log negative advance if it is 0-128deg scaling???

[CSXRT4]

This will always be the case. The hep triggers the interrupt in the smec that the plugin uses to get data back.


Yeah I noticed that if I flashed a new cal onto the ostrich and turned the key on it would not connect. But if I started it and then shut it off, I could just turn the key on (engine off) and it would connect :confused2:

I just figured all the variables and bits in the ram were empty since it hadn't done a program loop yet, but afterward everything had been written in the ram.



I've never had to change any of the settings in the advanced settings other than forcing a com port. I don't think it's going to matter much because the baud rate isn't very high and any relatively modern pc or netbook should be OK.


I noticed you talking in a thread about having a weird issue with initiating a connection and the first bit of data received was garble or something? Maybe this has something to do with the latency setting? Honda guys all set this to "1" to datalog

[TopDollar69]

The fwd p 89 stage 5 cal I just got is based on the 89 TII 16k file. I'm willing to bet all their 88-89 stuff is also based on the 89 TII factory calibration.

[risen]

Yeah I noticed that if I flashed a new cal onto the ostrich and turned the key on it would not connect. But if I started it and then shut it off, I could just turn the key on (engine off) and it would connect :confused2:

I just figured all the variables and bits in the ram were empty since it hadn't done a program loop yet, but afterward everything had been written in the ram.

I'm not sure why it would connect as it waits to see a successful reply from the 0x12 command first. I couldn't ever get my bench rig to reply unless it saw a hep signal.



I noticed you talking in a thread about having a weird issue with initiating a connection and the first bit of data received was garble or something? Maybe this has something to do with the latency setting? Honda guys all set this to "1" to datalog

You mean the problem with having to issue commands and read back the data 2x over? I don't think this is going to fix it because it happens when I use a serial port instead of a usb converter, but I'll take a look. What setting are they using? You can give me a link if it's easier.


The fwd p 89 stage 5 cal I just got is based on the 89 TII 16k file. I'm willing to bet all their 88-89 stuff is also based on the 89 TII factory calibration.

Well, that's one down :). If anyone gets the vendor cals to work please post here so others can make use of the plugin.

[ShelGame]

How can I log negative advance if it is 0-128deg scaling???

There is no negative advance. It's always 0-128deg. The MAP advance table is negative, but that value is added to the advance from RPM table - which is always positive. If the result happens to be negative, it gets forced to 0 before it is stored as the final advance. So, 0 is the smallest advance you could get.

[CSXRT4]

There is no negative advance. It's always 0-128deg. The MAP advance table is negative, but that value is added to the advance from RPM table - which is always positive. If the result happens to be negative, it gets forced to 0 before it is stored as the final advance. So, 0 is the smallest advance you could get.

ok that makes sense. That kinda puts a limitation on launch control "anti-lag". :( When tuning other cars I was able to make the biggest gains in maximum boost thresholds by bringing the timing down to the area of -10 degrees during launch control.

[lotsaboost]

At this point it's not that big a deal. I'm currently logging with the RPM converter. I will resume use of the plug-in once I start burning my own chips. Big, huge thanks.
Ok, I can't guarantee that the vendor cals will work because I don't know what the ram maps are.
I'm currently using this cable with the Logworks plug-in. Works fine.

Glad to know this cable works. I have the same one, but have yet to try it with LogWorks.
Carlos

[risen]

Oh, and lets see some logs or screenshots or even videos of logworks in action.

[ShelGame]

I'm sure it's a big no-no to even ask - but is there a way to use Logworks on a car WITHOUT a Innovate WB installed? I'd like to try this on my van, but I don't have the $$ for a WB for it right now...

[CSXRT4]

I'm sure it's a big no-no to even ask - but is there a way to use Logworks on a car WITHOUT a Innovate WB installed? I'd like to try this on my van, but I don't have the $$ for a WB for it right now...

I wish that was possible. Sometimes I want to log with just a plug-in and without hooking all the wideband stuff up but it wont let you. If you open logworks and dont connect to an innovate wideband it wont let you do anything except open logs to view and configure hardware :(



Oh, and lets see some logs or screenshots or even videos of logworks in action.
Heres the only log I have taken so far, the cal is completely fresh so no tuning is done at all (very lean in boost :eek:). This was just to test it out so I only have a handful of things being logged. Also I think my knock sensor is bad because it wasnt putting out any voltage at all really, I had to relocate it for the hybrid engine so im going to log it at various RPMs and set up a new knock curve in my cal.

http://www.turbo-mopar.com/forums/attachment.php?attachmentid=18738&stc=1&d=1258516781
I had to zip it because it wouldn't let me upload .log files

[risen]

I'm sure it's a big no-no to even ask - but is there a way to use Logworks on a car WITHOUT a Innovate WB installed? I'd like to try this on my van, but I don't have the $$ for a WB for it right now...

Yes you can. You an use the mts stim dll and ignore any of the data it puts out. LMK if you want further instructions on that. It's really just a matter of copying a .dll file around and that's it.

[CSXRT4]

Yes you can. You an use the mts stim dll and ignore any of the data it puts out. LMK if you want further instructions on that. It's really just a matter of copying a .dll file around and that's it.

Ok im definitely interested in how to do this also! Is this a work around that somebody figured out?? How do you do it?

[ShelGame]

Yes you can. You an use the mts stim dll and ignore any of the data it puts out. LMK if you want further instructions on that. It's really just a matter of copying a .dll file around and that's it.

Most definitely. I think maybe you walked me through it before, but I've forgotten. Would probably be a good topic to add to this discussion...

[risen]

Ok im definitely interested in how to do this also! Is this a work around that somebody figured out?? How do you do it?

Innovate released the sim dll to help people develop logworks plugins and apps that read from a MTS chain. I'd imagine that it's not officially supported but it was developed by Innovate. You change the .dll and logworks think's there's a really large mts chain attached to whatever com port you give it. The chain puts out semi-random data which you can just choose to ignore.


Most definitely. I think maybe you walked me through it before, but I've forgotten. Would probably be a good topic to add to this discussion...

Ok, here are the requirements.
1) you need a spare com port on your machine. This cannot be the same com port that you have your ECU connected to.
2) you need to replace the mts.dll in your logworks install directory with the one from the zip in this thread (make sure you save a copy of the original): http://www.innovatemotorsports.com/forums/showthread.php?t=5784&highlight=dll

Once you get the new .dll in place, start the plugin normally and connect it to the com port your ecu is on. Next, start logworks. On starting logworks point it to the open com port (the one where your ecu is *NOT* connected) and it should fire right up.

There are limits on the number of channels you can add with the sim dll in place (I believe it's 3). I recently botched my dev machine by trying to delete the simulated channels and nothing from the plugin would show up afterwards, so don't try and delete the sim channels. I have previously gone back and forth with the sim and regular dll and it seemed to work OK.

If you want to go back to logging with your wideband you just need to replace the sim dll with the original and it should all go back to normal.

LMK if something isn't clear

[lotsaboost]

In time. Getting new clutch in now.
lets see some logs or screenshots or even videos of logworks

BTW, love your sig. Gotta love the gold Omni's

Carlos

[CSXRT4]

Innovate released the sim dll to help people develop logworks plugins and apps that read from a MTS chain. I'd imagine that it's not officially supported but it was developed by Innovate. You change the .dll and logworks think's there's a really large mts chain attached to whatever com port you give it. The chain puts out semi-random data which you can just choose to ignore.



Ok, here are the requirements.
1) you need a spare com port on your machine. This cannot be the same com port that you have your ECU connected to.
2) you need to replace the mts.dll in your logworks install directory with the one from the zip in this thread (make sure you save a copy of the original): http://www.innovatemotorsports.com/forums/showthread.php?t=5784&highlight=dll

Once you get the new .dll in place, start the plugin normally and connect it to the com port your ecu is on. Next, start logworks. On starting logworks point it to the open com port (the one where your ecu is *NOT* connected) and it should fire right up.

There are limits on the number of channels you can add with the sim dll in place (I believe it's 3). I recently botched my dev machine by trying to delete the simulated channels and nothing from the plugin would show up afterwards, so don't try and delete the sim channels. I have previously gone back and forth with the sim and regular dll and it seemed to work OK.

If you want to go back to logging with your wideband you just need to replace the sim dll with the original and it should all go back to normal.

LMK if something isn't clear


Ok that is sweet, I did some hex editing on the mts.dll and dropped the number of sim channels down to 6. I have to go to work but when I get back home im going to see if I can get a couple more off. Ill post it up when im done with it :)

Thanks

[risen]

Ok that is sweet, I did some hex editing on the mts.dll and dropped the number of sim channels down to 6. I have to go to work but when I get back home im going to see if I can get a couple more off. Ill post it up when im done with it :)

Thanks

Nice. Did you run it under a debugger to figure out which addresses to edit?



Just as an update, I figured out what was wrong with my logworks install. Turns out there's nothing wrong with deleting the channels from logworks. You can't have more than 5 channels from the plugin or none of the channels will show up. I tested this 3 or 4x over tonight and was unable to get logworks to display more than 5 channels. I was trying to get all 6 inputs from my smecstim up on the logworks display and it wasn't having it, 5 channels is fine.

So if anyone is planning on using the sim dll, please be aware of this limitation. If you think it's not working, try with 1 channel first.

[CSXRT4]

Ok so my hex editing didnt work as well as I had thought :( :(

I was able to remove the channels and it worked by itself, but when I hooked up to the smec to log it wouldnt work :(




Just as an update, I figured out what was wrong with my logworks install. Turns out there's nothing wrong with deleting the channels from logworks. You can't have more than 5 channels from the plugin or none of the channels will show up. I tested this 3 or 4x over tonight and was unable to get logworks to display more than 5 channels. I was trying to get all 6 inputs from my smecstim up on the logworks display and it wasn't having it, 5 channels is fine.

So if anyone is planning on using the sim dll, please be aware of this limitation. If you think it's not working, try with 1 channel first.

How are you deleting channels in logworks(EDIT: Nevermind I found out that you can do this in logworks 2 but not 3)??? Really, 5 channels is plenty to tune with, this would be great for guys who dont have an innovate wideband as they could still use your plug-in to datalog pretty much everything except fuel

[jpcturbo]

How are you deleting channels in logworks(EDIT: Nevermind I found out that you can do this in logworks 2 but not 3)??? Really, 5 channels is plenty to tune with, this would be great for guys who dont have an innovate wideband as they could still use your plug-in to datalog pretty much everything except fuel

If I remember right it seems as a "Feature" logworks3 tries to configure the number of channels automatically from what it sees on the chain upon connection. Obviously it's not working in our application. So I just use logworks2.
SMEC/LM log can show up to 8 (or more if you want $$ lol) but you loose so much resolution. I seem to find myself logging with at most 4 to 5 channels.

[risen]

If I remember right it seems as a "Feature" logworks3 tries to configure the number of channels automatically from what it sees on the chain upon connection. Obviously it's not working in our application. So I just use logworks2.
SMEC/LM log can show up to 8 (or more if you want $$ lol) but you loose so much resolution. I seem to find myself logging with at most 4 to 5 channels.

I think the limitation in logworks is only with the sim .dll. I have a log from my CSX somewhere with around 10 channels + wideband output in it and I don't think there's any limit with 'real' hardware.

You actually have to have all the channels opened in the plugin before logworks starts so it's not a big deal that it checks upon startup. I don't think there's an easy way to go and remove channels but you may be able to add them on the fly. Adding them on the fly wasn't something I felt like dealing with (synchronization issues between threads, etc).

Although, when I was logging many items, I quickly came to the realization you have above. Too many channels quickly makes the logs worthless due to the resolution loss.

[CSXRT4]

Hey im going to be doing some tuning today, do you guys know what the scalings are for the autocal cells and the "current autocal cell"?

[risen]

Hey im going to be doing some tuning today, do you guys know what the scalings are for the autocal cells and the "current autocal cell"?

I don't know off the top of my head, but I believe they're in 'kicks'. There's a couple threads around here about the o2 strategy that might give you more info. Rob understands that whole thing a lot better than I do, so you may have to wait for him to get a real good idea of what it represents.

[ShelGame]

I don't know off the top of my head, but I believe they're in 'kicks'. There's a couple threads around here about the o2 strategy that might give you more info. Rob understands that whole thing a lot better than I do, so you may have to wait for him to get a real good idea of what it represents.

Yeah, I've done the math on them, but I must be missing somethign becuase I get 200% correction and such - which obviously isn't right. I've got to go thru it again and figure out the scaling. But, it's definitely in % and the adaptive cells are signed...

[dan_j_b]

I got this all working in my car and am currently logging boost, coolant temp, RPM and MPH in addition to the wideband. It all works pretty well, but I noticed some strange spikes in the log. is there something in the baud rate I need to change to fix this?

http://i45.tinypic.com/2450p07.jpg

Here are the values I am using in the custom lookup tables in logworks3:
(second number is volts)

MPH
0 - 0
75 - 0.375
150 - 0.75

RPM
500 - 0.167
3000 - 1
7000 - 2.331

Boost
-28.5 - 0.078
0.7 - 1.719
30 - 5

Coolant Temp
250 - 1.45
240 - 1.62
230 - 1.8
220 - 2
210 - 2.2
200 - 2.4
190 - 2.6
180 - 2.8
170 - 3.02
160 - 3.2
150 - 3.4
140 - 3.6
130 - 3.7
120 - 4
110 - 4.2

[ShelGame]

FYI, -28.5psi defies the laws of math and physics. -14.7psi is a perfect vacuum...

[dan_j_b]

Yeah, I chose those 3 values from a long list of values covering the entire range of the 3-bar. I used the 2 extremes and one near 0 and judging by my autometer gauge, it looks to be acurate.

[risen]

I got this all working in my car and am currently logging boost, coolant temp, RPM and MPH in addition to the wideband. It all works pretty well, but I noticed some strange spikes in the log. is there something in the baud rate I need to change to fix this?

I have a couple of questions to sort out the bad values:

Are you using a USB converter or a regular serial port?
Have you changed the baud rates from the defaults?
Can you give me the specs on your laptop (hw speed/os version)?
If you want to dig further into it, you can run a program called portmon to watch the serial transfers. I can give you instructions and you can send me the output.


Yeah, I chose those 3 values from a long list of values covering the entire range of the 3-bar. I used the 2 extremes and one near 0 and judging by my autometer gauge, it looks to be acurate.

Your guage is likely in inches of hg on the vacuum side, not negative psi.

[dan_j_b]

I am using the usb-txrx-g usb-ttl interface from the knowledgebase on my 87 LM. I haven't changed the baud rates. The laptop is a 1.6GHz centrino 512mb ram windows xp pro sp3. I downloaded portmon, I will run it next time I log. If theres anything special I need to know about that, let me know. Yeah the gauge measures vac in inches HG. Should I change my boost table to only the values above 0?

[risen]

I am using the usb-txrx-g usb-ttl interface from the knowledgebase on my 87 LM. I haven't changed the baud rates. The laptop is a 1.6GHz centrino 512mb ram windows xp pro sp3. I downloaded portmon, I will run it next time I log. If theres anything special I need to know about that, let me know. Yeah the gauge measures vac in inches HG. Should I change my boost table to only the values above 0?

You just need to make sure that portmon is only set to monitor the serial port you have the ecu connected to and have it log to a file. Also, you can stop logging to the screen if you don't want to waste cpu or aren't going to watch it. You can send me the portmon log afterwards, it would also help if you can send me the logworks session, too. Your laptop is about the same as my dev machine, so it's got enough juice.

I think it's up to you how you want to handle the mapping, you just need to be aware of what the value represents. I normally just set 0=-14.7 and 255 to 30.0 and let it be a linear scale. It's a little more straightforward of a mapping and is easier to use when you adjust stuff in dcal/chem.

[risen]

For those interested in performance numbers I did some testing tonight and I get around 33 samples/s. So, total time is around 33 ms/sample. By way of comparison, this is almost 3x the rate a lc1 is sampled at. From what I've seen on innovate's site their serial protocol updates at 12.2 hz.

Maybe I'll be able to figure out how to get it to run faster in the future but I'd need to understand exactly what it takes to get the smec to respond to my query on the 1st try every time. The limit is seems to be around 15 ms/sample since that's how long it takes the smec to send a response to a single query (correct or incorrect).

[ShelGame]

Actually, I just looked at the TOC1 interrupt code again. The timer compare it uses is actually variable, but the min interval is 32.3ms. Which corresponds nearly exactly to 33 samples/sec. The variable compare time is also possibly to blame for the unreliable byte reads. I don't really understand the variable timer purpose. I'll have to look into it more. Regardles of why, it doesn't look like we can get more than 33 samples/sec (total) from the 0x12 DRB protocol.

[risen]

Actually, I just looked at the TOC1 interrupt code again. The timer compare it uses is actually variable, but the min interval is 32.3ms. Which corresponds nearly exactly to 33 samples/sec. The variable compare time is also possibly to blame for the unreliable byte reads. I don't really understand the variable timer purpose. I'll have to look into it more. Regardles of why, it doesn't look like we can get more than 33 samples/sec (total) from the 0x12 DRB protocol.

So is it actually set to compare to TOC1A/B/C or does it compare to some other variable in memory in the interrupt somewhere (like an overflow counter)?

From what I can tell, It seems like the smec I have always spits back a response every 15 ms. Maybe this is due to a mismatch between the speed at which the serial tx routine runs and the speed at which the new 0x12 value is loaded? I guess I should be pretty happy with myself for getting it so close to the limit :)

However, in the quest to make it faster, if the interrupt is run on a timer compare match, couldn't we reset the compare value each time it's run? Or is the granularity of the timer such that each tick is 32 ms? I suppose we'd need to make sure it wouldn't cause too heavy an interrupt load if it was possible.

[wowzer]

i vote for either a new routine or just use the high speed logger! it is such a simple routine to use and i was getting more than 600 bytes/sec at 9600 baud. the only downside (as mentioned before) was a strange blip (every 5 or 10 seconds) but still so much better than the drb crap.

[ShelGame]

The only problem is, the high-speed logger routine will not work on the SBEC without some major re-work. The SBEC already has a serial interrupt routine. That would have to be replaced, or at least have a command parser added so that it can have 2 modes - normal and logger. But, it's possible...

[wowzer]

For those interested in performance numbers I did some testing tonight and I get around 33 samples/s. So, total time is around 33 ms/sample. By way of comparison, this is almost 3x the rate a lc1 is sampled at. From what I've seen on innovate's site their serial protocol updates at 12.2 hz.

Maybe I'll be able to figure out how to get it to run faster in the future but I'd need to understand exactly what it takes to get the smec to respond to my query on the 1st try every time. The limit is seems to be around 15 ms/sample since that's how long it takes the smec to send a response to a single query (correct or incorrect).

on what platform? smec t1, smec t2, (or lm)

[wowzer]

For those interested in performance numbers I did some testing tonight and I get around 33 samples/s. So, total time is around 33 ms/sample. By way of comparison, this is almost 3x the rate a lc1 is sampled at. From what I've seen on innovate's site their serial protocol updates at 12.2 hz.

Maybe I'll be able to figure out how to get it to run faster in the future but I'd need to understand exactly what it takes to get the smec to respond to my query on the 1st try every time. The limit is seems to be around 15 ms/sample since that's how long it takes the smec to send a response to a single query (correct or incorrect).

as a followup, using the drb II protocol, MPScan, hi baud = 9600, 15 bytes per sample, i was getting a throughput of 25 bytes/sec. i didn't try different sample sizes but as noted i doubt i'll get much more speed. comparatively, i got over 600 bytes/sec at 9600 baud using the high speed logger! just food for thought. seems like it would be a better use of effort to look at something other than the drb stuff, at least for the lm and smec

[risen]

on what platform? smec t1, smec t2, (or lm)

88 t2 smec. I really need to get a LM on the bench for testing. Eventually I'll socket the smec so I can try different cals.


as a followup, using the drb II protocol, MPScan, hi baud = 9600, 15 bytes per sample, i was getting a throughput of 25 bytes/sec. i didn't try different sample sizes but as noted i doubt i'll get much more speed. comparatively, i got over 600 bytes/sec at 9600 baud using the high speed logger! just food for thought. seems like it would be a better use of effort to look at something other than the drb stuff, at least for the lm and smec

Well, I guess if there's a need for that level of resolution then I can try and support it in a future version of the plugin. I'd just ask that whatever upgraded routine is used, that it's consistent across the various ecu types.

Still, 33 samples/s isn't that bad unless you have something that only happens at 7500 rpm.

[wowzer]

i agree. as far as the innovative stuff that resolution is probably ok. for my purposes with MPScan i may need to log up to 24 addresses at a time. so that would limit me to 1 to 2 samples per second so i need quite a bit more resolution. also, looking at the real time update stuff that rob's module (hopefully) will support. i know my hptuner software works best (based on ecu) at 10 samples per second, with each sample being 24 bytes.

i just looked at your sim stuff again. that is so cool. can't wait to get my hands on it.

[cs daytona]

Well i finally got my lc1 hooked up last night, and after work today i was messing with the logworks 3 with the plugin. Awesome work!! I love it, but the its a p.i.t.a. That i have to enter the values everytime i start the plugin and lw3. I just to confirm that the lw3 works flawlessly (for me, at least). Has anybody had luck with saving the channel configurations so i dont have to run that dumb wizard? I saved the channel configuration but once i exit the plugin, everythings lost again. Otherwise, its great!

Travis

[risen]

Well i finally got my lc1 hooked up last night, and after work today i was messing with the logworks 3 with the plugin. Awesome work!! I love it, but the its a p.i.t.a. That i have to enter the values everytime i start the plugin and lw3. I just to confirm that the lw3 works flawlessly (for me, at least). Has anybody had luck with saving the channel configurations so i dont have to run that dumb wizard? I saved the channel configuration but once i exit the plugin, everythings lost again. Otherwise, its great!

Travis

The plugin should retain it's settings after you hit the 'start' button. The plugin does retain which channels you have checked, correct?

I don't think I did anything special for logworks3 to make it save the config. Every time I start it up I hit cancel on the configuration of the logging chain (I believe this is the wizard you mentioned) and it pops up the last screen I had setup with the scaling and everything.

I haven't used it in-car yet, but I don't think there should be any difference.

[cs daytona]

your plugin saves everything just fine. the channel configuration in logworks3 is what was not saving automatically. but now i was going to reply that i have to load the configurations from a saved file everytime i start the lw3 with the plugin, which is not bad now that i found where i needed to go to load the channel config file. the users manual comes in handy sometimes hehe. so now that being said, i dont have any complaints. just love. thanks for the program!

travis

[TFmech]

Hey does anyone have the stim mts.dll file to make logworks work with out the LC-1. Inovates forum has said it is in transition forever now and I was wanting to see if this thing will work like it should. If someone could email it to me at kris@claymillican.com that would be great.

Thanks,
Kris

[Stratman]

I planned to play with this Friday, but UPS dropped the FTDI cable off at wrong business address.....:mad:

Got to play tonight though!:)
Thank you very much for this plugin!!!!! This has been a fantasy since 2004....logged for 30 min with no drops outs.
The ignition timing reads 31 deg adv at idle in Logworks, but the OTC scanner reads about 18 deg adv at idle. IPW eems to be right. I did choose the 89 T1 TSMEC which is correct for what I am running. Would there be a difference between the scanner and the scale of the plugin?

EDIT: If I stop the scan, I have to close the plugin and open it again or it gets stuck at initializing logworks(?).

EDITx2: Sorry, reread the first post about restarting plugin.

[risen]

I planned to play with this Friday, but UPS dropped the FTDI cable off at wrong business address.....:mad:

Got to play tonight though!:)
Thank you very much for this plugin!!!!! This has been a fantasy since 2004....logged for 30 min with no drops outs.
The ignition timing reads 31 deg adv at idle in Logworks, but the OTC scanner reads about 18 deg adv at idle. IPW eems to be right. I did choose the 89 T1 TSMEC which is correct for what I am running. Would there be a difference between the scanner and the scale of the plugin?

Glad to hear it worked well for you.

As to the advance, I'm not 100% sure what the issue is there, it's been a long time since I looked at it though. I don't believe that there's any translation currently being done by the plugin, so you may have to map it. There's a thread around here where Rob mentions exactly what the format of the advance variable is (as it's a signed value), but I can't seem to recall what thread it was.



EDIT: If I stop the scan, I have to close the plugin and open it again or it gets stuck at initializing logworks(?).

EDITx2: Sorry, reread the first post about restarting plugin.

Unfortunately I haven't found a way around that issue yet and I don't know that I will be able to.

[Stratman]

Thanks. Maybe Rob can chime in with his knowledge of scaling.

[ShelGame]

Advance is not signed, but the scale is 0-127degrees. So, if you get a 'raw' reading of 31, that's actually 15.5 deg.

[Stratman]

Advance is not signed, but the scale is 0-127degrees. So, if you get a 'raw' reading of 31, that's actually 15.5 deg.

Thank you Rob. Is there other documented scales? It seems it should be easy enough to go by table scaling in the cal. Correct?

Which address should I check if I wanted to log fuel trim or adaptives? I was playing with the autocal addresses and CAC this morning, but there are so many I could make heads or tails which one to watch. CAC was logging zero.

[ShelGame]

Most of the scales are documented in T-SMEC. You can just copy them from the template or from the .tbl file after it's compiled.

For the 2.5 cals, or T-SMEC, the autocal values are from 0x0F to 0x1B. Basically, they are mapped like this:



AutoCalCell0 == 0x000F
AutoCalCell1 == 0x0010
AutoCalCell2 == 0x0011
AutoCalCell3 == 0x0012
AutoCalCell4 == 0x0013
AutoCalCell5 == 0x0014
AutoCalCell6 == 0x0015
AutoCalCell7 == 0x0016
AutoCalCell8 == 0x0017
AutoCalCell9 == 0x0018
AutoCalCell10 == 0x0019
AutoCalCell11 == 0x001A
AutoCalCell12idle == 0x001B


*****************************************
; Auto Cal Factors Table
; *****************************************
;
; closed throttle = cell 12, otherwise:
; $ff
; +-----+-----+-----+-----+-----+-----+
; | 1 | 3 | 5 | 7 | 9 | 11 |
; R1 +-----+-----+-----+-----+-----+-----+
; | 0 | 2 | 4 | 6 | 8 | 10 |
; rpm^ +-----+-----+-----+-----+-----+-----+
; map> MP1 MP2 MP3 MP4 MP5 $ff
;
; *****************************************


Where R1 and MP1-5 are the Map cell boundaries as defined in the cal data (template).

Also, there are these 2:


PointerIntoAdaptiveMemory == 0x008A
ValueFromAdaptiveMemory == 0x008B


The pointer is the active autocal cell cell above (0-12), and the value should be a copy of the value in that cell. Though, there may be some discrepancy when it's updating.

The scale of the autocal factors is in signed %. So, it goes from -25% to +25%.

[risen]

Advance is not signed, but the scale is 0-127degrees. So, if you get a 'raw' reading of 31, that's actually 15.5 deg.

Ahhh. Thanks for clearing that up. My memory isn't so great lately it seems.

[Stratman]

I logged address 8B yesterday which seems to be fuel correction factor I want to log for fine tuning. I scaled it -25 to +25 in Logworks. When I stopped at a light with no throttle it slowly maxed out at +25 and would basically go off chart and immediately jump strait to -25 and climb from there to -14 and settle.

Spark timing now looks correct at 0-127 scale.

[ShelGame]

It's a signed variable. Not sure if Logworks can deal with that. Sounds like no.

Basically, values from 00-0f are positive, and values from 10-FF are negative; in 2's complement form.

[risen]

It's a signed variable. Not sure if Logworks can deal with that. Sounds like no.

Basically, values from 00-0f are positive, and values from 10-FF are negative; in 2's complement form.

The plugin just shovels the byte it received back over to logworks, it's up to logworks to interpert it. I believe logworks 3 will let you build a table to do that translation.
I can build the table and post it if anyone wants to try it.

[Stratman]

The plugin just shovels the byte it received back over to logworks, it's up to logworks to interpert it. I believe logworks 3 will let you build a table to do that translation.
I can build the table and post it if anyone wants to try it.

:wave1: me..me..me..I'll try it since I'm playing with it anyway.

[risen]

:wave1: me..me..me..I'll try it since I'm playing with it anyway.

Here, give this a try. Left hand column should be x (input) right hand column is y (output):


0,0
1,1
2,2
3,3
4,4
5,5
6,6
7,7
8,8
9,9
10,10
11,11
12,12
13,13
14,14
15,15
16,16
17,17
18,18
19,19
20,20
21,21
22,22
23,23
24,24
25,25
26,26
27,27
28,28
29,29
30,30
31,31
32,32
33,33
34,34
35,35
36,36
37,37
38,38
39,39
40,40
41,41
42,42
43,43
44,44
45,45
46,46
47,47
48,48
49,49
50,50
51,51
52,52
53,53
54,54
55,55
56,56
57,57
58,58
59,59
60,60
61,61
62,62
63,63
64,64
65,65
66,66
67,67
68,68
69,69
70,70
71,71
72,72
73,73
74,74
75,75
76,76
77,77
78,78
79,79
80,80
81,81
82,82
83,83
84,84
85,85
86,86
87,87
88,88
89,89
90,90
91,91
92,92
93,93
94,94
95,95
96,96
97,97
98,98
99,99
100,100
101,101
102,102
103,103
104,104
105,105
106,106
107,107
108,108
109,109
110,110
111,111
112,112
113,113
114,114
115,115
116,116
117,117
118,118
119,119
120,120
121,121
122,122
123,123
124,124
125,125
126,126
127,127
128,-128
129,-127
130,-126
131,-125
132,-124
133,-123
134,-122
135,-121
136,-120
137,-119
138,-118
139,-117
140,-116
141,-115
142,-114
143,-113
144,-112
145,-111
146,-110
147,-109
148,-108
149,-107
150,-106
151,-105
152,-104
153,-103
154,-102
155,-101
156,-100
157,-99
158,-98
159,-97
160,-96
161,-95
162,-94
163,-93
164,-92
165,-91
166,-90
167,-89
168,-88
169,-87
170,-86
171,-85
172,-84
173,-83
174,-82
175,-81
176,-80
177,-79
178,-78
179,-77
180,-76
181,-75
182,-74
183,-73
184,-72
185,-71
186,-70
187,-69
188,-68
189,-67
190,-66
191,-65
192,-64
193,-63
194,-62
195,-61
196,-60
197,-59
198,-58
199,-57
200,-56
201,-55
202,-54
203,-53
204,-52
205,-51
206,-50
207,-49
208,-48
209,-47
210,-46
211,-45
212,-44
213,-43
214,-42
215,-41
216,-40
217,-39
218,-38
219,-37
220,-36
221,-35
222,-34
223,-33
224,-32
225,-31
226,-30
227,-29
228,-28
229,-27
230,-26
231,-25
232,-24
233,-23
234,-22
235,-21
236,-20
237,-19
238,-18
239,-17
240,-16
241,-15
242,-14
243,-13
244,-12
245,-11
246,-10
247,-9
248,-8
249,-7
250,-6
251,-5
252,-4
253,-3
254,-2
255,-1

[Stratman]

In Logworks under Configure channel>custom lookup table there is a "raw" column and "volts" column. Raw seems to be output and volts 0-5 volts input. I tried to load this scale as a txt, but it didn't work right. Do you have a suggestion on loading this into Logworks?

[risen]

In Logworks under Configure channel>custom lookup table there is a "raw" column and "volts" column. Raw seems to be output and volts 0-5 volts input. I tried to load this scale as a txt, but it didn't work right. Do you have a suggestion on loading this into Logworks?

Can you change the input of the channel to be something other than volts? I thought there were some options as to what the channel represents. I'll look tomorrow.

[Stratman]

You have a choice of different output options as this channel is set at "raw", but "volts" (0-5 volts) seems to be the main input and I have not been able to change this.

On another note, let me ask about the baud rate for logging. I am using the original DRBII baud which is a rather low sample rate when logging 10 addresses. I know this has been covered somewhere, is there any way to communicate faster with the SMEC other than logging less addresses?

[risen]

You have a choice of different output options as this channel is set at "raw", but "volts" (0-5 volts) seems to be the main input and I have not been able to change this.

Well, we could get really dirty and I could translate those 0-255 values to be 0-5v values to see logworks likes that better. It's not that hard, I have a script that generates the table, so it's very little work for me, so if you'd like to try that LMK. I haven't had a chance to look at logworks yet.




On another note, let me ask about the baud rate for logging. I am using the original DRBII baud which is a rather low sample rate when logging 10 addresses. I know this has been covered somewhere, is there any way to communicate faster with the SMEC other than logging less addresses?

The baud rate isn't really the limiting factor. If you're using the 62.5k high rate it's good to around 8000 1 byte returns each second. Way more than you're likely to be able to get from the ECU. The big problem is how how fast the SMEC/SBEC can reply to your request. There was some discussion about the additional latency introduced by the DLP adapter (it's actually in the FTDI chip that's on the adapter). I can give you a setting to try and tweak to see if it brings it up faster than 33s/sec. It's a simple setting that you can change in windows control panel and if it doesn't work you can ignore it or change it back.

[Stratman]

Well, we could get really dirty and I could translate those 0-255 values to be 0-5v values to see logworks likes that better. It's not that hard, I have a script that generates the table, so it's very little work for me, so if you'd like to try that LMK. I haven't had a chance to look at logworks yet.

This would definitely be worth a try. Is this a change in the SMEC code or plugin?


The baud rate isn't really the limiting factor. If you're using the 62.5k high rate it's good to around 8000 1 byte returns each second. Way more than you're likely to be able to get from the ECU. The big problem is how how fast the SMEC/SBEC can reply to your request. There was some discussion about the additional latency introduced by the DLP adapter (it's actually in the FTDI chip that's on the adapter). I can give you a setting to try and tweak to see if it brings it up faster than 33s/sec. It's a simple setting that you can change in windows control panel and if it doesn't work you can ignore it or change it back.

Do I just need to change the buffer latency in the com port in device manager? Would be easy enough.

[vprtech]

This would definitely be worth a try. Is this a change in the SMEC code or plugin?



Do I just need to change the buffer latency in the com port in device manager? Would be easy enough.

It appears that these ecu's are capable sending data quite a bit faster than previously thought. There may be a limit to how many times the ecu will update a ram location in a given time, but that is still in the neighborhood of at least thirty updates per second per byte, while polling around twelve bytes. So , assuming you were logging twenty bytes, you would be well above twelve updates per second , per byte cap, which is the limit of logworks.

[risen]

This would definitely be worth a try. Is this a change in the SMEC code or plugin?

No, it would be in logworks. I'm thinking of giving you another table that has something like


0.0,0
1.25,64
2.5,127

Do you want to try that? There might be something I can do in the plugin, but it's been a while since I looked at the code for the plugin, so it won't be quick (or right the 1st time, most likely).


Do I just need to change the buffer latency in the com port in device manager? Would be easy enough.
Exactly. If you go to the device manager and right-click the com port and go to advanced you can select 1ms for the timeout in the properties. You can try and bring the listing packet sizes down to 64 bytes, too (that probably won't have any effect). If you don't see those options LMK and I'll get a screenshot later on.


It appears that these ecu's are capable sending data quite a bit faster than previously thought. There may be a limit to how many times the ecu will update a ram location in a given time, but that is still in the neighborhood of at least thirty updates per second per byte, while polling around twelve bytes. So , assuming you were logging twenty bytes, you would be well above twelve updates per second , per byte cap, which is the limit of logworks.

While it may be capable of sending a value stored in ram out the serial port more than 33 times/s there won't be any limit on how fast the cpu updates any given ram location. In reality there is a hard cap, but it's limited by the CPU's clock (4 or 8mhz iirc) and by how many cycles it takes to write the data back from a register to the ram. I could write a program that increments a register and writes it back to a ram location, and that could easily be done 500k or 1m times in one second. Which would essentially look like no limit to you if you were to attempt to log it with logworks or something.

Now, as a practical matter, if there's a location that ever sees an update rate > 33 times/s that would depend on the code and (likely) how fast you're turning your engine. I'm not sure if the timers are mapped into memory, but we could always try logging those as I'd be surprised if they ticked more slowly than 33hz.

[Stratman]

The logs are a bit more smooth with the latency change. It is fast enough now I can actually see the knock logging when it occurs with 10 addresses logging. I previously had the same latency issue with my usb to serial converter in the past making read/writes very slow to the old Romulator.


No, it would be in logworks. I'm thinking of giving you another table that has something like
Code:

0.0,0
1.25,64
2.5,127

Which column of values would fall under the "volt" category?

[risen]

The logs are a bit more smooth with the latency change. It is fast enough now I can actually see the knock logging when it occurs with 10 addresses logging. I previously had the same latency issue with my usb to serial converter in the past making read/writes very slow to the old Romulator.

That's actually great news. Have you, by chance, ever used portmon for windows? If not, no biggie. If you have, and you have the time, could you get a 30s portmon log with the latency set low on the adapter while you're datalogging?



Which column of values would fall under the "volt" category?
The left column would be the volts. I can give you the full table if you'd like.

[Stratman]

That's actually great news. Have you, by chance, ever used portmon for windows? If not, no biggie. If you have, and you have the time, could you get a 30s portmon log with the latency set low on the adapter while you're datalogging?
Yes, I used to run PortMon religiously when I had issues. I guess you want the plugin com port logged in PortMon?



The left column would be the volts. I can give you the full table if you'd like.

Yes, I'll try an new table.

[risen]

Yes, I used to run PortMon religiously when I had issues. I guess you want the plugin com port logged in PortMon?

Yes, please.



Yes, I'll try an new table.

OK, I'll post it later today.

[Stratman]

http://www.turbofreak.com/1ms_pluginlog_10_addies.LOG
1ms latency with 10 addresses logged.

http://www.turbofreak.com/16ms_pluginlog_10_addies.LOG
16ms latency with 10 addresses logged.

I screwed up and selected clock time. Hopefully this gives you enough info.

[Stratman]

I just got a look at the com logs. 1ms 603 lines per sec, 16ms 73 lines per sec. Looks significant.

[risen]

http://www.turbofreak.com/1ms_pluginlog_10_addies.LOG
1ms latency with 10 addresses logged.

http://www.turbofreak.com/16ms_pluginlog_10_addies.LOG
16ms latency with 10 addresses logged.

I screwed up and selected clock time. Hopefully this gives you enough info.

Thanks for taking the time to do that. I owe you a beer if you're ever up here in the NE (since I'll probably never end up in Dallas, lol). I'll sort out the subtraction but I should be able to tell pretty quickly how big an improvement it made.

Here's your table. I looked at logworks a little, but I haven't had time to really mess with it lately, I didn't even load the table in yet :(. If it doesn't work on your first try LMK and I'll find a way to get the table to load tomorrow at lunch.


0.0000,0
0.0195,1
0.0391,2
0.0586,3
0.0781,4
0.0976,5
0.1172,6
0.1367,7
0.1562,8
0.1758,9
0.1953,10
0.2148,11
0.2344,12
0.2539,13
0.2734,14
0.2929,15
0.3125,16
0.3320,17
0.3515,18
0.3711,19
0.3906,20
0.4101,21
0.4297,22
0.4492,23
0.4687,24
0.4882,25
0.5078,26
0.5273,27
0.5468,28
0.5664,29
0.5859,30
0.6054,31
0.6250,32
0.6445,33
0.6640,34
0.6836,35
0.7031,36
0.7226,37
0.7421,38
0.7617,39
0.7812,40
0.8007,41
0.8203,42
0.8398,43
0.8593,44
0.8789,45
0.8984,46
0.9179,47
0.9374,48
0.9570,49
0.9765,50
0.9960,51
1.0156,52
1.0351,53
1.0546,54
1.0742,55
1.0937,56
1.1132,57
1.1327,58
1.1523,59
1.1718,60
1.1913,61
1.2109,62
1.2304,63
1.2499,64
1.2695,65
1.2890,66
1.3085,67
1.3280,68
1.3476,69
1.3671,70
1.3866,71
1.4062,72
1.4257,73
1.4452,74
1.4648,75
1.4843,76
1.5038,77
1.5233,78
1.5429,79
1.5624,80
1.5819,81
1.6015,82
1.6210,83
1.6405,84
1.6601,85
1.6796,86
1.6991,87
1.7186,88
1.7382,89
1.7577,90
1.7772,91
1.7968,92
1.8163,93
1.8358,94
1.8554,95
1.8749,96
1.8944,97
1.9139,98
1.9335,99
1.9530,100
1.9725,101
1.9921,102
2.0116,103
2.0311,104
2.0507,105
2.0702,106
2.0897,107
2.1092,108
2.1288,109
2.1483,110
2.1678,111
2.1874,112
2.2069,113
2.2264,114
2.2460,115
2.2655,116
2.2850,117
2.3045,118
2.3241,119
2.3436,120
2.3631,121
2.3827,122
2.4022,123
2.4217,124
2.4413,125
2.4608,126
2.4803,127
2.4998,-128
2.5194,-127
2.5389,-126
2.5584,-125
2.5780,-124
2.5975,-123
2.6170,-122
2.6366,-121
2.6561,-120
2.6756,-119
2.6951,-118
2.7147,-117
2.7342,-116
2.7537,-115
2.7733,-114
2.7928,-113
2.8123,-112
2.8319,-111
2.8514,-110
2.8709,-109
2.8904,-108
2.9100,-107
2.9295,-106
2.9490,-105
2.9686,-104
2.9881,-103
3.0076,-102
3.0272,-101
3.0467,-100
3.0662,-99
3.0857,-98
3.1053,-97
3.1248,-96
3.1443,-95
3.1639,-94
3.1834,-93
3.2029,-92
3.2225,-91
3.2420,-90
3.2615,-89
3.2810,-88
3.3006,-87
3.3201,-86
3.3396,-85
3.3592,-84
3.3787,-83
3.3982,-82
3.4178,-81
3.4373,-80
3.4568,-79
3.4763,-78
3.4959,-77
3.5154,-76
3.5349,-75
3.5545,-74
3.5740,-73
3.5935,-72
3.6131,-71
3.6326,-70
3.6521,-69
3.6716,-68
3.6912,-67
3.7107,-66
3.7302,-65
3.7498,-64
3.7693,-63
3.7888,-62
3.8084,-61
3.8279,-60
3.8474,-59
3.8669,-58
3.8865,-57
3.9060,-56
3.9255,-55
3.9451,-54
3.9646,-53
3.9841,-52
4.0037,-51
4.0232,-50
4.0427,-49
4.0622,-48
4.0818,-47
4.1013,-46
4.1208,-45
4.1404,-44
4.1599,-43
4.1794,-42
4.1990,-41
4.2185,-40
4.2380,-39
4.2575,-38
4.2771,-37
4.2966,-36
4.3161,-35
4.3357,-34
4.3552,-33
4.3747,-32
4.3943,-31
4.4138,-30
4.4333,-29
4.4528,-28
4.4724,-27
4.4919,-26
4.5114,-25
4.5310,-24
4.5505,-23
4.5700,-22
4.5895,-21
4.6091,-20
4.6286,-19
4.6481,-18
4.6677,-17
4.6872,-16
4.7067,-15
4.7263,-14
4.7458,-13
4.7653,-12
4.7848,-11
4.8044,-10
4.8239,-9
4.8434,-8
4.8630,-7
4.8825,-6
4.9020,-5
4.9216,-4
4.9411,-3
4.9606,-2
4.9801,-1
4.9997,0

[risen]

I just got a look at the com logs. 1ms 603 lines per sec, 16ms 73 lines per sec. Looks significant.

I didn't realize that the wall clock time removed the fractional seconds :( . Now I realize what you meant above. I was pretty sure that when you noticed a difference that it must've been significant, but it's almost 10x. Even the difference in the amount of time it took me to download the 2 logs is enough to make me think that the latency setting made a *serious* improvement. I'm going to pump it through gnuplot tomorrow.

Once I get the knock board off my plate (maybe 1st week of Sep) I'm going to revisit the plugin while testing my new stim. I should be able to remove more overhead from the plugin and make things a little more efficient. This makes 1 more thing to add to the USB adatper article I have to re-write for the KB. Maybe I'll even get to update that much-neglected winlog plugin.

[Stratman]

I didn't realize that the wall clock time removed the fractional seconds :( . Now I realize what you meant above. I was pretty sure that when you noticed a difference that it must've been significant, but it's almost 10x. Even the difference in the amount of time it took me to download the 2 logs is enough to make me think that the latency setting made a *serious* improvement. I'm going to pump it through gnuplot tomorrow.
When I ran the DB9 driven Romulator on the usb to serial converter the first week, it took 30 seconds or more to update 32 kb bin file which drove me nuts. Then I found the latency value, changed to 1ms from the default 16ms, and it would update a 32 kb bin in around 10 secs.
Unfortunately, it still wasn't as fast updating the Romulator when it was connected directly to a DB9 port (not using the converter). Strait to the laptop DB9 it would update in less than 4 seconds. I could not find any way to make the unit run faster using the converter.

For some reason I could never get the 3 different DB9 RS232 units I own to communicate to the SMEC or my LM. If I can get that to work it should be ridiculously more responsive. Now I know the signal is supposed to be inverted maybe I can somehow get the DB9 RS232 converters to work for testing, but since I only have one DB9 port on the laptop, that means my LM-1 will have to be hooked up to serial converter which makes the wideband log slower.


Once I get the knock board off my plate (maybe 1st week of Sep) I'm going to revisit the plugin while testing my new stim. I should be able to remove more overhead from the plugin and make things a little more efficient. This makes 1 more thing to add to the USB adatper article I have to re-write for the KB. Maybe I'll even get to update that much-neglected winlog plugin.

I need to get a knock board for my Supra!
Is your new stim the JimStim? That board is really nice for testing.
Where are your articles located?

[risen]

When I ran the DB9 driven Romulator on the usb to serial converter the first week, it took 30 seconds or more to update 32 kb bin file which drove me nuts. Then I found the latency value, changed to 1ms from the default 16ms, and it would update a 32 kb bin in around 10 secs.
Unfortunately, it still wasn't as fast updating the Romulator when it was connected directly to a DB9 port (not using the converter). Strait to the laptop DB9 it would update in less than 4 seconds. I could not find any way to make the unit run faster using the converter.


After all the reading I've been doing on the notes from FTDI about the chips used in the converter and the USB protocol this is as fast as I think we're going to get the current converters to run. I am eyeballing a different FTDI chipset that may do better, but the boards based upon it are about 10$ more expensive than the dlp adapter. I'm going to be testing those when I go back to the the stim work. I also seem to recall that you're able to increase the USB polling speed on some mice (think FPS gaming mice), which may also bring an increase if applicable here.

You can also thank vprtech for offering up the proof that we weren't strictly limited to 33 samples/s by the ecu's response speed. I probably would have said 'that's as fast as it goes' without his evidence that a DRB-II communicates faster than my plugin.



For some reason I could never get the 3 different DB9 RS232 units I own to communicate to the SMEC or my LM. If I can get that to work it should be ridiculously more responsive. Now I know the signal is supposed to be inverted maybe I can somehow get the DB9 RS232 converters to work for testing, but since I only have one DB9 port on the laptop, that means my LM-1 will have to be hooked up to serial converter which makes the wideband log slower.


There may be another reason it didn't want to work. Some serial ports don't like odd baud rates like what we have to use. I have used an add-in pcmcia card to handle the odd baud rates. I'm sure that there's a way of getting a straight rs232 connection, as I've done it before with a LM. The LM didn't require a inverted connection because I soldered straight to the pins on the mcu, that's hard to do with a smec though. I attempted to invert the signals on my rs232 adapter for a smec once, but I didn't do it properly and went back to USB. I thought Rob was working on a rs232 adapter for flashing/datalogging, but I'm not sure where he stands with that. I'll try to test the speed of a rs232 connection when I get back to the plugin.



I need to get a knock board for my Supra!
Is your new stim the JimStim? That board is really nice for testing.
Where are your articles located?

The working title of my new stim (which has had input from Rob) is the uberstim. It's mostly focused on chrysler stuff, but there's some parts that are applicable to bench testing any ecu. Most of the info on my projects are around here, you can check the smecstim thread for updates on the next stim.

The knock board thread is in this section, I'm working with Bucar and Frank on that. I'd support the supra, but I need the cam/crank/distributor waveforms to do it. The board is currently setup to start monitoring for knock at a certain crank angle and stop at some other fixed angle. So it needs to know how to calculate those angles from it's pickup inputs. I just got the code to compile last night after reworking a large chunk of it, so I'm hopeful that I'll be able to give it to Bucar to test sometime soon. I have to start working on the 2.0/2.4 decoder as soon as I get to run on the 2.2/2.5 stimulus the way I'd like it to, though.

[ShelGame]

After all the reading I've been doing on the notes from FTDI about the chips used in the converter and the USB protocol this is as fast as I think we're going to get the current converters to run. I am eyeballing a different FTDI chipset that may do better, but the boards based upon it are about 10$ more expensive than the dlp adapter. I'm going to be testing those when I go back to the the stim work. I also seem to recall that you're able to increase the USB polling speed on some mice (think FPS gaming mice), which may also bring an increase if applicable here.

You can also thank vprtech for offering up the proof that we weren't strictly limited to 33 samples/s by the ecu's response speed. I probably would have said 'that's as fast as it goes' without his evidence that a DRB-II communicates faster than my plugin.

Another possibility for the FTDI chip is the bit-bang mode. From what I've read, that might also make it faster. But, it doesn't look like you can use it as a generic serial port that way. You have to use the .dll. Might make programming more difficult. And, from what I've read, it still can't avoid the USB transfer latency. USB devices essentially have to wait their turn to use the bus, and this will ultimately limit how fast we can get data directly with a USB-serial interface.

Instead of the FTDI chip, I'm looking at a Pic Micro that is intended to add USB to embedded applications. It's less than $2 in bulk. It has both a built-in USB interface and a UART. My plan is to add some serial memory and try to get it to act as a buffer for the ECU. Basically, it will log whatever channels you want as fast as it can (or as fast as you specify, maybe) and load up a buffer. When the buffer is full, it will transfer the data to the PC (or phone ;) over serial (or BT). That way, the ECU is not waiting for the USB to 'catch up'. What I'd really like to do is make an all-in-one module that would allow either USB and BT datalogging as well as flashing for all of the ECU's. I think this micro will support it. I have a sample coming, and I'm going to get a development kit. Unfortunately, the BT modules are on back-order :(

[Stratman]

You can also thank vprtech for offering up the proof that we weren't strictly limited to 33 samples/s by the ecu's response speed. I probably would have said 'that's as fast as it goes' without his evidence that a DRB-II communicates faster than my plugin.

If you look at the PortMon log it seems like the plugin is hitting the same address twice in a row. Do you see the same thing?
Also, here is 30 sec worth of PortMon loggs from this morning. Same format as above, but without the wall clock time.
http://www.turbofreak.com/1ms_pluginlog_10_addies_increment.LOG
http://www.turbofreak.com/16ms_pluginlog_10_addies_increment.LOG



I thought Rob was working on a rs232 adapter for flashing/datalogging, but I'm not sure where he stands with that. I'll try to test the speed of a rs232 connection when I get back to the plugin.
I was able to flash my flashable SMEC back in 2004 with one of these RS232 boxes I build from Chad's kit, but I was never able to communicate like we are doing now. I believe I was just doing something wrong.

[risen]

Another possibility for the FTDI chip is the bit-bang mode. From what I've read, that might also make it faster. But, it doesn't look like you can use it as a generic serial port that way. You have to use the .dll. Might make programming more difficult. And, from what I've read, it still can't avoid the USB transfer latency. USB devices essentially have to wait their turn to use the bus, and this will ultimately limit how fast we can get data directly with a USB-serial interface.


I actually looked at that for another application, but I didn't think it was applicable to rs232, or would be a royal PITA since we'd have to handle the start bit and everything else. What I was actually considering is the ft2232h chip. I was reading that the regular speed usb only checks the bus 1 time per ms. The high speed (or full usb 2.0 speed) can update 8x per ms. Since the 2232h chip can do full 2.0 usb speeds it may be quicker. I wanted to test before I said anything, but since we're having a discussion now, I might as well mention it.



Instead of the FTDI chip, I'm looking at a Pic Micro that is intended to add USB to embedded applications. It's less than $2 in bulk. It has both a built-in USB interface and a UART. My plan is to add some serial memory and try to get it to act as a buffer for the ECU. Basically, it will log whatever channels you want as fast as it can (or as fast as you specify, maybe) and load up a buffer. When the buffer is full, it will transfer the data to the PC (or phone ;) over serial (or BT). That way, the ECU is not waiting for the USB to 'catch up'. What I'd really like to do is make an all-in-one module that would allow either USB and BT datalogging as well as flashing for all of the ECU's. I think this micro will support it. I have a sample coming, and I'm going to get a development kit. Unfortunately, the BT modules are on back-order :(

I also noticed that microchip has a mcp2200 chip that I was considering testing but I haven't looked to see what speed USB it supports. Do you know what usb standard/speed the chip you're looking at supports? I'm still a little iffy on the blocking of data. I'd like to see what the overhead looks like with the latency set as low as possible (125 us if possible) with a byte at a time. Maybe the blocking of data won't hurt things too much (heck, if you get it done in under 33ms, you're still doing better than the plugin was previously doing), but if you wait for a USB block at a minimum size of 62 bytes, the data is starting to be heavily delayed and it's harder to integrate with a wbo2.

[risen]

If you look at the PortMon log it seems like the plugin is hitting the same address twice in a row. Do you see the same thing?
Also, here is 30 sec worth of PortMon loggs from this morning. Same format as above, but without the wall clock time.
http://www.turbofreak.com/1ms_pluginlog_10_addies_increment.LOG
http://www.turbofreak.com/16ms_pluginlog_10_addies_increment.LOG

Yeah, that's my code. That's the reason I need to revisit it. It's being wasteful. It won't hurt anything, I just set it up to hammer the ecu as hard as it could. Now that I have a better understanding of the timing, etc I should be able to do it better.



I was able to flash my flashable SMEC back in 2004 with one of these RS232 boxes I build from Chad's kit, but I was never able to communicate like we are doing now. I believe I was just doing something wrong.

My guess would be that your serial port didn't like the logging baud rate. IIRC the flashing works at 9600, or at least the bootloader was sent at that baud.

[ShelGame]

I actually looked at that for another application, but I didn't think it was applicable to rs232, or would be a royal PITA since we'd have to handle the start bit and everything else. What I was actually considering is the ft2232h chip. I was reading that the regular speed usb only checks the bus 1 time per ms. The high speed (or full usb 2.0 speed) can update 8x per ms. Since the 2232h chip can do full 2.0 usb speeds it may be quicker. I wanted to test before I said anything, but since we're having a discussion now, I might as well mention it.



I also noticed that microchip has a mcp2200 chip that I was considering testing but I haven't looked to see what speed USB it supports. Do you know what usb standard/speed the chip you're looking at supports? I'm still a little iffy on the blocking of data. I'd like to see what the overhead looks like with the latency set as low as possible (125 us if possible) with a byte at a time. Maybe the blocking of data won't hurt things too much (heck, if you get it done in under 33ms, you're still doing better than the plugin was previously doing), but if you wait for a USB block at a minimum size of 62 bytes, the data is starting to be heavily delayed and it's harder to integrate with a wbo2.

The documentation says it's USB 2.0. But, I haven't read enough to know what actual speeds it communicates at. It's not a USB-UART chip, strictly speaking. It's a full-on Pic micro that happens to have both ports built in. With buffering, even USB 1.0 should work, I think.

As Chris found, we should be able to log @500 samples/sec with the DRB logging routine. I don't think I'll be happy unless I can get close to that. I get that now using the 'hi-speed' logger mod and the USB cable at 9600 baud. It could probably go faster if I changed the latency to 1ms, and increased the baud rate (I originally set it to 9600 because I was using a RS232 adapter, not USB).

[risen]

The documentation says it's USB 2.0. But, I haven't read enough to know what actual speeds it communicates at. It's not a USB-UART chip, strictly speaking. It's a full-on Pic micro that happens to have both ports built in. With buffering, even USB 1.0 should work, I think.

Can you give me the model number of the pic you're considering? You can pm it if you don't want to tip your hand too much :). I'd like to take a look at it's datasheet, and the fact that they're a few bucks a pop is really interesting.

USB (even 1.0) has plenty of bandwidth to handle what we're trying to do, it's just that it's latency is atrocious.



As Chris found, we should be able to log @500 samples/sec with the DRB logging routine. I don't think I'll be happy unless I can get close to that. I get that now using the 'hi-speed' logger mod and the USB cable at 9600 baud. It could probably go faster if I changed the latency to 1ms, and increased the baud rate (I originally set it to 9600 because I was using a RS232 adapter, not USB).


I've been meaning to ask, since the bar has been moed up so high, do you know what that timer you previously looked at was actually doing? I recall when I first tested and got around 33 samples/s that you had looked at the logging code on the ecu and found a timer compare with a variable that might've capped it. I was just wondering if you revisited that or figured out what was up with the timer.

[ShelGame]

I've been meaning to ask, since the bar has been moed up so high, do you know what that timer you previously looked at was actually doing? I recall when I first tested and got around 33 samples/s that you had looked at the logging code on the ecu and found a timer compare with a variable that might've capped it. I was just wondering if you revisited that or figured out what was up with the timer.

When I looked at it originally, I thought (for some reason) that the timer was being stored in 2's complement - which came out to a value of ~30samples/sec. But, I was wrong. I don't see (now) why I thought it was in 2's complement format. It's just a straight timer value. The loop that the datalogrer routine is in runs every 480uSec. Assuming the logger side was just as fast as the ECU side, that means it might be possible to get 1k samples/sec. In reality, with the overhead on the logger side, I think 500 is a good target.

[risen]

If you look at the PortMon log it seems like the plugin is hitting the same address twice in a row. Do you see the same thing?
Also, here is 30 sec worth of PortMon loggs from this morning. Same format as above, but without the wall clock time.
http://www.turbofreak.com/1ms_pluginlog_10_addies_increment.LOG
http://www.turbofreak.com/16ms_pluginlog_10_addies_increment.LOG


Based upon the little bit of data I looked at in that log it appears that the whole time from request to response is on the order of 2 ms now. That's quite impressive from just a tweak in the timeout setting. It would be even better if my program wasn't requesting each location 2x. I'll fix that in a couple months, I promise.

[Stratman]

I haven't tried the below values yet, but it is still a table from 0-5 volts which seems to be the problem. Yesterday I was creating a small custom table every which way (ie..input= -2.5, 0, 2.5...0-10 volts 0-5 volts, etc), but the gauge would still roll right around to 5 volts after it apparently goes below 0 volts :confused:. I don't quite understand what the ecu's output is from address 8B to make this situation occur. Logworks seems to not like any input voltage other than 0-5 volts! I thought I figured it out and at 0=-25, 2.50=0, and 5.00=25 though when I tuned the PE table to force the 8B address to go below 0 volts point, it jump right to 5 volts on the guage. Is the plugin translating address 8B as a 0-5 volts output into Logworks? How logworks reading the output of the ecu hex?

If I am not explaining this in an understanding way, I'm sure I can send you the log or a video of this occurrence.

Did you make this table below as to invert the 0-5 volts in Logworks gauge? (ie...illustrated below, 0 is positive range and .499 volts is negative range)



Here's your table. I looked at logworks a little, but I haven't had time to really mess with it lately, I didn't even load the table in yet :(. If it doesn't work on your first try LMK and I'll find a way to get the table to load tomorrow at lunch.


0.0000,0
0.0195,1
0.0391,2
0.0586,3
0.0781,4
0.0976,5
0.1172,6
0.1367,7
0.1562,8
0.1758,9
0.1953,10
0.2148,11
0.2344,12
0.2539,13
0.2734,14
0.2929,15
0.3125,16
0.3320,17
0.3515,18
0.3711,19
0.3906,20
0.4101,21
0.4297,22
0.4492,23
0.4687,24
0.4882,25
0.5078,26
0.5273,27
0.5468,28
0.5664,29
0.5859,30
0.6054,31
0.6250,32
0.6445,33
0.6640,34
0.6836,35
0.7031,36
0.7226,37
0.7421,38
0.7617,39
0.7812,40
0.8007,41
0.8203,42
0.8398,43
0.8593,44
0.8789,45
0.8984,46
0.9179,47
0.9374,48
0.9570,49
0.9765,50
0.9960,51
1.0156,52
1.0351,53
1.0546,54
1.0742,55
1.0937,56
1.1132,57
1.1327,58
1.1523,59
1.1718,60
1.1913,61
1.2109,62
1.2304,63
1.2499,64
1.2695,65
1.2890,66
1.3085,67
1.3280,68
1.3476,69
1.3671,70
1.3866,71
1.4062,72
1.4257,73
1.4452,74
1.4648,75
1.4843,76
1.5038,77
1.5233,78
1.5429,79
1.5624,80
1.5819,81
1.6015,82
1.6210,83
1.6405,84
1.6601,85
1.6796,86
1.6991,87
1.7186,88
1.7382,89
1.7577,90
1.7772,91
1.7968,92
1.8163,93
1.8358,94
1.8554,95
1.8749,96
1.8944,97
1.9139,98
1.9335,99
1.9530,100
1.9725,101
1.9921,102
2.0116,103
2.0311,104
2.0507,105
2.0702,106
2.0897,107
2.1092,108
2.1288,109
2.1483,110
2.1678,111
2.1874,112
2.2069,113
2.2264,114
2.2460,115
2.2655,116
2.2850,117
2.3045,118
2.3241,119
2.3436,120
2.3631,121
2.3827,122
2.4022,123
2.4217,124
2.4413,125
2.4608,126
2.4803,127
2.4998,-128
2.5194,-127
2.5389,-126
2.5584,-125
2.5780,-124
2.5975,-123
2.6170,-122
2.6366,-121
2.6561,-120
2.6756,-119
2.6951,-118
2.7147,-117
2.7342,-116
2.7537,-115
2.7733,-114
2.7928,-113
2.8123,-112
2.8319,-111
2.8514,-110
2.8709,-109
2.8904,-108
2.9100,-107
2.9295,-106
2.9490,-105
2.9686,-104
2.9881,-103
3.0076,-102
3.0272,-101
3.0467,-100
3.0662,-99
3.0857,-98
3.1053,-97
3.1248,-96
3.1443,-95
3.1639,-94
3.1834,-93
3.2029,-92
3.2225,-91
3.2420,-90
3.2615,-89
3.2810,-88
3.3006,-87
3.3201,-86
3.3396,-85
3.3592,-84
3.3787,-83
3.3982,-82
3.4178,-81
3.4373,-80
3.4568,-79
3.4763,-78
3.4959,-77
3.5154,-76
3.5349,-75
3.5545,-74
3.5740,-73
3.5935,-72
3.6131,-71
3.6326,-70
3.6521,-69
3.6716,-68
3.6912,-67
3.7107,-66
3.7302,-65
3.7498,-64
3.7693,-63
3.7888,-62
3.8084,-61
3.8279,-60
3.8474,-59
3.8669,-58
3.8865,-57
3.9060,-56
3.9255,-55
3.9451,-54
3.9646,-53
3.9841,-52
4.0037,-51
4.0232,-50
4.0427,-49
4.0622,-48
4.0818,-47
4.1013,-46
4.1208,-45
4.1404,-44
4.1599,-43
4.1794,-42
4.1990,-41
4.2185,-40
4.2380,-39
4.2575,-38
4.2771,-37
4.2966,-36
4.3161,-35
4.3357,-34
4.3552,-33
4.3747,-32
4.3943,-31
4.4138,-30
4.4333,-29
4.4528,-28
4.4724,-27
4.4919,-26
4.5114,-25
4.5310,-24
4.5505,-23
4.5700,-22
4.5895,-21
4.6091,-20
4.6286,-19
4.6481,-18
4.6677,-17
4.6872,-16
4.7067,-15
4.7263,-14
4.7458,-13
4.7653,-12
4.7848,-11
4.8044,-10
4.8239,-9
4.8434,-8
4.8630,-7
4.8825,-6
4.9020,-5
4.9216,-4
4.9411,-3
4.9606,-2
4.9801,-1
4.9997,0

[risen]

I haven't tried the below values yet, but it is still a table from 0-5 volts which seems to be the problem. Yesterday I was creating a small custom table every which way (ie..input= -2.5, 0, 2.5...0-10 volts 0-5 volts, etc), but the gauge would still roll right around to 5 volts after it apparently goes below 0 volts :confused:. I don't quite understand what the ecu's output is from address 8B to make this situation occur. Logworks seems to not like any input voltage other than 0-5 volts! I thought I figured it out and at 0=-25, 2.50=0, and 5.00=25 though when I tuned the PE table to force the 8B address to go below 0 volts point, it jump right to 5 volts on the guage. Is the plugin translating address 8B as a 0-5 volts output into Logworks? How logworks reading the output of the ecu hex?

If I am not explaining this in an understanding way, I'm sure I can send you the log or a video of this occurrence.

Did you make this table below as to invert the 0-5 volts in Logworks gauge? (ie...illustrated below, 0 is positive range and .499 volts is negative range)
I thought logworks was forcing the input to be read in volts, no? Basically, what you want to happen is the values 0-127 stay the same. The values 128-255 ascending map to -127 to -1 descending. I'm going to have to look at it in more depth. I'll probably add a checkbox to the plugin to select signed vs unsigned.

As to how the plugin is handling it, there isn't any translation going on. It just takes the byte received and sends it to logworks. There may be a cast to a double or float in there, but that's about it. It's essentially the raw hex value 0x00 to 0xff mapped to 0 - 255.

[Stratman]

Thanks for the lookup table values. All values in a custom lookup table must be ascending or it won't work when loaded into Logworks so I corrected and it loads fine now. The ascending format should be correct anyways as lowering the pumping efficiency in real time shows fuel increase at address 8B moving up the scale from 0 towards 5 volt and visa versa. Here is the format to load for a custom lookup table:



Trim Volt
-127 0.0195
-126 0.0391
-125 0.0586
-124 0.0781
-123 0.0976
-122 0.1172
-121 0.1367
-120 0.1562
-119 0.1758
-118 0.1953
-117 0.2148
-116 0.2344
-115 0.2539
-114 0.2734
-113 0.2929
-112 0.3125
-111 0.332
-110 0.3515
-109 0.3711
-108 0.3906
-107 0.4101
-106 0.4297
-105 0.4492
-104 0.4687
-103 0.4882
-102 0.5078
-101 0.5273
-100 0.5468
-99 0.5664
-98 0.5859
-97 0.6054
-96 0.625
-95 0.6445
-94 0.664
-93 0.6836
-92 0.7031
-91 0.7226
-90 0.7421
-89 0.7617
-88 0.7812
-87 0.8007
-86 0.8203
-85 0.8398
-84 0.8593
-83 0.8789
-82 0.8984
-81 0.9179
-80 0.9374
-79 0.957
-78 0.9765
-77 0.996
-76 1.0156
-75 1.0351
-74 1.0546
-73 1.0742
-72 1.0937
-71 1.1132
-70 1.1327
-69 1.1523
-68 1.1718
-67 1.1913
-66 1.2109
-65 1.2304
-64 1.2499
-63 1.2695
-62 1.289
-61 1.3085
-60 1.328
-59 1.3476
-58 1.3671
-57 1.3866
-56 1.4062
-55 1.4257
-54 1.4452
-53 1.4648
-52 1.4843
-51 1.5038
-50 1.5233
-49 1.5429
-48 1.5624
-47 1.5819
-46 1.6015
-45 1.621
-44 1.6405
-43 1.6601
-42 1.6796
-41 1.6991
-40 1.7186
-39 1.7382
-38 1.7577
-37 1.7772
-36 1.7968
-35 1.8163
-34 1.8358
-33 1.8554
-32 1.8749
-31 1.8944
-30 1.9139
-29 1.9335
-28 1.953
-27 1.9725
-26 1.9921
-25 2.0116
-24 2.0311
-23 2.0507
-22 2.0702
-21 2.0897
-20 2.1092
-19 2.1288
-18 2.1483
-17 2.1678
-16 2.1874
-15 2.2069
-14 2.2264
-13 2.246
-12 2.2655
-11 2.285
-10 2.3045
-9 2.3241
-8 2.3436
-7 2.3631
-6 2.3827
-5 2.4022
-4 2.4217
-3 2.4413
-2 2.4608
-1 2.4803
0 2.4998
1 2.5194
2 2.5389
3 2.5584
4 2.578
5 2.5975
6 2.617
7 2.6366
8 2.6561
9 2.6756
10 2.6951
11 2.7147
12 2.7342
13 2.7537
14 2.7733
15 2.7928
16 2.8123
17 2.8319
18 2.8514
19 2.8709
20 2.8904
21 2.91
22 2.9295
23 2.949
24 2.9686
25 2.9881
26 3.0076
27 3.0272
28 3.0467
29 3.0662
30 3.0857
31 3.1053
32 3.1248
33 3.1443
34 3.1639
35 3.1834
36 3.2029
37 3.2225
38 3.242
39 3.2615
40 3.281
41 3.3006
42 3.3201
43 3.3396
44 3.3592
45 3.3787
46 3.3982
47 3.4178
48 3.4373
49 3.4568
50 3.4763
51 3.4959
52 3.5154
53 3.5349
54 3.5545
55 3.574
56 3.5935
57 3.6131
58 3.6326
59 3.6521
60 3.6716
61 3.6912
62 3.7107
63 3.7302
64 3.7498
65 3.7693
66 3.7888
67 3.8084
68 3.8279
69 3.8474
70 3.8669
71 3.8865
72 3.906
73 3.9255
74 3.9451
75 3.9646
76 3.9841
77 4.0037
78 4.0232
79 4.0427
80 4.0622
81 4.0818
82 4.1013
83 4.1208
84 4.1404
85 4.1599
86 4.1794
87 4.199
88 4.2185
89 4.238
90 4.2575
91 4.2771
92 4.2966
93 4.3161
94 4.3357
95 4.3552
96 4.3747
97 4.3943
98 4.4138
99 4.4333
100 4.4528
101 4.4724
102 4.4919
103 4.5114
104 4.531
105 4.5505
106 4.57
107 4.5895
108 4.6091
109 4.6286
110 4.6481
111 4.6677
112 4.6872
113 4.7067
114 4.7263
115 4.7458
116 4.7653
117 4.7848
118 4.8044
119 4.8239
120 4.8434
121 4.863
122 4.8825
123 4.902
124 4.9216
125 4.9411
126 4.9606
127 4.9801
128 4.9997

[risen]

Thanks for the lookup table values. All values in a custom lookup table must be ascending or it won't work when loaded into Logworks so I corrected and it loads fine now. The ascending format should be correct anyways as lowering the pumping efficiency in real time shows fuel increase at address 8B moving up the scale from 0 towards 5 volt and visa versa. Here is the format to load for a custom lookup table:



Trim Volt
-127 0.0195
-126 0.0391
-125 0.0586
-124 0.0781
-123 0.0976
-122 0.1172
-121 0.1367
-120 0.1562
-119 0.1758
-118 0.1953
-117 0.2148
-116 0.2344
-115 0.2539
-114 0.2734
-113 0.2929
-112 0.3125
-111 0.332
-110 0.3515
-109 0.3711
-108 0.3906
-107 0.4101
-106 0.4297
-105 0.4492
-104 0.4687
-103 0.4882
-102 0.5078
-101 0.5273
-100 0.5468
-99 0.5664
-98 0.5859
-97 0.6054
-96 0.625
-95 0.6445
-94 0.664
-93 0.6836
-92 0.7031
-91 0.7226
-90 0.7421
-89 0.7617
-88 0.7812
-87 0.8007
-86 0.8203
-85 0.8398
-84 0.8593
-83 0.8789
-82 0.8984
-81 0.9179
-80 0.9374
-79 0.957
-78 0.9765
-77 0.996
-76 1.0156
-75 1.0351
-74 1.0546
-73 1.0742
-72 1.0937
-71 1.1132
-70 1.1327
-69 1.1523
-68 1.1718
-67 1.1913
-66 1.2109
-65 1.2304
-64 1.2499
-63 1.2695
-62 1.289
-61 1.3085
-60 1.328
-59 1.3476
-58 1.3671
-57 1.3866
-56 1.4062
-55 1.4257
-54 1.4452
-53 1.4648
-52 1.4843
-51 1.5038
-50 1.5233
-49 1.5429
-48 1.5624
-47 1.5819
-46 1.6015
-45 1.621
-44 1.6405
-43 1.6601
-42 1.6796
-41 1.6991
-40 1.7186
-39 1.7382
-38 1.7577
-37 1.7772
-36 1.7968
-35 1.8163
-34 1.8358
-33 1.8554
-32 1.8749
-31 1.8944
-30 1.9139
-29 1.9335
-28 1.953
-27 1.9725
-26 1.9921
-25 2.0116
-24 2.0311
-23 2.0507
-22 2.0702
-21 2.0897
-20 2.1092
-19 2.1288
-18 2.1483
-17 2.1678
-16 2.1874
-15 2.2069
-14 2.2264
-13 2.246
-12 2.2655
-11 2.285
-10 2.3045
-9 2.3241
-8 2.3436
-7 2.3631
-6 2.3827
-5 2.4022
-4 2.4217
-3 2.4413
-2 2.4608
-1 2.4803
0 2.4998
1 2.5194
2 2.5389
3 2.5584
4 2.578
5 2.5975
6 2.617
7 2.6366
8 2.6561
9 2.6756
10 2.6951
11 2.7147
12 2.7342
13 2.7537
14 2.7733
15 2.7928
16 2.8123
17 2.8319
18 2.8514
19 2.8709
20 2.8904
21 2.91
22 2.9295
23 2.949
24 2.9686
25 2.9881
26 3.0076
27 3.0272
28 3.0467
29 3.0662
30 3.0857
31 3.1053
32 3.1248
33 3.1443
34 3.1639
35 3.1834
36 3.2029
37 3.2225
38 3.242
39 3.2615
40 3.281
41 3.3006
42 3.3201
43 3.3396
44 3.3592
45 3.3787
46 3.3982
47 3.4178
48 3.4373
49 3.4568
50 3.4763
51 3.4959
52 3.5154
53 3.5349
54 3.5545
55 3.574
56 3.5935
57 3.6131
58 3.6326
59 3.6521
60 3.6716
61 3.6912
62 3.7107
63 3.7302
64 3.7498
65 3.7693
66 3.7888
67 3.8084
68 3.8279
69 3.8474
70 3.8669
71 3.8865
72 3.906
73 3.9255
74 3.9451
75 3.9646
76 3.9841
77 4.0037
78 4.0232
79 4.0427
80 4.0622
81 4.0818
82 4.1013
83 4.1208
84 4.1404
85 4.1599
86 4.1794
87 4.199
88 4.2185
89 4.238
90 4.2575
91 4.2771
92 4.2966
93 4.3161
94 4.3357
95 4.3552
96 4.3747
97 4.3943
98 4.4138
99 4.4333
100 4.4528
101 4.4724
102 4.4919
103 4.5114
104 4.531
105 4.5505
106 4.57
107 4.5895
108 4.6091
109 4.6286
110 4.6481
111 4.6677
112 4.6872
113 4.7067
114 4.7263
115 4.7458
116 4.7653
117 4.7848
118 4.8044
119 4.8239
120 4.8434
121 4.863
122 4.8825
123 4.902
124 4.9216
125 4.9411
126 4.9606
127 4.9801
128 4.9997


Are you sure that's right? -127 as a signed number is 128 unsigned or around 2.5v (if you map 0-255 unsigned to 0-5). I guess if it's working the way you expect it to it's ok. I'm going to add a feature into the plugin for signed/unsigned.

[Stratman]

Are you sure that's right? -127 as a signed number is 128 unsigned or around 2.5v (if you map 0-255 unsigned to 0-5). I guess if it's working the way you expect it to it's ok. I'm going to add a feature into the plugin for signed/unsigned.

The main thing I am judging this by is if I add fuel in PE table address, address 8B needle will move left to pull fuel to regain Stoich value, if I remove fuel in PE table needle will move right to add fuel to regain Stoich unless I am mistaken and address 8B is not the fuel trim value.
After testing more this morning Logworks seems to have a continuous problem with this address on the input side as it will still flip the needle straight to 5 volts when descending towards and past 0 volts (full left side of gauge).
I need to get MPscan working so I can see what this address output is to understand why or when Logworks is flipping the needle back to 5 volts once it descends past 0 volts, but I am having trouble communication with MPscan correctly as stated in the MPscan thread.

[Stratman]

Can the LW plugin have an option for output to a txt or dif log file without having to use Logworks? Since we have found the plugin is soooo freakin fast and all options for the different years and code type is available it could be a sole key program with or without LW on any vehicle without the use of the LM-1 etc....
The key option would be to continue using Logworks since it is a great graphical log and works incredibly smooth with the plugin. The main obstacle is Logworks only connects and logs when an LM1, LM2, or LC1 is connected to a com port. The Innovate forum is down at the moment, but I thought I have read somewhere that Logworks can be activated somehow to run test while creating plugins with the Innovate SDK. That would be the coolest combination for sure.
The only other hurdle I am trying to deal with is how Logworks is handling the signed values like logging address 8B as the 0-5 volt input is not working right with the signed values. It logs very smooth, but it's confusing how the gauge can descend downward past 0 volts jumping the needle directly to 5 volts.

[risen]

Can the LW plugin have an option for output to a txt or dif log file without having to use Logworks? Since we have found the plugin is soooo freakin fast and all options for the different years and code type is available it could be a sole key program with or without LW on any vehicle without the use of the LM-1 etc....
The key option would be to continue using Logworks since it is a great graphical log and works incredibly smooth with the plugin. The main obstacle is Logworks only connects and logs when an LM1, LM2, or LC1 is connected to a com port. The Innovate forum is down at the moment, but I thought I have read somewhere that Logworks can be activated somehow to run test while creating plugins with the Innovate SDK. That would be the coolest combination for sure.
The only other hurdle I am trying to deal with is how Logworks is handling the signed values like logging address 8B as the 0-5 volt input is not working right with the signed values. It logs very smooth, but it's confusing how the gauge can descend downward past 0 volts jumping the needle directly to 5 volts.

Yes, I can add a feature to dump the output to a text file. I can do something like columns delimited by comma with or without raw values. I would have to setup the translations of the data in the plugin if you don't want values of 0-255 in the log. Do you have any preference for the output format? Do you want it formatted and translated or just the raw values?

Logworks can run without a mts device. You just need the stim mts.dll file. You copy the stim mts.dll file (after saving a copy of your original) run the plugin and then logworks afterwards.

I still have to try and mess with logworks to see if I can get the table to function properly.

[wowzer]

risen - quick question - when the plugin is closed do you reset the ecu baud rate back to the low baud setting?

[Stratman]

Yes, I can add a feature to dump the output to a text file. I can do something like columns delimited by comma with or without raw values. I would have to setup the translations of the data in the plugin if you don't want values of 0-255 in the log. Do you have any preference for the output format? Do you want it formatted and translated or just the raw values?
I didn't stop to realize the work it would take for this, but the translation would need to be it's scaled format and labeled at the top of each column with a time stamp in column A1 for a diff files so it could be opened and read to see actual timing deg, IPW, etc....... Is it as easy as adding a user input scale value field beside each address? In that case maybe an option to just output the raw value if no scale is in the field?


Logworks can run without a mts device. You just need the stim mts.dll file. You copy the stim mts.dll file (after saving a copy of your original) run the plugin and then logworks afterwards.

I still have to try and mess with logworks to see if I can get the table to function properly.
Where is the stim mts.dll located? Is this correct..... overwrite the original mts.dll file with the stim file in the Innovate folder under Program Files?

[Stratman]

:o Sorry, I found the info on the stim file subject on page 4, but the forum is down so I can't grab it. Can someone post a copy of it?

[risen]

I didn't stop to realize the work it would take for this, but the translation would need to be it's scaled format and labeled at the top of each column with a time stamp in column A1 for a diff files so it could be opened and read to see actual timing deg, IPW, etc....... Is it as easy as adding a user input scale value field beside each address? In that case maybe an option to just output the raw value if no scale is in the field?


I can do that, I know what I'm getting myself into, so don't worry about how much work it is. Here's what I'm thinking: a checkbox to enable the scaling for each variable, a checkbox for signed/unsigned values, and 2 text boxes for the scale. I'll load defaults for the scale and write any changes to the registry. It'll be almost the same as the ram map setup.


Where is the stim mts.dll located? Is this correct..... overwrite the original mts.dll file with the stim file in the Innovate folder under Program Files?

Yes. Send me your email in a pm and I'll mail it to you on mon when I have access to my laptop at home. I'm not sure I want to post that here, I don't need any trouble from innovate. The only issue with the stim dll is that you can only enable 5 channels.

[Stratman]

After explaining to Innovate what file I needed, they were kind enough to send me the stim file.

[CSX194]

I would like to thank all involved in this plugin, its great! I got it up and running without a hitch last night. I have a few questions/problems, Im running the turbonator 87 t2 cal with 3 bar map and ostrich.

Questions:
I have used the RPM numbers from the 3rd page but I dont think that it is displaying accurate, I show about 900 rpm on the tach and in logworks it idles around 500 or so. Second question is with the advance, is the number that shows the actual advance or is it half of what it says? At idle I show about 50 degrees. Not sure if Im doing something wrong. I used the numbers below

advance 0deg-5v; 128deg-5v
RPM 0rpm-0v; 8192rpm-5v

So far these are the only 2 plus my wideband and map that I am messing with. I have verified that the map is displaying correctly. Im sure I will dig a little deeper when I get these figured out and get more familiar with logworks. Thanks in advance.

Jamie

[risen]

I would like to thank all involved in this plugin, its great! I got it up and running without a hitch last night. I have a few questions/problems, Im running the turbonator 87 t2 cal with 3 bar map and ostrich.

Questions:
I have used the RPM numbers from the 3rd page but I dont think that it is displaying accurate, I show about 900 rpm on the tach and in logworks it idles around 500 or so. Second question is with the advance, is the number that shows the actual advance or is it half of what it says? At idle I show about 50 degrees. Not sure if Im doing something wrong. I used the numbers below

advance 0deg-5v; 128deg-5v
RPM 0rpm-0v; 8192rpm-5v

So far these are the only 2 plus my wideband and map that I am messing with. I have verified that the map is displaying correctly. Im sure I will dig a little deeper when I get these figured out and get more familiar with logworks. Thanks in advance.

Jamie
I think you want the advance to be 0 deg @ 0v, 128 deg @ 5v. That should give you the proper advance readout.

RPM, I don't recall 100% but the LM has really poor resolution for RPM. Can you tell me what ram location it says next to the RPM box you have checked?

[CSXRT4]

I think you want the advance to be 0 deg @ 0v, 128 deg @ 5v. That should give you the proper advance readout.

RPM, I don't recall 100% but the LM has really poor resolution for RPM. Can you tell me what ram location it says next to the RPM box you have checked?

EDIT: NVM I just read that you were talking about the LM :o

[CSX194]

I think you want the advance to be 0 deg @ 0v, 128 deg @ 5v. That should give you the proper advance readout.

RPM, I don't recall 100% but the LM has really poor resolution for RPM. Can you tell me what ram location it says next to the RPM box you have checked?

That was a typo it should have been 0deg at 0v not 5v. I will look at the ram location when I get home. Its on my other computer. Thank you very much for the help!

I could always get the data cable for my LM-2 to log the rpm if I cant get it to work.

[CSX194]

I think you want the advance to be 0 deg @ 0v, 128 deg @ 5v. That should give you the proper advance readout.

RPM, I don't recall 100% but the LM has really poor resolution for RPM. Can you tell me what ram location it says next to the RPM box you have checked?

Location is 8F

[risen]

Location is 8F

I believe that the resolution is limited to +/- 256 rpm, as that's the upper byte of the RPM. I think this makes it so the normal scaling would need to be doubled, so you can try and map it to 0-16384.

The code for a higher resolution 1 byte rpm is in some of the turbonator LM cals and uses the F0 address for RPM, which would be enough to use the regular scaling (0-8192) and be good to +/- 128 rpm. You can try that, too.

Hopefully one of those 2 will be OK. I'm sure Rob will correct me if I've got it wrong.

The advance, I thought would be correct as 0-128. Can you try and set 0-2.5v to 0-64 and see what that looks like?

[CSX194]

Thanks, I will try the advance tonight. I did just as you said for kicks last night,and it seemed that the rpm was dead on:) I will report back on the advance.

[Stratman]

Still working great anytime I need it! There was a necessity to put my 11 sec race engine from the CSX into my DD Daytona so I've been using it alot to tune.
Running the 89 SMEC, the MPH updates very slowly in the logs only receiving data roughly every 3 sec logging 5-7 MPH or so each interval. Not a big deal, just wondered if that value is received as low priority.
BTW: I never figured out the signed value issue so I just stopped logging it.:)

[risen]

Still working great anytime I need it! There was a necessity to put my 11 sec race engine from the CSX into my DD Daytona so I've been using it alot to tune.
Running the 89 SMEC, the MPH updates very slowly in the logs only receiving data roughly every 3 sec logging 5-7 MPH or so each interval. Not a big deal, just wondered if that value is received as low priority.
BTW: I never figured out the signed value issue so I just stopped logging it.:)

It's really good to hear that someone else is having success with this thing. Thanks for that.

I'm not sure how often the MPH is updated in the ecu itself. It could be that it only uptdates the value into ram every so often, but the plugin queries for it as fast is a queries everything else. You might be able to pick Rob's brain about that, maybe he has a clue.

I'll get the support for signed variables added eventually, but it's probably going to take longer than I wanted. I have 0 free time right now with 3 courses this semester and a house that still needs to be fixed and rented. I'll get to it, eventually.

[ShelGame]

It's really good to hear that someone else is having success with this thing. Thanks for that.

I'm not sure how often the MPH is updated in the ecu itself. It could be that it only uptdates the value into ram every so often, but the plugin queries for it as fast is a queries everything else. You might be able to pick Rob's brain about that, maybe he has a clue.

I'll get the support for signed variables added eventually, but it's probably going to take longer than I wanted. I have 0 free time right now with 3 courses this semester and a house that still needs to be fixed and rented. I'll get to it, eventually.

I think if you're only logging the high byte of the MPH, the resolution is like 4mph. So, maybe that's what you're getting...

[risen]

I think if you're only logging the high byte of the MPH, the resolution is like 4mph. So, maybe that's what you're getting...

Thanks for jogging my memory. I'm 99% sure it's only taking the high byte. I think now that we can get the logging speed up by lowering the FTDI latency I'll have to do the 2 bytes for both RPM and MPH or at least give the option to do so.

[Stratman]

Just for reference of how well this is working and to see outcome of the plugin, here is a log after install of a new boost controller Sunday. It will show alot such as how much lag the Innovate aux box MAP sensor will pick up with the extra length of vacuum hose compared to the ecu MAP input. Logworks 3 was used.
http://www.turbofreak.com/logs/9-19-10_blitz_boost_control.log

[Stratman]

I wanted to add that the latency of the log above was set to 1ms.


Thanks for jogging my memory. I'm 99% sure it's only taking the high byte. I think now that we can get the logging speed up by lowering the FTDI latency I'll have to do the 2 bytes for both RPM and MPH or at least give the option to do so.

Didn't we also find that it queries each ram location twice in a row? If so, that should speed it up even more. After running with the OTC and DRB2 for so long, this plugin logs very fast in comparison.

Since I use this so much and know some of the issues, I want to contribute and take a stab at these changes. It's been a while since I've messed with C++ and another copy of Visual is needed. This would be fun to mess with again while I have down time with my hybrid build.

[Stratman]

I found my Borland C++ last night and installed, but apparently it's not like riding a bicycle. I tried to add the source files and compile though I am missing a afxwin.h and other afx library files. Got alot of work to do.

[risen]

Didn't we also find that it queries each ram location twice in a row? If so, that should speed it up even more. After running with the OTC and DRB2 for so long, this plugin logs very fast in comparison.

Since I use this so much and know some of the issues, I want to contribute and take a stab at these changes. It's been a while since I've messed with C++ and another copy of Visual is needed. This would be fun to mess with again while I have down time with my hybrid build.

It does try to get each location 2x over. That's actually by design on the code. You should be able to remove that somewhat easily. If I recall correctly the main loop is all contained in one function that is used to create a thread. It should be pretty obvious which one it is once you make it through the boilerplate bs.


I found my Borland C++ last night and installed, but apparently it's not like riding a bicycle. I tried to add the source files and compile though I am missing a afxwin.h and other afx library files. Got alot of work to do.

I'm not sure if borland is going to work as it was built in visual studio and visual studio is notoriously finicky. You could try the express version of visual c++, it may build in that environment without too many headaches,

[Stratman]

Same situation with afxwin.h in Visual 2010 express, but at least the project opened. Downloaded MS SDK and included that file. Looks like I'll have to learn alot more than I thought.

[Aries_Turbo]

is the winlog plugin going to get these updates at some point? no rush of course. :) my cars are sitting on tarps in the yard lol.

[risen]

Same situation with afxwin.h in Visual 2010 express, but at least the project opened. Downloaded MS SDK and included that file. Looks like I'll have to learn alot more than I thought.

I seem to recall that of it's asking for that header there's something else wrong with the setup of the project or environment. Have you tried googling for that error a little bit?


is the winlog plugin going to get these updates at some point? no rush of course. :) my cars are sitting on tarps in the yard lol.

Yes I plan on it, it'll probably be done after logworks though. Also depends on how many additional changes need to be made to the knock unit. So you'll have to pick your requests wisely, or learn how to program in c/c++. :)

[Aries_Turbo]

lol. hehe i understand. its low on my priority list compared to the knock unit.

i would like to learn C/C++ at some point. :) it would open up all kinds of possibilities for MCU gadgetry. :)

Brian

[Stratman]

Yes, I've googled it and found alot of uber l33t coders with sarcastic answers to guys with the same problem. The only helpful answer I found was the MS SDK link which I downloaded and included in the project. Maybe I'm just doin it wrong.

[Stratman]

Installing VS 2005 now. Knew I had it, but couldn't find it earlier this week. I walked out the door this morning and it was sitting on the top of my Frazier speaker cabinet right by the door.lol :) Go figure.

Edit: No more AFXWIN.H warnings with VS2005!!!! I just have some strncpy errors which I am dealing with now. More later.

[risen]

Installing VS 2005 now. Knew I had it, but couldn't find it earlier this week. I walked out the door this morning and it was sitting on the top of my Frazier speaker cabinet right by the door.lol :) Go figure.

Edit: No more AFXWIN.H warnings with VS2005!!!! I just have some strncpy errors which I am dealing with now. More later.

VS makes me want to gouge my eyes out and cleanse the sockets with bleach afterwards.

I'm not sure what the issue with strncpy would be, it's pretty standard. Is it just warnings from the compiler or is it actually throwing errors?

[wowzer]

i'm using vs2008 and if i remember i just added a directive i think to the preprocessor to ignore some of the "non secure" strncpy functions. it's a very nice piece of programming that risen did.

[Stratman]

That's what I believe. There are no more strncpy error after #define
the depricate errors so maybe I can get it working soon. Will update more later.

[wowzer]

well - worse case i can zip up mine and email it to you, but it sounds like you basically have it working.

[Stratman]

well - worse case i can zip up mine and email it to you, but it sounds like you basically have it working.

That would be appreciated. At least I could have another project to mess with if this doesn't work.
Email
chris at
turbofreak
com
and
chris.robertson at
nei
com.

Thanks!

Chris

[risen]

i'm using vs2008 and if i remember i just added a directive i think to the preprocessor to ignore some of the "non secure" strncpy functions. it's a very nice piece of programming that risen did.
Thanks, I'm glad that you found some of it useful, and that's a hell of a compliment from the guy who's got mptuner on his resume :) . There's tons of stuff in there that needs to be cleaned up and broken apart to make it more modular. And I'd still like to get all the strings out of there and into a .csv or .txt file. IMO that stuff really doesn't belong in the binary, it should be in a configuration file.


That's what I believe. There are no more strncpy error after #define
the depricate errors so maybe I can get it working soon. Will update more later.

Well, we could probably change to the use of the strncpy functions with a max length. I probably just figured since I have to stick these in here, I'm not going to sweat the length because they'll be compiled into the binary.

[Stratman]

This is what I have left to deal with after ignoring the strncpy errors. If Wowzer's VS2008 ver works with my 2005 ver, then I'll just leave this alone.


------ Build started: Project: lw2_lm_vdev, Configuration: Release Win32 ------
Compiling...
stdafx.cpp
Compiling...
lw2vdev1.cpp
lw2_lm_vdevDlg.cpp
.\lw2_lm_vdevDlg.cpp(595) : warning C4800: 'UINT' : forcing value to bool 'true' or 'false' (performance warning)
.\lw2_lm_vdevDlg.cpp(605) : warning C4244: '=' : conversion from 'double' to 'float', possible loss of data
.\lw2_lm_vdevDlg.cpp(626) : warning C4244: 'argument' : conversion from 'double' to 'int', possible loss of data
.\lw2_lm_vdevDlg.cpp(897) : error C3867: 'Clw2_lm_vdevDlg::close_in_error': function call missing argument list; use '&Clw2_lm_vdevDlg::close_in_error' to create a pointer to member
.\lw2_lm_vdevDlg.cpp(1084) : warning C4800: 'BOOL' : forcing value to bool 'true' or 'false' (performance warning)
.\lw2_lm_vdevDlg.cpp(1094) : warning C4800: 'BOOL' : forcing value to bool 'true' or 'false' (performance warning)
lw2_lm_vdev.cpp
Generating Code...
Build log was saved at "file://c:\Documents and Settings\Chris\My Documents\lw2_vdev\Release\BuildLog.htm"
lw2_lm_vdev - 1 error(s), 5 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

[wowzer]

chris - i do not get the error message, but i do get the same warnings which should be addressed at some point. i'll email u my lw2_lm_vdevdlg.cpp file

http://www.turbo-mopar.com/forums/photopost/data/500/thumbs/c_setting.jpg ('http://www.turbo-mopar.com/forums/photopost/data/500/c_setting.jpg') http://www.turbo-mopar.com/forums/photopost/data/500/thumbs/c_warnings.jpg ('http://www.turbo-mopar.com/forums/photopost/data/500/c_warnings.jpg')

[risen]

This is what I have left to deal with after ignoring the strncpy errors. If Wowzer's VS2008 ver works with my 2005 ver, then I'll just leave this alone.


------ Build started: Project: lw2_lm_vdev, Configuration: Release Win32 ------
Compiling...
stdafx.cpp
Compiling...
lw2vdev1.cpp
lw2_lm_vdevDlg.cpp
.\lw2_lm_vdevDlg.cpp(595) : warning C4800: 'UINT' : forcing value to bool 'true' or 'false' (performance warning)
.\lw2_lm_vdevDlg.cpp(605) : warning C4244: '=' : conversion from 'double' to 'float', possible loss of data
.\lw2_lm_vdevDlg.cpp(626) : warning C4244: 'argument' : conversion from 'double' to 'int', possible loss of data
.\lw2_lm_vdevDlg.cpp(897) : error C3867: 'Clw2_lm_vdevDlg::close_in_error': function call missing argument list; use '&Clw2_lm_vdevDlg::close_in_error' to create a pointer to member
.\lw2_lm_vdevDlg.cpp(1084) : warning C4800: 'BOOL' : forcing value to bool 'true' or 'false' (performance warning)
.\lw2_lm_vdevDlg.cpp(1094) : warning C4800: 'BOOL' : forcing value to bool 'true' or 'false' (performance warning)
lw2_lm_vdev.cpp
Generating Code...
Build log was saved at "file://c:\Documents and Settings\Chris\My Documents\lw2_vdev\Release\BuildLog.htm"
lw2_lm_vdev - 1 error(s), 5 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
The bool warnings are because I was doing tests more in a C style than C++, they'll get fixed eventually. Also, I think the logworks object only wants doubles, so there's probably a few casts missing. The error about the number of args being passed to that function must be due to a typo or something. It wouldn't have compiled for me if that error was there when I built it. I'd double check the call against the source wowzer provides you. The header or function def may also help you sort it out.

[Stratman]

chris - i do not get the error message, but i do get the same warnings which should be addressed at some point. i'll email u my lw2_lm_vdevdlg.cpp file

http://www.turbo-mopar.com/forums/photopost/data/500/thumbs/c_setting.jpg ('http://www.turbo-mopar.com/forums/photopost/data/500/c_setting.jpg') http://www.turbo-mopar.com/forums/photopost/data/500/thumbs/c_warnings.jpg ('http://www.turbo-mopar.com/forums/photopost/data/500/c_warnings.jpg')


Thanks Morris. I will mess with them after lunch. Thanks very much for the help guys. Yesterday made my work day aggravating. Guess I shouldn't be messing with this during work hours! :)

[Stratman]

The error was found with the help of a co-worker. Thanks to Dustin, the IT guy who sits in a faintly lit glass room here at work!lol


return Clw2_lm_vdevDlg::close_in_error();

One of these lines were missing (). Once that was corrected everything started working. It looked like the ram_maps wasn't loading the choices in the dropdown combobox, I only had to resize the ram_map_combobox for the up/down scroll arrows and multiple choices to appear. I believe I did find where the address hits twice so I've commented one line out, see below. Will see if this works this evening leaving work.


//vdev->get_byte_sync(&(vdev->channels[i].address), &tmp);
vdev->get_byte_sync(&(vdev->channels[i].address), &tmp);
vdev->channels[i].value = vdev->parse_byte(i, tmp);
vdev ->lw2_vdev.SetValue(vdev->channels[i].ch_num_from_lw, vdev->channels[i].value);

[Stratman]

All is working well and it is no longer hitting an address twice. Here is a link to the portmon log. Is the "time" which portmon shows equal to wall clock time? If so, that equals 225 samples per second........

http://www.turbofreak.com/logs/1_address_hit_sample_test.LOG

[risen]

The error was found with the help of a co-worker. Thanks to Dustin, the IT guy who sits in a faintly lit glass room here at work!lol


return Clw2_lm_vdevDlg::close_in_error();

One of these lines were missing (). Once that was corrected everything started working.
It looked like the ram_maps wasn't loading the choices in the dropdown combobox, I only had to resize the ram_map_combobox for the up/down scroll arrows and multiple choices to appear. I believe I did find where the address hits twice so I've commented one line out, see below. Will see if this works this evening leaving work.


//vdev->get_byte_sync(&(vdev->channels[i].address), &tmp);
vdev->get_byte_sync(&(vdev->channels[i].address), &tmp);
vdev->channels[i].value = vdev->parse_byte(i, tmp);
vdev ->lw2_vdev.SetValue(vdev->channels[i].ch_num_from_lw, vdev->channels[i].value);


Horray for Dustin, let's hope they pay him what he's worth. :)

That commented line should do the trick.

The combo box issue is probably due to the horribly outdated and simplistic way I'm using the controls and displaying the dialog. The gui is one of the areas that needs major improvements.

[Stratman]

Horray for Dustin, let's hope they pay him what he's worth. :)

That commented line should do the trick.

The combo box issue is probably due to the horribly outdated and simplistic way I'm using the controls and displaying the dialog. The gui is one of the areas that needs major improvements.

Yes. Horay! Dustin actually started getting exited looking at something different than his daily coding for the company. He got to see the plungin in action on the Daytona after work and thought it was very cool. He'll help me Monday as well.

[risen]

All is working well and it is no longer hitting an address twice. Here is a link to the portmon log. Is the "time" which portmon shows equal to wall clock time? If so, that equals 225 samples per second........

http://www.turbofreak.com/logs/1_address_hit_sample_test.LOG

That is a pretty substantial improvement. While I'm sure it makes a hell of an improvement in terms of logging resolution there's still plenty of samples that take 3ms before the read call returns. Maybe I shouldn't be beating myself up over that, but there's still some overhead with the calls to flush/purge in the code. If you're still looking for an improvement you can try and take those out of the get_byte_sync.

Have you seen any issues with the channels getting mixed up (like a map value in the rpm channel, etc)? That's the main reason I coded it that way, the ftdi chip seemed to be giving me back values much later than I would have liked them and the program was putting the values in the wrong channel. If that's not an issue taking the flush/purge calls out probably won't hurt you. I'm not sure if that will help the amount of time it takes the ecu to respond but it'lll definitely take some of the overhead out of the problem.

[Stratman]

That is a pretty substantial improvement. While I'm sure it makes a hell of an improvement in terms of logging resolution there's still plenty of samples that take 3ms before the read call returns. Maybe I shouldn't be beating myself up over that, but there's still some overhead with the calls to flush/purge in the code. If you're still looking for an improvement you can try and take those out of the get_byte_sync.

Have you seen any issues with the channels getting mixed up (like a map value in the rpm channel, etc)? That's the main reason I coded it that way, the ftdi chip seemed to be giving me back values much later than I would have liked them and the program was putting the values in the wrong channel. If that's not an issue taking the flush/purge calls out probably won't hurt you. I'm not sure if that will help the amount of time it takes the ecu to respond but it'lll definitely take some of the overhead out of the problem.

I'll log more and see if anything funny is going on. It did show 3 IPW channels like they were each in the serial chain as separate devices, but I thought it may have been something funny with Logworks so maybe there is an issue. Truly, it is very fast in the first place. If there are issues I will have no problem adding the double d line back and try to work on something else like the GUI maybe.

[Stratman]

The replication of serial devices in LW seemed to be an effect of leaving VS open and recompiling the plug in. After a reboot LW has no issues and the plugin worked perfect hitting the addresses once. I ran 15 channels which logged perfect. Is there a limit to channels recorded?
The only issue I have is the plug in not saving the settings and addresses which were checked after logging and closing. Every time it is re-opened, all is back at default including com 0. I'll look at this.

[Stratman]

Still trying to find the issue with saving last used settings in the plug in.

[risen]

Still trying to find the issue with saving last used settings in the plug in.

The plugin writes the values to the registry when you hit the start button. I think it may also have something to do with the GUId of the application. Can you try and run the same version two or 3x? Just try and test it a few times over without recompiling it.

[Stratman]

Hmm, for some reason any changes made to my new compiled exe are saving to the original plug in exe. Do I need to delete the registry somewhere?

EDIT: When I delete all original files and re-extract the original zip file, it opens all previous settings. :confused:

[Stratman]

Just got back to messing with it tonight. I bet all newly compiled programs are not looking at the registry to retrieve the saved setting.

[Stratman]

Just got back to messing with it tonight. I bet all newly compiled programs are not looking at the registry to retrieve the saved setting.

Risen,
Is this how the program works when it opens? Everything works great except for the new compiled programs not retrieving last settings. If I unzip and open your compiled plug in, it retrieves the last settings from my compiled plug in.

[Stratman]

I guess I can only find things when I'm screwing off at work.lol
I found where it saves in the registry and also found where it reads in the cpp file. Maybe another 20 more hours of work to figure it out.:)

[risen]

Risen,
Is this how the program works when it opens? Everything works great except for the new compiled programs not retrieving last settings. If I unzip and open your compiled plug in, it retrieves the last settings from my compiled plug in.

It checks the registry to see if there are values, I believe, then loads them if they exist. I don't fully recall if I put more logic in than that, but it's all in the functions called by the start button.


I guess I can only find things when I'm screwing off at work.lol
I found where it saves in the registry and also found where it reads in the cpp file. Maybe another 20 more hours of work to figure it out.:)

I have a little time here myself today, so I'll take a look at it and see if I can give you a better idea of what may be the problem. You can search the registry for the keys given in the program, if you'd like to see if maybe there are multiple keys.

[Stratman]

It checks the registry to see if there are values, I believe, then loads them if they exist. I don't fully recall if I put more logic in than that, but it's all in the functions called by the start button.

I have a little time here myself today, so I'll take a look at it and see if I can give you a better idea of what may be the problem. You can search the registry for the keys given in the program, if you'd like to see if maybe there are multiple keys.

I found the keys in the registry today. My complied exe is definitely changing the registry, just not reading them. Opening my compiled exe presents an error titled "lw2_lm_vdev" stating "The parameter is incorrect". You think the conversion into VS 8 may have caused some of these issues I've been dealing with?

[risen]

I found the keys in the registry today. My complied exe is definitely changing the registry, just not reading them. Opening my compiled exe presents an error titled "lw2_lm_vdev" stating "The parameter is incorrect". You think the conversion into VS 8 may have caused some of these issues I've been dealing with?

All the registry functions are contained in the read_from_registry and write_to_registry functions. An example of one of the calls that tries to read the values from the registry is below. If the registry doesn't have a key for the item requested, it returns the last argument in the call (false for the example below) .

It basically tries to get the subkey for one of the "Enabled Channels". It's stuck in the for loop at the top of the function, and tries to iterate through all the short names, which are all in the init fucntion. If you didn't change anything in that function it's probably some sort of library or compatibility issue.

Do you get the error multiple times over or just 1x? Have you tried to either comment the call to read_from_registry or some of the calls in the function to see if it reduces the number of errors?

Maybe this is one of those things I need to look into line changing the strncpy calls to strncpy_s. Though, I'm not sure why the write calls would succeed and the read calls would fail.



Clw2_lm_vdevDlg::channels[i].enabled =
Clw2_lm_vdevDlg::pApp -> GetProfileInt(_T("Enabled Channels"),Clw2_lm_vdevDlg::snames[i],false)

[Stratman]

All the registry functions are contained in the read_from_registry and write_to_registry functions. An example of one of the calls that tries to read the values from the registry is below. If the registry doesn't have a key for the item requested, it returns the last argument in the call (false for the example below) .

It basically tries to get the subkey for one of the "Enabled Channels". It's stuck in the for loop at the top of the function, and tries to iterate through all the short names, which are all in the init fucntion. If you didn't change anything in that function it's probably some sort of library or compatibility issue.

Do you get the error multiple times over or just 1x? Have you tried to either comment the call to read_from_registry or some of the calls in the function to see if it reduces the number of errors?

Maybe this is one of those things I need to look into line changing the strncpy calls to strncpy_s. Though, I'm not sure why the write calls would succeed and the read calls would fail.



Clw2_lm_vdevDlg::channels[i].enabled =
Clw2_lm_vdevDlg::pApp -> GetProfileInt(_T("Enabled Channels"),Clw2_lm_vdevDlg::snames[i],false)


"The parameter is incorrect" error only appears once when the exe is opened. I will comment the read_from_registry out to see if it gets rid of the error all together.

When I changed all strncpy to strncpy_s last week there was a different warning when compiling, but that's when there was an error keeping the build to be compiled so I changed it back. I will try it again sometime. Would the MS SDK files play a major role with a function like this?

[risen]

"The parameter is incorrect" error only appears once when the exe is opened. I will comment the read_from_registry out to see if it gets rid of the error all together.

When I changed all strncpy to strncpy_s last week there was a different warning when compiling, but that's when there was an error keeping the build to be compiled so I changed it back. I will try it again sometime. Would the MS SDK files play a major role with a function like this?

I don't think anything should have changed that would have an effect on the registry calls. I checked msdn quickly and it looks the same, but I didn't really get in-depth with it.

The strncpy_s needs a max length and a buffer size, so if you only changed the call from strncpy to strncpy_s, it'll fail because there isn't an additional argument, you can give it the strlen()+1 call 2x over and it should be OK.

IDK why the win32 string functions are so painful. In unix strcpy == bad, strncpy == good and you only need 1 size argument.

[Stratman]

Stepping through this for a week! Problem fixed...

tmps = Clw2_lm_vdevDlg::pApp ->GetProfileString(_T("ECU Setting"),_T("Com Port"),_T("com0"));
for (int i=0; i < 6; i++)
Clw2_lm_vdevDlg::comport[i] = tmps[i];
Clw2_lm_vdevDlg::comport[6] = '\0';
Had to change to:

tmps = Clw2_lm_vdevDlg::pApp ->GetProfileString(_T("ECU
Setting"),_T("Com Port"),_T("com0"));
for (int i=0; i < 5; i++)
Clw2_lm_vdevDlg::comport[i] = tmps[i];
Clw2_lm_vdevDlg::comport[6] = '\0';

No more errors and all previous settings load fine. Now...I can move on.....

[risen]

Stepping through this for a week! Problem fixed...

tmps = Clw2_lm_vdevDlg::pApp ->GetProfileString(_T("ECU Setting"),_T("Com Port"),_T("com0"));
for (int i=0; i < 6; i++)
Clw2_lm_vdevDlg::comport[i] = tmps[i];
Clw2_lm_vdevDlg::comport[6] = '\0';
Had to change to:

tmps = Clw2_lm_vdevDlg::pApp ->GetProfileString(_T("ECU
Setting"),_T("Com Port"),_T("com0"));
for (int i=0; i < 5; i++)
Clw2_lm_vdevDlg::comport[i] = tmps[i];
Clw2_lm_vdevDlg::comport[6] = '\0';

No more errors and all previous settings load fine. Now...I can move on.....
Wow, why didn't I use strncpy. Man sorry about that one. That's on the list of items to fix, for certain. Though are you sure you don't get strange errors now since the index leaves a character untouched and places the null after it? I really should have uses strncpy or strncpy_s.

[Stratman]

Tested tonight with 12 channels enabled and works great. No errors at all with the exe or while compiling. There are many warnings though.

[Stratman]

Build log:
http://www.turbofreak.com/logs/compile/BuildLog.htm

[Stratman]

Wow, why didn't I use strncpy. Man sorry about that one.

No reason to apologize about providing a tool I have seriously needed since 2004!:D

[Stratman]

Thanks for jogging my memory. I'm 99% sure it's only taking the high byte. I think now that we can get the logging speed up by lowering the FTDI latency I'll have to do the 2 bytes for both RPM and MPH or at least give the option to do so.

What is the low byte for MPH from the 89 T-SMEC? Is it as simple as just changing address location?

[wowzer]

89 t-smec:

RPM - MSB=5d, LSB=5e
MPH - MSB=37, LSB=38

Rpm = ([5d] * 256 + [5e]) / 8
Mph = ([37] * 256 + [38]) / 64

[risen]

No reason to apologize about providing a tool I have seriously needed since 2004!:D

I know, but that bit of code was seriously boneheaded. I still don't recall why I did that. I just wish I could stop having things come up so I can at least give you some real answers. I'm totally swamped with work and school and husbandly duties :( .

[Stratman]

I know, but that bit of code was seriously boneheaded. I still don't recall why I did that. I just wish I could stop having things come up so I can at least give you some real answers. I'm totally swamped with work and school and husbandly duties :( .

Completely understood...That's why I want to contribute. Maybe you can help me with format for the following:

89 t-smec:

RPM - MSB=5d, LSB=5e
MPH - MSB=37, LSB=38

Rpm = ([5d] * 256 + [5e]) / 8
Mph = ([37] * 256 + [38]) / 64

Do we have to add another address box in the GUI for the MPH low byte?

//coolant temp
case 2:
ret = ((460.0/255.0) *(double)value) - 200.0;
break;

/*mph un-used
case 3:

break;
*/
//rpm
case 4:
ret = (double) value*32;
break;
Isn't this where the MPH formula will need to be inserted?
How will this need to be formatted? Mph = ([37] * 256 + [38]) / 64

[risen]

Completely understood...That's why I want to contribute. Maybe you can help me with format for the following:


Do we have to add another address box in the GUI for the MPH low byte?

//coolant temp
case 2:
ret = ((460.0/255.0) *(double)value) - 200.0;
break;

/*mph un-used
case 3:

break;
*/
//rpm
case 4:
ret = (double) value*32;
break;
Isn't this where MPH the formula will need to be inserted?
How will this need to be formatted? Mph = ([37] * 256 + [38]) / 64

Adding another box in for the low byte of MPH would be the best bet, but it's a bit of an undertaking. I'm not 100% sure what the index of the MPH variable is, but that case 3: needs to match it's index, I believe.

What you can do is in the man loop that gets the bytes back you can do the following if you don't want to screw with the gui stuff (even adding a text box can be extremely painful). I'm not sure if this is 100% correct or not but it's the basic idea:


if(i == MPH_INDEX)
{
vdev->get_byte_sync(&(vdev->channels[i].address), &tmp);
vdev->channels[i].value = (double)tmp * 256;
vdev->channels[i].address-=1;
vdev->get_byte_sync(&(vdev->channels[i].address), &tmp);
vdev->channels[i].value += (double) tmp;
vdev->channels[i].value /= 64.0;
vdev->channels[i].address+=1;
}


Otherwise, you will need to add stuff into the parse byte function to take into account the 2 different addresses. Basically, you want to store the high byte returned as it came back multiplied by 256. You can then store the low byte without changing it. After you've stored both bytes you need to divide the 2 bytes by 64 to get the mph value.

What I'm doing above is just to decrement the high byte address and grab the low byte, then make sure that you move the address back to be the high byte. It assumes that the value is a double and address is either char/unsigned char/int or something like that.

[Juggy]

i skimmed through the thread quickly, def need 2 read everything again

i have a couple questions i didnt see mentioned

im running an ostrich. do I still need a serial cable???

also if so where does the serial cable get wired into???

and if I need this serial cable. my laptop only has 1 USB out currently occupied by the ostrich, and 1 printer port that will be used for the LC-1

can I get a USB hub and have everything work simutaneously? or do I need a laptop with more ports :(

i checked the part # listed in the thread b4 and it had nothing 2 do with the cable. it just showed a little USB box that u can wire up yourself

there are 2 cables here, 1 has a bulkhead, the other is raw..whats best? im still not sure where this would get wired too or if i actually need it if my ostrich is already rigging the SMEC up to the laptop....

http://ca.mouser.com/ProductDetail/FTDI/TTL-232R-5V/?qs=sGAEpiMZZMt4a%252bVKO2jOrfSrr7sUIV2jkj0OYybDD/A%3d

http://ca.mouser.com/ProductDetail/FTDI/TTL-232R-5V-WE/?qs=sGAEpiMZZMt4a%252bVKO2jOrfSrr7sUIV2jl0%252bZBa sxjZs%3d

[risen]

i skimmed through the thread quickly, def need 2 read everything again

i have a couple questions i didnt see mentioned

im running an ostrich. do I still need a serial cable???

Yes


also if so where does the serial cable get wired into???

To the SCI port. If you have a LM you can wire it to the MCU on the board instead, like in the KB article.



and if I need this serial cable. my laptop only has 1 USB out currently occupied by the ostrich, and 1 printer port that will be used for the LC-1

can I get a USB hub and have everything work simutaneously? or do I need a laptop with more ports :(

You'll need the USB ports, I'd imagine that a USB hub will work just fine. And just so we're clear, you need the 9 pin serial port for the lc1. Most printer ports are 25 pins and won't work correctly.



i checked the part # listed in the thread b4 and it had nothing 2 do with the cable. it just showed a little USB box that u can wire up yourself

there are 2 cables here, 1 has a bulkhead, the other is raw..whats best? im still not sure where this would get wired too or if i actually need it if my ostrich is already rigging the SMEC up to the laptop....

http://ca.mouser.com/ProductDetail/FTDI/TTL-232R-5V/?qs=sGAEpiMZZMt4a%252bVKO2jOrfSrr7sUIV2jkj0OYybDD/A%3d

http://ca.mouser.com/ProductDetail/FTDI/TTL-232R-5V-WE/?qs=sGAEpiMZZMt4a%252bVKO2jOrfSrr7sUIV2jl0%252bZBa sxjZs%3d
The part number that gives you a board is essentially the same thing. The cable is just easier to deal with in mots cases. They both have the same chipset and function the same. Others here are using the cable, I just used the board because it was easier for me.

I'd say take the raw one from above. You'll probably end up soldering to the one with the bulkhead unless you're going to use the pins to connect it.

[Juggy]

Yes

To the SCI port. If you have a LM you can wire it to the MCU on the board instead, like in the KB article.


You'll need the USB ports, I'd imagine that a USB hub will work just fine. And just so we're clear, you need the 9 pin serial port for the lc1. Most printer ports are 25 pins and won't work correctly.


The part number that gives you a board is essentially the same thing. The cable is just easier to deal with in mots cases. They both have the same chipset and function the same. Others here are using the cable, I just used the board because it was easier for me.

I'd say take the raw one from above. You'll probably end up soldering to the one with the bulkhead unless you're going to use the pins to connect it.

good, i like it raw :eyebrows:

thanks!! wiring it to the SCI connector makes complete sense now....LOL. ill have to order the cable. i got the wideband to work with logworks and finally connect 2night (seems like a pain) one problem is it doesnt regcognize and save so it creates a new sensor profile everytime? im sure its no biggy.

the serial cable for the printer port is a 9 pin on my laptop. the cable for the innovate plugs right in. looks like i just need the USB to serial cable.

now where might i be able to find a female bulkhead for the SCI connector??

[risen]

good, i like it raw :eyebrows:

Shimmy-shimmy y'all, shimmy yeah, shimmy yea? :)

Lets see how long it takes someone to figure out that bit^ of obscurity. :)


thanks!! wiring it to the SCI connector makes complete sense now....LOL. ill have to order the cable. i got the wideband to work with logworks and finally connect 2night (seems like a pain) one problem is it doesnt regcognize and save so it creates a new sensor profile everytime? im sure its no biggy.

the serial cable for the printer port is a 9 pin on my laptop. the cable for the innovate plugs right in. looks like i just need the USB to serial cable.

now where might i be able to find a female bulkhead for the SCI connector??

IDK, maybe someone else around here knows where you can get the other 1/2. You could just grab 2 spade terminals and plug them into the sci connector and find some way of securing them. Also be aware that you need to have the TX/RX signals set to inverted for SMEC/SBEC usage and you should bring the latency setting discussed further above in this thread down to 1ms.

Some day I'll get to that full-on KB article.

[Juggy]

also i was trying to determine the com port for the USB on my laptop using usbview . exe

is the driver key the com port??

DriverKey: {36fc9e60-c465-11cf-8056-444553540000}\0004

im guessing this is com port 4??? how would I enter that address into your lw2_vdev???
is it possible to have a com port zero??

sorry for all the questions.



hey can I just cut off 1 end of a USB cable and wire it up ????? lol....

[Juggy]

Shimmy-shimmy y'all, shimmy yeah, shimmy yea? :)

Lets see how long it takes someone to figure out that bit^ of obscurity. :)


IDK, maybe someone else around here knows where you can get the other 1/2. You could just grab 2 spade terminals and plug them into the sci connector and find some way of securing them. Also be aware that you need to have the TX/RX signals set to inverted for SMEC/SBEC usage and you should bring the latency setting discussed further above in this thread down to 1ms.

Some day I'll get to that full-on KB article.

i almost spit my beer out all over the keyboard when i started reading this post....i hit enter and it showed right up, didnt even know you were here posting on the thread, thanks for the laugh!!! and help :)

ok so i only need 2 wire up 2 wires out of the 6 or whatever it is that comes out of the serial cable?? sounds good. yeah my car is SMEC.

[Juggy]

oohhh yeah im blowin this thread up


one thing. im not sure what resolution im running on the laptop (noticed u were asking about that earlier in the thread) but the screen for the vdev is HUGE and i have to move it as far up 2 the screen as i can, as well as unlock and hide my taskbar just so i can view it all.

do i need to change rez???? its an ibm thinkpad PIII 800mhz, old but trusty!

[risen]

oohhh yeah im blowin this thread up


one thing. im not sure what resolution im running on the laptop (noticed u were asking about that earlier in the thread) but the screen for the vdev is HUGE and i have to move it as far up 2 the screen as i can, as well as unlock and hide my taskbar just so i can view it all.

do i need to change rez???? its an ibm thinkpad PIII 800mhz, old but trusty!

Well, if you can get to all the buttons and checkboxes I guess you're ok and don't need to change the res. That is one thing I'm going to have to address over the winter.

[Stratman]

oohhh yeah im blowin this thread up


one thing. im not sure what resolution im running on the laptop (noticed u were asking about that earlier in the thread) but the screen for the vdev is HUGE and i have to move it as far up 2 the screen as i can, as well as unlock and hide my taskbar just so i can view it all.

do i need to change rez???? its an ibm thinkpad PIII 800mhz, old but trusty!

I have the same problem with my Dell max resolution so I've recompiled the plugin to fit. This version is also modified to hit an address only once which seems to work very well. PM me your email address and I'll send it to see if it will work fine on your end.

[Stratman]

i almost spit my beer out all over the keyboard when i started reading this post....i hit enter and it showed right up, didnt even know you were here posting on the thread, thanks for the laugh!!! and help :)

ok so i only need 2 wire up 2 wires out of the 6 or whatever it is that comes out of the serial cable?? sounds good. yeah my car is SMEC.

Yes, 2 wires used...TX and RX.
I bought an 8 pin round din connector to attach to my OTC scanner cable I already had in the car, but the blade terminals will work great.

[TopDollar69]

I actually modified my OTC and put a regular 9 pin serial connector on it like it should have had in the first place.

[Juggy]

i have the round 8 pin plug that has 3 wires coming out the one end....but no DRB lol.
kicking myself for not ordering a cable from xenocron when i ordered my ostrich!!! shoulda been paying more attention to this thread lol. oh well, seasons pretty much over anyway....

[risen]

OK, i'm ready to get the updates you guys want into the plugin now. So, listed below is what I'm planning on including in this release:

1) Ability to hit addresses 1x each instead of 2x. I'll probably make this configurable with a checkbox on the front screen.
2) Ability to use 2 bytes for RPM and MPH logging. Anyone have others that need to be made 2 bytes long?
3) I'm going to change the stupid copying of com port string to use strncpy_s
4) Change all strncpy functions to strncpy_s
5) Change GUI interface so that it's usable on 640x480 or 800x600 size screens and resizable
6) Add log to file option so that the plugin can dump values to CSV
7) Allow definable translations for output from ECU.

Anyone have any others they want to see added to the next release?

I really do appreciate the feedback, I want to provide something everyone will want to use, so please let me know what you'd like to see added or changed. There's no huge hurry for the responses, what I have above is going to take some work to implement, but if you'd like to see something above changed or expanded sooner is better than later so I don't have to implement something 2x :) .

[Stratman]

Thanks for the update!
Does any of that fix the signed outputs so LW could read it correctly?
Also if you could add an output field so we could have a choice to see the returned hex.

[risen]

Thanks for the update!
Does any of that fix the signed outputs so LW could read it correctly?
Also if you could add an output field so we could have a choice to see the returned hex.
I didn't explicitly add it up there, but I do intend on adding a configuration setting for each byte to say whether it's signed or not.

Would you like an option that dumps the raw hex value(s) received to the text log file? Or do you want it both sent to logworks and dumped to the text log?

[Stratman]

I didn't explicitly add it up there, but I do intend on adding a configuration setting for each byte to say whether it's signed or not.

Would you like an option that dumps the raw hex value(s) received to the text log file? Or do you want it both sent to logworks and dumped to the text log?

No, we don't need both at the same time. If the signed issue gets fixed to LW there is really no need for the dump unless hex can be translated into a scaled value and become a csv for stand alone purposes for vehicles without the wideband unit which would make the plug in a powerful tool since it works so well. If an output can be scaled (or not), an option for viewing real time output next to each address would be very handy for tuning in fuel adaptives ..etc.. on the fly.
On another note, will we always have to close and re-open the program if LW is stopped?

[risen]

No, we don't need both at the same time. If the signed issue gets fixed to LW there is really no need for the dump unless hex can be translated into a scaled value and become a csv for stand alone purposes for vehicles without the wideband unit which would make the plug in a powerful tool since it works so well. If an output can be scaled (or not), an option for viewing real time output next to each address would be very handy for tuning in fuel adaptives ..etc.. on the fly.
On another note, will we always have to close and re-open the program if LW is stopped?

Well, I plan on letting the scaling be selectable on/off per variable, so if you shut it off you'll get a raw 0-255 value in the output like you do now for most variables.

I do plan on updating my winlog plugin too, that's good for people who don't have an innovate wideband. But that'll probably be in the late spring or summer of next year by the time I get to it.


Yes, you'll always need to restart the plugin if logworks is stopped. I don't think there's any way around that without me giving an interface to delete and recreate the object that connects the 2 programs, and I'm not even sure that'll work. It's due to the way Innovate provided the device driver for the plugins.

[Stratman]

Well, I plan on letting the scaling be selectable on/off per variable, so if you shut it off you'll get a raw 0-255 value in the output like you do now for most variables.

Sounds good.


I do plan on updating my winlog plugin too, that's good for people who don't have an innovate wideband. But that'll probably be in the late spring or summer of next year by the time I get to it.

Ok. I guess I have just been biased toward the plug in since it works every time I want it too. I guess I need to look at Winlog or SMEClog for such occasions.



Yes, you'll always need to restart the plugin if logworks is stopped. I don't think there's any way around that without me giving an interface to delete and recreate the object that connects the 2 programs, and I'm not even sure that'll work. It's due to the way Innovate provided the device driver for the plugins.

I see.

[Stratman]

Is there a way to add a decent size button (shortcut) within the plugin to open Logworks after starting the plugin? Could have a user input to browse and set the LW program location to assign what exe to open. This is just one of those little things to help opening everything in a hurry at stop lights.
Thanks for taking our input! :D

[risen]

Is there a way to add a decent size button (shortcut) within the plugin to open Logworks after starting the plugin? Could have a user input to browse and set the LW program location to assign what exe to open. This is just one of those little things to help opening everything in a hurry at stop lights.
Thanks for taking our input! :D

That should be very easy to do. I'll add it to the todo list.

[risen]

Just so everyone knows, I'm working on this slowly but surely. I've decided to mostly gut the code and go for a more proper object oriented approach. IDK how long it's going to take, but it might be spring before the rewrite sees the light of day.

[ShelGame]

Any updates to the plugin?

Also, I tried running the current plugin on my Netbook and the plugin screen is too large for me to even see the 'start' button. So, it's unusable on a netbook. How hard would it be to shrink the plugin display down to fit a 1024 x 600?

[risen]

Any updates to the plugin?

Also, I tried running the current plugin on my Netbook and the plugin screen is too large for me to even see the 'start' button. So, it's unusable on a netbook. How hard would it be to shrink the plugin display down to fit a 1024 x 600?

Nothing in a workable form yet. I've got such a backlog after this semester and moving for the 2nd time in 2 years it's a little crazy. Basically the code to handle encapsulation of each variable or value from the ecu is mostly done. The code to handle connection to the ECU is nearly done. So, I have the GUI interface to rewrite and chase the bugs out of the whole thing. I doubt the rewrite will be done before 2012.

So, with that said, I can try and look into making the screen on the current application resizable so at least you guys with netbooks can use it. I have finals this week so I'll try to see if I can get it in sometime next week. If you don't get an update from me in the next 2 or 3 weeks please post here or PM me, just in case I forget.

[CNH320]

i was messing around with this last night and got it working but for some reason if i check more than 4 channels in the plug-in, when i load up logworks it doesnt bring in any of the channels. If i back off to only 4 channels it works fine. I only have version 3 of logworks, could that be the problem?

[risen]

i was messing around with this last night and got it working but for some reason if i check more than 4 channels in the plug-in, when i load up logworks it doesnt bring in any of the channels. If i back off to only 4 channels it works fine. I only have version 3 of logworks, could that be the problem?
Are you using the regular install with a lm-1/lc-1 or other innovate device? Or are you using the stim .dll to get around having to use an innovate device? I only had a problem with a limited number of channels using the stim .dll. It's more or less a known issue that I'm not going to be able to solve since, as far as I can tell, it's the limitation is somewhere in the innovate software.

[CNH320]

Yep I was using the modified STIM.DLL as i dont have my Innovate WB installed yet but i wanted to check out the plug-in. Thanks!

[risen]

Yep I was using the modified STIM.DLL as i dont have my Innovate WB installed yet but i wanted to check out the plug-in. Thanks!
Glad no one spent too much time on that :). You should be able to have as many channels as you'd like once you get start using the regular Innovate device and normal .dll. Also, if you're using one of the USB->serial adapters, make sure you check out the USB thread from a few months ago. Reducing the latency on the USB devices makes a huge difference in the performance of the logging.

[CNH320]

Yep, read through that USB thread a few times, i think its configured right. I was unaware of the channel limiting with the modified .DLL though. Must've missed that "known issue" Obviously... Thanks.

[zin]

Now that I'm getting close to logging, I was wondering a couple of things...

First, since we are getting close to 2012 I was curious as to the progress (as in will I be able to use it soon!)

Second, will this work with a non-Innovate (read AEM) wide-band O2?

Thanks for all the effort

Mike

[risen]

Now that I'm getting close to logging, I was wondering a couple of things...

First, since we are getting close to 2012 I was curious as to the progress (as in will I be able to use it soon!)

Depends, I think it's usable as-is but due to the way I have the screen laid out etc, some people with netbooks or who have their resolution set really low (< 1024x768) have a hard time with the interface. That's the primary problem with it that I see at the moment. I do want to make it better both in terms of performance and the user interface, but I always have something that seems to come up just a few weeks before I'm going to tear into the code again.



Second, will this work with a non-Innovate (read AEM) wide-band O2?

Thanks for all the effort

Mike

No, it's innovate only. Logworks has to talk to the WB directly and they only have it setup to talk to their WB controllers.

[Aries_Turbo]

for those with zeitronics zt2 widebands use this

http://www.devtechnics.com/winlog.htm

risen wrote a LM plugin for winlog. works well.

http://www.turbo-mopar.com/forums/showthread.php?36011-My-WinLog-Dashboards&p=466757#post466757

Brian