Well, it's down to the registry entries. That's the one thing it does on the 1st startup. Are you comfortable with regedit?
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.Originally Posted by risen
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.sure i guess lol. as long as it doesn't mess with my operating system im good.
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.
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.
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-dat...-kit-p-72.html
Thanks
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.
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).
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
Thanks
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.
Last edited by risen; 11-07-2009 at 11:13 AM. Reason: comma overkill
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?
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).
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.
Ok im having issues with this. I bought this cable, http://www.ftdichip.com/Products/Eva...s/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???
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.
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.Ok im having issues with this. I bought this cable, http://www.ftdichip.com/Products/Eva...s/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???
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
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.Its the 5v one, TTL-232R-PCB shown in the picture
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
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).
It works!!!
I uninstalled my usb drivers with the FTDI Clean Utility like it said to do here. I restarted my computer and plugged in the cable, the "install new hardware" window came up and I directed it to install the drivers 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?
Posting Permissions
Reply With Quote
