pcmhacking.net

Attached is all the tests for new version still all the same, crashes for vin retrieve on any of the CAN, but it actually tries to get engine data but comes up with unknown error everytime I exit monitor all when in CAN mode only!

On the good news front I decided to plug my old style scan tool to bench setup & it actually gives me all the data & fault codes unlike the other scan tool I had that said it couldn't find data, just need to keep the older dumber scan tool for this I guess!

So yeah as I said it will get all the data now but monitor all doesn't see any of it just keeps rolling when retrying but didn't see any of the data going passed!

On the PCM front that your getting the VY V8 pcm will probably be an 0411 & only worth around $60, but hopefully the VZ alloytec will be good for some more testing!

Well I thought about it for a bit & thought I'd better check the ELM device & sure enough the plate that supports the pins had backed out again, so last time I glued outer section & then realised today there is an inner section of this & clips weren't supporting it so glued that sucker in now!

So here is some actual data from monitor, but as suspected ELM couldn't keep up!

& yeah with pins out properly now it still has the same issues with crash & not getting VIN!

Great stuff VX!.

Looks like the CAN stuff for requests is just hating it. It keeps sending back "CAN ERROR". I Think the problem is the formatting actually... I might have to add buffer bytes.
eg 7E0 01 0C 00 00 00 00 00 ect.. something like that, just add 00 padding. But this should only be the problem for reading, the monitoring application should pick up anything from the elm.

That last document you sent through VX, doesnt have anything in it lol. Did the ELM actually log data on CAN HI?
If it cant keep up and keeps showing buffer full, will need to add in a filter so that it doesnt stop every few bytes.

**
Have now turning on the ELMs CAN Auto Formatting. This might help us out. And also Changed the ELMS error handing.. should be able to do the normal 010C engine request now without the elm erroring for whatever reason.

Here is the blurb from the ELM data sheet about it:

"The CAN System had difficulty initializing, sending or receiving. Often this is simply from not being connected to a CAN system when you attempt to send a message, but it may be because you have set the system to an incorrect protocol, or to a baud rate that does not match the actual data rate. As the BUS errors, the CAN ERROR might also be the result of a wiring problem, so if this is the first time using your ELM327 circuit, review all of your CAN interface circuitry before proceeding."

WOOPS not sure why it didn't export properly for the last 1, but yeah it logged fine!

Here's 1 I did just after that & interesting to note that it didn't show anything being monitored on CAN 29 or J1850 so must assume the alloytec E55 pcm is on CAN11?

But yeah pretty annoying how the program shuts down every time you try & search for VIN or disable the monitor but only when in CAN mode!

You'll see the buffer full message in this log quite a bit!!!

OK Cool. So if you cant see anything over CAN29bit.. then nothing must be communicating over that. But in those logs, we can clearly see that there is 11bit being monitored!
eg. 110 60 00 00 00 00 00 0F 00
That three byte header means its 11bit.

VX, is it automatically resetting each time buffer is full?
I "think" I may have sorted the erroring a bit more.. I turned off a few stupid little settings the elm uses. And I dont think the VIN function works for the CAN protocol.. Im not sure what GM actually sends to get the vin.. obliviously isnt 0902 or 3C01 ect. But the buffer full message will occur untill we start adding a filter. Eg.. only look for a message with the header 110

Just looking at the logs again.. The elm is sending back: "<DATA ERROR."

The fact sheet says this occurs when the frame is not formatted to the "standard" way that it normally uses..Should have known.. of course being GM they wouldnt use the "typical" format. We might need to actually turn "off" the auto formatting since its by default turned on!

Not sure when it's stopping but every now & then when monitoring it just stops & comes up with retry for communicating but doesn't & in this log 1 out of the 5 times it didn't crash when I had to press disable to re-monitor, but other 4 times program still crashes?

Found out why the text box was empty the free serial port monitor program says it's exported ok, but then the data is empty in text I almost lost this lot too!

Ohh I see, it keeps crashing when clicking disable chatter. Alright added a "crash" catch.. Should prevent that now.

I *think* this will be the one to work!

Next time you try VX, could you paste everything that displays in the textbox in the app into notepad as well? makes it a hell of a lot easier to read.

But its good to see that its "semi" working for the can protocol.. well the monitoring part!.

VX, I was thinking about why your scantool doesnt pick up the pcm... Mayyyybe.. its looking for the BCM ALDL heartbeat? Might be a good idea to try hooking one of your bench bcm's up and your other scantool may work? Might check that the car is actually present before doing anything else? But hey, if you got something working.. thats better then nothing!

I wouldnt think the Tech2 would do this since it needs the candi module connected up to communicate over OBD2, so I doubt it would be able to see the ALDL communication.

Iv found after going through aloooooooot of trouble shooting/problem threads on various sites, that the "<Error" and also "Error Can" messages occur due to invalid formatting of the frames. Meaning the "auto formatting" will need to be turned off (ATCAF0). Its automatically on by default.

Also next version will have a basic filter which can be applied, for 11bit CAN (ATCFXXX), VPW (ATMRXX or ATMTXX) and 29bit can (ATCFVVXXYYZZ). The filter will be applied based on the protocol selected. Using a filter should hopefully eliminate the buffer full errors and will provide continuous streaming. Also upping the baud rate to the highest support amount should help.

Having a look through some logs from VX, some of the 11bit Device header (IDs) that could be of interest.. VX, is this all from a pcm on bench!? Bit worrying on how many headers there are coming from a single component.? Unless its broadcasting alot of information directed at specific components?