Hi,
There is many FREE basic tools for communicating via serial. "Putty" is one
My approach would be to
setup a computer with putty to MONITOR the serial comms,
Use the same or another machine to connect to the ECU as normal and just connect the RX line of the putty interface to either the RX or the TX line of the ECU.
With that type of setup you should be able to simply monitor the comms traffic over the standard interface. Connecting only the (putty) Serial RX line (pin 2 on pc 9way) will simply listen.
First thing will be to determine the correct Baud rate, taking note that it could change at any point.
Some devices will connect at a low known rate and then switch up to something faster.
If you have access to a scope it is easy to figure the approx. baud rate.
Or it maybe written somewhere.!
Oh... com1:38400,n,8,1. That saves looking too hard.
However, within the DLL it is clear to see that 9600,n,8,1 and 19200,n,8,1 is also mentioned.
Once you establish what the proper Baud rate is then you can log the traffic on the TX line and do the same for the RX line.
It is possible that the ECU will not transmit any data until it receives a valid instruction thus you need to see what the original interface is saying to the ECU to make it reply.
Once you can see the data flow you could then perhaps use an Arduino to monitor and listen, even perhaps using two serial ports, connecting the RX and TX pins of the original interface to the RX pins on the Arduino ports. Some Arduinos only have one hardware serial but you can use a software serial port to give a second one. But I would say using a PC will give an easier interface while working with the unknown.
I have not mentioned it but you know that the pins on the Arduino will be TTL and the pins on the ECU sound like they are RS232. Not only are the lines at the wrong voltage but I believe they are also inverted, I forget now. So connecting to the Arduino will require TTL-232 convertor like MAX232 or similar.
Then once you have nailed what the required Baud Rate and protocol is you can then use the Arduino in place of the original interface and talk to the ECU like a pro.
There does not seem like much work needed to reverse engineer the received packets as they are clearly defined in the excel macro you show.
Hope that helps, I do this a lot so if you need any further help SHOUT.
Hv.