Logworks plugin for logic modules

[risen]

I'm glad to say that I've finally gotten the logic module plugin re-written in C++ and built to the point where I think others can make use of it. The zip file attached to this thread contains the whole visual studio project in case anyone is interested in messing with it further. In order to make use of this plugin you need to meet 2 criteria:

1) You must have a Logic Module with either a serial interface or USB interface

2) You must have an Innovate LC-1, LM-1, or other Innovate wideband O2 controller

To use the plugin you need to connect you laptop to the car with one com port connected to your wideband and the LM connected. The logworks plugin (which is the lw2_lm_vdev.exe file under the Debug directory in the zip archive) should be started. Once the application starts you need to select which variables you want to log, enter the com port on which your PC is connected to the LM, make sure the addresses are correct and hit the start button. You should see the status text field start flipping pretty quickly if all goes well.

You can then start up logworks, and select the com port your wideband is connected to. You can then go in and you should be able to see the channels you selected in the config screen under the 'Edit Channels' menu. You can go and add gauges and start logging.

I've only had about 30 minutes of testing on this program this weekend but it was working pretty well. I made some small tweaks which haven't been tested but they *shouldn't* have any effect on the running of the code.

The 16 bit values don't work at the moment, and only TPS, MAP, CLT, RPM, and Pulsewidth values are parsed properly. Everything else will return 0-255 and you will have to map it yourself inside logworks.

If anyone tries this program and has problems please LMK. If you want me to help you troubleshoot it, you're going to need portmon and provide me the output of portmon while running the program, so be prepared to go back and forth a few times.

PS: I had to take some of the build files out of the .zip for it to be uploadable. The program should run without them, but I just want to make everyone aware just in case.
PPS: I also haven't tried this program on a system without the development environment so hopefully it won't bomb due to missing debug libraries.

UPDATE:
The debug libraries were causing the program to not run on systems without visual studio. Attached is version in the Release folder of zip file that should run on any windows system without library problems. Source code is same and still included in this version. I'm still working on the version with smec/sbec/autoid support.

UPDATE 20090604: I've built the logworks module with static MFC links. This means it shouldn't complain about .dll files *at all*. I'm still working on the autoid driver, but this should be good for the LM folks now.

[jpcturbo]

Will the project compile under the express versions of Visual Studio? I am just about finished with installing the LC-1 on my SMEC turbo van. It looks like there are only a few changes to make to get the driver to talk to a SMEC. (nobody's done this already, right?)

[risen]

I haven't done any smec mods, since I haven't even looked at the smec I was going to use for bench testing. That, and you can see how much help I've been to Rob for his bench testing, . You'll probably only have to rewrite the init_serial function and maybe the addresses for smec support, unless you want to extend the whole thing to support both LM and smec. It won't support 16bit return values out of the box due to the way I've staggered the reads and writes.

You should be able to compile it with the free versions of Visual c++. I wrote it on visual studio .net, which I believe is VC7 or VS 2002 or some such, so you may have to upgrade the project. LMK if you need a hand with some of the code, I wrote it all over the past 2 or 3 weeks and only tested it this weekend, so there's sure to be some nastyness and things that could be done more efficiently in there.

[ShelGame]

Originally Posted by jpcturbo

Will the project compile under the express versions of Visual Studio? I am just about finished with installing the LC-1 on my SMEC turbo van. It looks like there are only a few changes to make to get the driver to talk to a SMEC. (nobody's done this already, right?)

I looked at it - it should be pretty simple to get it to work for a DRB-I SMEC (T2 SMEC, that is). But, it would need more work for the DRB-II SMEC's and SBEC's. Baud rates are different, protocol is slightly different, etc.

[risen]

All the serial stuff is in the init_serial and get_byte functions. I'm not sure what the protocol for the DRB-II is, but I'd think those are the only 2 functions that'll need changes. Unless you want to remove the delayed read setup, which would greatly simplify the code, but require a larger re-write of the main processing function.

[ShelGame]

I shouldv'e said I've looked at your WinLog driver to modify for SMEC usage. I haven't actually lookd at this driver code yet.

I had wanted to incorporate the Auto-ID function I built into MiniDash and try to make a kind of 'universal' Chrysler driver. But, that may be (Ha! more probably IS) beyond my time/talent. Certainly in C++...

[risen]

Originally Posted by ShelGame

I shouldv'e said I've looked at your WinLog driver to modify for SMEC usage. I haven't actually lookd at this driver code yet.

I had wanted to incorporate the Auto-ID function I built into MiniDash and try to make a kind of 'universal' Chrysler driver. But, that may be (Ha! more probably IS) beyond my time/talent. Certainly in C++...

The code between the 2 drivers is almost identical as far as serial comms is concerned, but almost all the other stuff is different. The winlog driver is actually much cleaner and shorter. I went out of my way to make the logworks one easier to extend and modify and will probably bring some fo that back to the winlog driver.

If you can explain to me how to do the auto id and how to decipher it (and connect to the various incarnations of the ECU), I can try and implement it. Is the auto-id a SMEC/DRB-II only thing since the base baud rates are different for the SMEC and the LM?

Jeff did explain how to connect to the SMEC a while ago. I still have the emails, but I haven't taken a crack at it. It's really hard for me to do SMEC since I don't have a SMEC based car to test it on.

[ShelGame]

Originally Posted by risen

The code between the 2 drivers is almost identical as far as serial comms is concerned, but almost all the other stuff is different. The winlog driver is actually much cleaner and shorter. I went out of my way to make the logworks one easier to extend and modify and will probably bring some fo that back to the winlog driver.

If you can explain to me how to do the auto id and how to decipher it (and connect to the various incarnations of the ECU), I can try and implement it. Is the auto-id a SMEC/DRB-II only thing since the base baud rates are different for the SMEC and the LM?

No, there's an Auto-ID function in the DRB code in every generation of ECU. In MiniDash, I built a database containing the Cal ID, what variable mapping it uses. When I wrote the AutoID function for MiniDash, I started with the DRB-II SMEC's becuase the baud rate is so high, I didn't think the DRB-I ECU's would be confused and send a response. If AutoID doesn't get a reply, then it tries the T2 DRBI protocol (different baud rates from the LM), if it doesn't get a reply, then it assumes LM DRBI protocol. With my code I also tried the hi-speed logger mod baud rates (9600/9600) to see if it could AutoID. But, I don't think anyone else uses that so it's not really necessary these days. Once I got the ID, I setup the variable mapping (also stored in a database) automatically.

Can you read VB? If you want, I can load up my HB++ code module. If you can't read it, I can convert the AutoID function to psudocode for you, I guess. I can also post my Cal ID and variable MAP databases.

If you can build a universal driver, I think that would be great. I've been wanting to use this software for my race car. And, I'm sure I'm not alone.
I had wanted to do it myself, but I'm going to be swamped (hopefully) making flashable SMEC's and SBEC's this summer.

[ShelGame]

Here's my HB++ Serial code. Let me know if this is too hard to read. I'm by no means a professional code writer...

Some of the code is obvioulsy Palm-specific (com port setup for example)...

Public Const iTimeout as Integer = 100 
Public LoBaud as Long
Public HiBaud as Long

Public sECU_ID as String

Public SI as SystemInfo

Private sCom as New StreamSerial

Public HiSpeedMode as Boolean

' ------------------------------------------------------

Public Function OpenSerial(byVal BaudRate as Long) as Boolean

	Try
		If SI.VersionMajor < 4 then 'this should fix the serial port problem on the older devices
 	  	sCom.Open &H00008000,BaudRate
 	 Else
 	  	sCom.Open &H00008003,BaudRate
 	 End If

		sCom.BitsPerChar = 8
		sCom.Parity = hbParityNone
		sCom.StopBits = 1
		sCom.FlowControl = &H0000 'clear all flow control bits

		OpenSerial = True

	Catch
		OpenSerial = False
	End Catch

End Function

'------------------------------------------------------

Public Function CloseSerial() as Boolean

	Try
		sCom.Close
		CloseSerial = True

	Catch
		CloseSerial = False
	End Catch

End Function

' ------------------------------------------------------

Public Function GetHiSpeedData (ByVal bAddy as Byte) as Byte
' this transfers data using the high-speed serial logger routine...

	Dim j as Integer
	Dim b as Byte

	Try
		sCom.Write  bAddy
	  sCom.Flush hbStreamWrite

	  For j = 1 to iTimeout
			If sCom.Ready(hbStreamRead)>0 Then
				sCom.Read  b
				sCom.Flush hbStreamRead 'I wonder if this slows things down...
				GetHiSpeedData = b
				Exit For ' otherwise, GetHiSpeedData is written over on the next loop...
			Else
				GetHiSpeedData = 0
			End If
		Next j

	Catch
		GetHiSpeedData = 0
	End Catch


End Function

' ------------------------------------------------------

Public Function SetHiSpeed() as Boolean
' this routine sets the ECU into high speed mode

Dim i as Boolean 'hi speed mode command OK
Dim j as Boolean 'hi speed mode confirmed OK

SetHiSpeed = False

' first, check for hi-speed mode on the ECU...

If OpenSerial(LoBaud) = True Then 'this should help speed things up a bit when not connected...

	i = true 'for now, assume we're in hi speed mode

	Select Case Prefs.SerialMod
		Case False
			' this segment is just to confirm high-speed mode with the ECU
			Select Case Prefs.MemMap
				Case 1, 3 'T2/S60 SMEC
					j = TxCmd(&hF2) 'test if the ECU is already in hi-speed mode
					If j = False then 'set to hi speed mode
						i = TxCmd_RxByte(&h12)
						CloseSerial
						OpenSerial(HiBaud)
						j = TxCmd(&hF2)'try to confirm hi-speed mode...
					End If
			 	Case 2, 8, 9 'LM
					j = TxCmd(&h12) 'test if the ECU is in hi-speed mode
					If j = False then 're-send command to set hi-speed mdoe
						i = TxCmd_NoEcho(&h12)
						CloseSerial
						OpenSerial(HiBaud)
						j = TxCmd(&h12)
					End If
				Case 4 to 7, 10 'T1 SMEC/All SBEC
					i = TxCmd(&h12)
					CloseSerial
					OpenSerial(HiBaud)
					j = TxCmd(&hF2)'try to confirm hi-speed mode...
			End Select
		Case True 'hi speed serial code is present
			j = True
	End Select

Else
	i = false
	j = false
End If

If i = True and j = True then
	SetHiSpeed = True
End If

'	 MsgBox ("Set Hi Spd Routine",hbMsgBoxOKOnly)

End Function

' ------------------------------------------------------

Public Function SetLoSpeed() as Boolean
' this routine returns the ECU to normal (low-speed) mode
' Ths routine assumes the serial port is already open and in Hi-Speed mode...

Dim i as Boolean

Select Case HiSpeedMode
	Case True
		i = TxCmd(&hFE)' this command should work for LM, T2 SMEC, and T1 SMEC/SBEC --- !!! need to confirm this command !!! ---
		If i = True then
			SetLoSpeed = True
			HiSpeedMode = False
		Else
			SetLoSpeed = False
			HiSpeedMode = True
		End If
	Case False
		SetLoSpeed = True
End Select

CloseSerial

End Function

' ------------------------------------------------------

Public Function SmecID() as String
' this function returns the ID of the SMEC
' confirmed working, don't change it !!!

	Dim bCmdID as Byte
	Dim bAddr as Byte
	Dim temp as String
	Dim b1 as Byte
	dim b2 as Byte

	bCmdID = &h16 '"get ID" command
	bAddr = &h02 'start of the ID code

	LoBaud = 7812
	HiBaud= 62500

	SmecID = "0000"
	If OpenSerial(HiBaud) = False then Goto ERR
	SetLoSpeed
	If OpenSerial(LoBaud) = False then Goto ERR

	' Get 1st byte
	If TxCmd(bCmdID) = False then Goto ERR
	sCom.Flush hbStreamRead
	If TxCmd(bAddr) = False then Goto ERR
	b1 = RxByte

	' get 2nd byte
	If TxCmd(bCmdID) = False then Goto ERR
	sCom.Flush hbStreamRead
	If TxCmd(bAddr+1) = False then Goto ERR
	b2 = RxByte

	temp = Hex(b1) & Hex(b2)

	Select Case temp
		Case "","0","00","000"
			SmecID = "0000"
		Case Else
			SmecID = temp
	End Select

ERR:
	CloseSerial

End Function

' ------------------------------------------------------

Public Function SmecID_T2() as String
' this function returns the ID of the T2 SMEC

	Dim bCmd as Byte
	Dim temp as string
	Dim i as Integer

	bCmd = &hF9 '"get ID" command <-- this command may need to be at hi-speed; need to flash T2 code and try in car

	Prefs.MemMap = 1 'temporary definition to trick the SetHiSpeed routine
	Prefs.SerialMod = False

	LoBaud = 976
	HiBaud = 62500

	SmecID_T2 = "0000"

	If SetHiSpeed = False Then Goto Err

	Sleep (100)
	sCom.Flush hbStreamRead

	For i = 1 to 2
		If TxCmd_NoEcho(bCmd) = False then Goto Err
	Next i

	temp = Mid(Hex(RxLong),1,4)

	Select Case temp
		Case "","0","00","000"
			SmecID_T2 = "0000"
		Case "FFFF"
			SmecID_T2 = "0000"
		Case Else
			SmecID_T2 = temp
	End Select

ERR:
	CloseSerial

End Function

' ------------------------------------------------------

Public Function LmID() as String
' this function returns the ID of the LM

	Dim bCmd as Byte
	Dim temp as String
	Dim i as Integer

	bCmd = &hFA '"get ID" command

	Prefs.MemMap = 2 'temporary definition to trick the SetHiSpeed routine
	Prefs.SerialMod = False

	LoBaud = 976
	HiBaud = 7812

	LmID = "0000"

	If SetHiSpeed = False Then Goto ERR

	Sleep (100)
	sCom.Flush hbStreamRead

	For i = 1 to 2
		If TxCmd_NoEcho(bCmd) = False then Goto ERR
	Next i

	temp = Mid(Hex(RxLong),1,4)

	Select Case temp
		Case "","0","00","000"
			LmID = "0000"
		Case "FFFF"
			LmID = "0000"
		Case Else
			LmID = temp
	End Select

ERR:
	CloseSerial

End Function

' ------------------------------------------------------

Public Function SerModID() as String

	Dim bCmd as Byte
	Dim b as Byte

	bCmd = &h00 'base address, return value should be either 00, AA, or 5A...
	LoBaud = 9600
	HiBaud = 9600

	SerModID = "0000"

	If OpenSerial(LoBaud) = False then Goto ERR

	If TxCmd_NoEcho(bCmd) = False then Goto Err

	b = RxByte

	Select Case b
		Case &hAA, &h5A, &hA5
			SerModID = "HiSp"
		Case Else
			SerModID = "0000"
	End Select

ERR:
	CloseSerial
End Function

' ------------------------------------------------------

Public Function ECU_ID() as String

Dim Temp as String

' here, try the 3 different protocols to get the ECU ID

'MsgBox ("Trying SMEC/SBEC ID",hbMsgBoxOKOnly)

Temp = SmecID 'LmID <-- reversed order...
If Temp = "0000" then 'if the LmID routine sends back "0000" - ie no ID or no coms
'	MsgBox ("Trying T2 SMEC ID",hbMsgBoxOKOnly)
	Temp = SmecID_T2
	If Temp = "0000" then
'		MsgBox ("Trying LM ID",hbMsgBoxOKOnly)
		Temp = LmID 'SmecID
			If Temp = "0000" then
'				MsgBox ("Trying SerMod ID",hbMsgBoxOKOnly)
				Temp = SerModID
			End If
	End IF
End If

	If Temp = "" Then
		ECU_ID = "0000"
	Else
		ECU_ID = Temp
	End If

'		 MsgBox ("ECU ID = " & ECU_ID,hbMsgBoxOKOnly)

End Function

' ------------------------------------------------------

Private Function TxCmd(bCmd as Byte) as Boolean
' this routine sends a command byte and waits for an echo. If echoed, the result is 'true'
' this assumes the serial prt has already been opened using "OpenSerial"

	Dim b as Byte
	Dim j as Integer
	Dim i as Integer

	sCom.Flush hbStreamRead 'flush any bytes that might be waiting

	Try
		For i = 1 to 5
			sCom.Write  bCmd
			Sleep (100) 'pause to wait for the return byte
			For j = 1 to iTimeout
 				If sCom.Ready(hbStreamRead)>0 Then
					sCom.Read  b
					If b <> bCmd then 'the command byte was NOT echoed back
						TxCmd = False
						Goto Finished
					Else 'the command byte was echoed back
						TxCmd = True
						Goto Finished
					End If
				End If
			Next j
		Next i
		Finished:
		sCom.Flush hbStreamWrite
	Catch
		TxCmd = False
	End Catch

End Function

' ------------------------------------------------------

Private Function TxCmd_NoEcho(bCmd as Byte) as Boolean
' This assumes the serial port has already been opened using "OpenSerial"
' Function returns the data (as a string) rx'd from the SMEC

	sCom.Flush hbStreamRead 'flush any bytes that might be waiting

	Try
		sCom.Write  bCmd
		TxCmd_NoEcho = True
	Catch
		TxCmd_NoEcho = False
	End Catch

	sCom.Flush hbStreamWrite

End Function

' ------------------------------------------------------

Private Function TxCmd_RxByte(bCmd as Byte) as Boolean
' this routine sends a command byte and waits for an echo, but not the command.
' this assumes the serial prt has already been opened using "OpenSerial"

	Dim b as Byte
	Dim j as Integer
	Dim i as Integer

	sCom.Flush hbStreamRead 'flush any bytes that might be waiting

	Try
		For i = 1 to 5
			sCom.Write  bCmd
			Sleep (100) ' was set to 100; pause to wait for the return byte
  		For j = 1 to iTimeout
				If sCom.Ready(hbStreamRead)>0 Then
					sCom.Read  b
					TxCmd_RxByte = True
					Exit For
				End If
			Next j
		Next i
		sCom.Flush hbStreamWrite
	Catch
		TxCmd_RxByte = False
	End Catch

'  msgbox (b,hbMsgBoxOKOnly)

	sCom.Flush hbStreamRead

End Function

' ------------------------------------------------------

Private Function RxByte () as Byte
' returns a single hex byte
' assumes that the serial port has already been opened by the calling routine

Dim i as Integer

Try
	For i = 1 to iTimeout
		If sCom.Ready(hbStreamRead) > 0 then
			sCom.Read RxByte
			Exit For
		End If
	Next i
Catch
	RxByte = 0
End Catch

'msgbox (RxByte,hbMsgBoxOKOnly)

sCom.Flush hbStreamRead

End Function

' ------------------------------------------------------

Private Function RxLong () as Long
' returns a long integer Rx'd from the serial port
' assumes that the serial port has already been opened by the calling routine

Dim i as Integer

Try
	For i = 1 to iTimeout
		If sCom.Ready(hbStreamRead) > 1 then
			sCom.Read RxLong
			Exit For
		End If
	Next i
Catch
	RxLong = 0
End Catch

sCom.Flush hbStreamRead

End Function

' ------------------------------------------------------

[risen]

Originally Posted by ShelGame

No, there's an Auto-ID function in the DRB code in every generation of ECU. In MiniDash, I built a database containing the Cal ID, what variable mapping it uses. When I wrote the AutoID function for MiniDash, I started with the DRB-II SMEC's becuase the baud rate is so high, I didn't think the DRB-I ECU's would be confused and send a response. If AutoID doesn't get a reply, then it tries the T2 DRBI protocol (different baud rates from the LM), if it doesn't get a reply, then it assumes LM DRBI protocol. With my code I also tried the hi-speed logger mod baud rates (9600/9600) to see if it could AutoID. But, I don't think anyone else uses that so it's not really necessary these days. Once I got the ID, I setup the variable mapping (also stored in a database) automatically.

Can you read VB? If you want, I can load up my HB++ code module. If you can't read it, I can convert the AutoID function to psudocode for you, I guess. I can also post my Cal ID and variable MAP databases.

If you can build a universal driver, I think that would be great. I've been wanting to use this software for my race car. And, I'm sure I'm not alone.
I had wanted to do it myself, but I'm going to be swamped (hopefully) making flashable SMEC's and SBEC's this summer.

Reading VB is no problem, writing it makes me want to break my fingers off, though .

I can try adding something like what you have above to the Logworks plugin. I'd like to keep the ability for the user to set the address by hand, so I may set it up so that you can either use auto-id, or set the addresses and comms type with a checkbox/radio button.

The only other question I have at this point, is are there a lot of 16bit variables that the SMEC/SBEC will return and do they have to be requested 1 byte at a time like the LM?

So are you signing up to be be the official tester for the smec/sbec part of the program?

[ShelGame]

Originally Posted by risen

Reading VB is no problem, writing it makes me want to break my fingers off, though .

I can try adding something like what you have above to the Logworks plugin. I'd like to keep the ability for the user to set the address by hand, so I may set it up so that you can either use auto-id, or set the addresses and comms type with a checkbox/radio button.

The only other question I have at this point, is are there a lot of 16bit variables that the SMEC/SBEC will return and do they have to be requested 1 byte at a time like the LM?

So are you signing up to be be the official tester for the smec/sbec part of the program?

SMEC, sure. The only SBEC car I have access to is a Spirit R/T. Maybe not the best test bed.

I actually had an option that if the CalID wasn't in my database, then the user was prompted to enter the cal info (Car, engine, application, etc.) and the variable map (memory map or 'MemMap' in my code above).

The only 2 byte variable I got was speed. RPM seems to me to be accurate enough (for anything you'd care to do with it; 32rpm reolution) just pulling in the high byte. Speed, though, only gives a 4mph resolution in the high byte. So, you really want both. I pulled them both in (separately, the 0x12 command only allows single byte reads), then combined them and re-scaled them to a 0-255mph signal and I saved/displayed this altered signal.

[risen]

Ok, the only 2 byte ones I had supported in the past are RPM, (which I thought had a 255 rpm resolution on the LM), MPH (which is as you mentioned it above), and pulsewidth. I was also really only worried about the upper byte for PW, since 255 usec of fuel seems like it amounts to a rounding error off idle. I was a bit concerned because of the RXLong function.

Do you have the memory maps available?

[ShelGame]

Originally Posted by risen

Ok, the only 2 byte ones I had supported in the past are RPM, (which I thought had a 255 rpm resolution on the LM), MPH (which is as you mentioned it above), and pulsewidth. I was also really only worried about the upper byte for PW, since 255 usec of fuel seems like it amounts to a rounding error off idle. I was a bit concerned because of the RXLong function.

Do you have the memory maps available?

I think I only used the RxLong function for the LM and T2 SMEC AutoID functions. That's because the DRB function for those automatically sends both bytes of the Cal ID. That's the only place I use that function. The DRBII AutoID function only sends 1 byte, so you have to ask for both bytes of the CalID.

The hi speed logging function (0x12) only allows for single byte retrievals anyway.

If you get confused about the different functions (TxCmd, TxCmd_noEcho, etc.) let me know. The DRB functions are a little odd in that there isn't really a set standard as to which functions echo the command and which just send back data.

I also have a complete listing of the DRBII functions and codes, if you wanted to do more than just logging. There's a way to reset error codes, for example. Switch tests, actuator tests, etc. I don't know how advanced you want to get (or can get within the LogWorks environment).

I'll post that with the databases I mentioned later tonight when I get down to the basement. I do have a large number of memory maps (variable maps). I think I identified 7 different maps from 85 thru 91.

EDIT: Zip file added. The nomenclature in the address table file is setup for transfer to a Palm database. The 'category' is what I used as the memory map ID inside MiniDash. I now have a complete memory map for the VNT and T3 cals, but I need to put them into this sheet.

[risen]

Originally Posted by ShelGame

I think I only used the RxLong function for the LM and T2 SMEC AutoID functions. That's because the DRB function for those automatically sends both bytes of the Cal ID. That's the only place I use that function. The DRBII AutoID function only sends 1 byte, so you have to ask for both bytes of the CalID.

The hi speed logging function (0x12) only allows for single byte retrievals anyway.

Ok, I just wasn't sure how much (or if) the RxLong function was used in the main loop to read from the ECU.

Originally Posted by ShelGame

If you get confused about the different functions (TxCmd, TxCmd_noEcho, etc.) let me know. The DRB functions are a little odd in that there isn't really a set standard as to which functions echo the command and which just send back data.

I also have a complete listing of the DRBII functions and codes, if you wanted to do more than just logging. There's a way to reset error codes, for example. Switch tests, actuator tests, etc. I don't know how advanced you want to get (or can get within the LogWorks environment).

I think the codes and diag functions are probably better left for a seprate application. There's a fair amount stuff that's done to focus just on logworks that would probably be better removed from a diag type program. I can move on to the diag part later, or someone can re-use bits of the code that are useful for that.

Originally Posted by ShelGame

I'll post that with the databases I mentioned later tonight when I get down to the basement. I do have a large number of memory maps (variable maps). I think I identified 7 different maps from 85 thru 91.

EDIT: Zip file added. The nomenclature in the address table file is setup for transfer to a Palm database. The 'category' is what I used as the memory map ID inside MiniDash. I now have a complete memory map for the VNT and T3 cals, but I need to put them into this sheet.

Thanks, depending on how much time I can steal away at lunch I may be able to get something roughly working by the end of this week. Unfortunately I won't be able to do much this weekend, I have some consulting work and an intake to build .

[risen]

I'm about 1/3rd of the way thru the implementation of the autoID and I've got 2 quick Q's:

1) Is there a reason that the VB code tries to read the cal ID back in low speed mode for the SMEC-T1/DRBII and not for the others? Will it not work at high speed by sending 0x02, 0x03?

2) Just so I'm clear, the SMEC-T1/DRBII ECUs will echo back the address requested once received, and immediately send back the value for that address, correct?

[ShelGame]

Originally Posted by risen

I'm about 1/3rd of the way thru the implementation of the autoID and I've got 2 quick Q's:

1) Is there a reason that the VB code tries to read the cal ID back in low speed mode for the SMEC-T1/DRBII and not for the others? Will it not work at high speed by sending 0x02, 0x03?

2) Just so I'm clear, the SMEC-T1/DRBII ECUs will echo back the address requested once received, and immediately send back the value for that address, correct?

All of the 'standard' DRBII functions are called at the inital baud rate of 7812. The 0x16 is just the standard DRB function that returns the cal ID. Actually, it will return any memory address starting with 0x80. But, I'm 99% sure it was intended for the CalID.

For whatever reason, the earlier DRB used the high speed mode to get the ID's.

No, the 0x12 test is the same protocol for all. You send an address; you get the value stored in that address. No address echo for any ECU (LM, SMEC, SBEC; DRB, DRBII). The only difference in the DRBII is they added a couple of subfunctions that allow you to get back to 'normal' DRBII command processing. I think with the LM, the only way to get out of command 0x12 is the key-off...

[risen]

Originally Posted by ShelGame

No, the 0x12 test is the same protocol for all. You send an address; you get the value stored in that address. No address echo for any ECU (LM, SMEC, SBEC; DRB, DRBII). The only difference in the DRBII is they added a couple of subfunctions that allow you to get back to 'normal' DRBII command processing. I think with the LM, the only way to get out of command 0x12 is the key-off...

OK, so you're just sending in the 0x12 to get an echo back so you see that the comms are still up and after it's successful then sending in the byte address you want to request? If that's not the case, could you explain why in the TxCmd function that the return from the read to the port is checked for ineqality to the command byte?

I must say, I forgot how frustrating VB was between it's setting the function name equal to a value as it's return and not enforcing any sort of function call syntax (optional ()'s ). The only nice feature is being able to do a switch (select case) on a string without the BS you have to pull in C/C++ to do the same.

[ShelGame]

Originally Posted by risen

OK, so you're just sending in the 0x12 to get an echo back so you see that the comms are still up and after it's successful then sending in the byte address you want to request? If that's not the case, could you explain why in the TxCmd function that the return from the read to the port is checked for ineqality to the command byte?

Yeah, the 0x12 is just to confirm the hi-speed mode. All generations will echo back the 0x12 when in hi-speed mode. Good thing there's nothing important stored at that address .

I used inequality probably because I'm a hack. I couldv'e just as easily used b = bCmd then TxCmd = true instead. I don't remember why I did it with negative logic like that.

Originally Posted by risen

I must say, I forgot how frustrating VB was between it's setting the function name equal to a value as it's return and not enforcing any sort of function call syntax (optional ()'s ). The only nice feature is being able to do a switch (select case) on a string without the BS you have to pull in C/C++ to do the same.

Honestly, I have a hard time with C++ because of those differences in conventions. Though, I do see how it can be a much more powerful language. The Llack of function call syntax is kind of annoying. Makes it hard to tell what's going on sometimes...

[risen]

Originally Posted by ShelGame

Yeah, the 0x12 is just to confirm the hi-speed mode. All generations will echo back the 0x12 when in hi-speed mode. Good thing there's nothing important stored at that address .

I used inequality probably because I'm a hack. I couldv'e just as easily used b = bCmd then TxCmd = true instead. I don't remember why I did it with negative logic like that.

It wasn't so much whether you check for the absence of inequality or equality, I just didn't understand why you'd check to make sure the byte you just sent came back, unless the ECU sent it back. But it's only used for 0x12, that's the part I didn't get previously.

Originally Posted by ShelGame

Honestly, I have a hard time with C++ because of those differences in conventions. Though, I do see how it can be a much more powerful language. The Llack of function call syntax is kind of annoying. Makes it hard to tell what's going on sometimes...

Reading through the VB code you have to ask yourself "is this a variable, or is this the return from a function" and go tracing thru the code. I learned regular old Basic on a TRS-80 when I was little so I'm a little more tolerant of 'goto' than someone who's only ever used Java is, but the function thing still gets me. 80% of my compsci classes were done in C++ in the late '90's, so it's much more natural to me than VB.

[ShelGame]

Originally Posted by risen

It wasn't so much whether you check for the absence of inequality or equality, I just didn't understand why you'd check to make sure the byte you just sent came back, unless the ECU sent it back. But it's only used for 0x12, that's the part I didn't get previously.

Yeah, I think the 0x12 test is the only one that will echo back the command to confirm the mode...

Originally Posted by risen

Reading through the VB code you have to ask yourself "is this a variable, or is this the return from a function" and go tracing thru the code. I learned regular old Basic on a TRS-80 when I was little so I'm a little more tolerant of 'goto' than someone who's only ever used Java is, but the function thing still gets me. 80% of my compsci classes were done in C++ in the late '90's, so it's much more natural to me than VB.

TRS-80!? Me too. My best friend had one (we couldn't afford one) and we wrote our own Zork-type games.