pcmhacking.net

ok.. updated to match.. same problem still.

Its only firing when the event queue is 0. Still no go.

Will continue with the DPDU tester app... almost there with it.

Im so happy, I could fucking cry.
It is a combination of timing, when events should be triggered and ensure you dont execute too fast.

There is still more that needs to be done.. since clicking confirm them locks up tech2win.. since for some absolutely stupid reason, tech2win decides it will close the VPW protocol.. and setup CANbus. Which is clearly going to cause a massive headache using the OBDX Pro VT.

Anyways.. massive progress!

Also, I think I figured out how to deal with the 4x to 1x switch for j2534. I believe should be able to just look for the mode 20 request.. and make the scantool switch to 1x after sending it if it's in 4x mode. I think that would actually solve the problem.

Congrats and well done!

Tazzi,

Are you finished with the J2534 firmware for the OBDX Pro VT?
I see there is no update (or the update tool?) listed on the tools website.
I have a V2 tool if that makes any difference.
Great work you are doing here, BTW!
Patiently waiting for your work to progress to completion!

Mike

MudDuck514 wrote:Tazzi,

Are you finished with the J2534 firmware for the OBDX Pro VT?
I see there is no update (or the update tool?) listed on the tools website.
I have a V2 tool if that makes any difference.
Great work you are doing here, BTW!
Patiently waiting for your work to progress to completion!

Mike

I need to test out the 4x change as mentioned above to see if it solves the SPS speed dilemma with the VT. If that works, then I will be able to release an initial J2534 installer for the OBDX Pro tools.

antus wrote:Congrats and well done!

Thanks! Just glad that its finally accepting the live frames!! I find it almost comical that my 'hack' with an ALDL was working, although I can see this is by pure luck now with timing of the frame and other events coincidentally occurring correctly.

The next issue... Tech2win.. for some absolutely stupid reason.. has opened CANBus communication. You can also physically hear the MDI when it has since it clicks on a relay to engage the correct PINs.
I had an E38 ecu on the bench at the same time, and tech2win did infact actually request a bunch of data from it. After it reads a bunch of data (Which is literally does nothing with), it then disconnects the CAN line, discards the CAN comms and moves on.

Checking a log without an E38 on bench.. and it still does same thing, cycles through a bunch of protocols.. specifically:
ISO_11898_2_DWCAN (ISO_15765_3_on_ISO_15765_2)
ISO_11898_2_DWCAN (ISO_11898_RAW)
ISO_11898_2_DWCAN (ISO_15765_3_on_ISO_15765_2)
ISO_11898_2_DWCAN (ISO_11898_RAW)
SAE_J1850_VPW (SAE_J2190_on_SAE_J1850_VPW)

Once it gets to VPW, it fires off 6C 10 F1 20.. and gets response 6C F1 10 60
The tries: 6C 18 F1 20 .. no response
then: 6C 10 F1 19 08 FF FF... and gets response 6C F1 10 59 08 00
finally: 6C 10 F1 20.. with response 6C F1 10 60

It then closes the COMMs, disconnects from VPW protocol.

Its almost like it was trying to autodetect which modules were present (maybe??). At the end of it all though, it still disconnects the VPW line again anyways.. so overall kinda seems pointless.
Especially since the vehicle selected to is ALDL and VPW technically... so in no way should it even be trying CAN.

To bypass CAN on VPW, I am going to have to make the tool just return "OK" and not actually transmit anything to the tool. This should result in the displayed no response event requests and allow it back to the VPW setup at the end.

From there I believe everything else is just standard comms when reading live data.

What about in the early stages of the init? Are you telling it that you have more protocols than you really do? Maybe you can change that, and if so by advertising lack of support of those protocols it might not try. Sending back a false OK might cause more problems later on.

Device ID 18 looks like TCM. So maybe its looking to see if its present to see if can pull any data from that, or needs to otherwise consider it on the bus.

Even though can bus might not look like it makes sense plenty of cars have more than 1 bus. VPW+ALDL, CAN+ALDL, VPW+CAN (eg E40 I think?) so its likely there is a scenario where it needs to do this. It might be more code and more database info required in t2w to skip looking, where looking for something thats not there probably doesnt matter and future proofs it from the tech2 developers point of view.

antus wrote:What about in the early stages of the init? Are you telling it that you have more protocols than you really do? Maybe you can change that, and if so by advertising lack of support of those protocols it might not try. Sending back a false OK might cause more problems later on.

Device ID 18 looks like TCM. So maybe its looking to see if its present to see if can pull any data from that, or needs to otherwise consider it on the bus.

Even though can bus might not look like it makes sense plenty of cars have more than 1 bus. VPW+ALDL, CAN+ALDL, VPW+CAN (eg E40 I think?) so its likely there is a scenario where it needs to do this. It might be more code and more database info required in t2w to skip looking, where looking for something thats not there probably doesnt matter and future proofs it from the tech2 developers point of view.

My previous tests of not supporting certain protocols/requests resulted in tech2win running in a "unsupported" mode, it seems tech2win was never intended to not support features that the current t2win card requires. The unsupported mode is what I was facing near the start of the DPDU saga, and the requests it made were extremely broad... almost impossible to figure out what it wanted.

I can understand that perspective, and look for modules on protocols it knows are supported for that vehicle, but on a VY, there was never a model with CANbus. They had to have already looked at the VY 'database' since if I write a non support hardware/OS details to the P01, it will not proceed as its an unrecognized ECU. It then does this CAN lookup after clicking confirm.

Ill tinker with trying to reject the CAN protocol change request after its at the confirm screen.. and see if it skips the process.. or completely makes it crash

FWIW I know t2w logs an error from the drewtech when you try and use ALDL as its not supported. And it does it not when the interface is opened, but when it tries to switch to ALDL protocol. If you have a drewtech you might be able to try that and see if you can handle it the same way.

Im suggesting the code in T2W might be more generic and common between models rather than know the exact approach per vehicle even if it does have the manufacturer, model and model year and variant. I guess in a 32mb card the DB would be too big to know if options were fitted etc to a car, especially in the larger markets so a lot of it is likely generic.