OBDX Development - Developer Tools and Suggestions

[Tazzi]

6000 lines of code later (No... I am no kidding).. and we are now opening the menus correctly for standard HSCAN.

Another perfect example to why scantool manufactures have to design their DLLs/tool around the actual software is this gem of a response:

Code: Select all

PDU_RESULT_DATA
            RxFlag:                               
              PDU_FLAG_DATA
                NumFlagBytes:                     4 
                pFlagData:                        REMOTE_FRAME
                pFlagData:                        10666ED8 
                *pFlagData:                       80 00 00 00    

This is part of a received message from the MDI to tech2win for the following CAN frame: 00 00 05 E8 81 01 07 00 6F 00 00 00

This CAN frame is actually a fault code report, basically just a standard CAN frame, so its nothing special.

Now.. why is this all important? Well, the REMOTE_FRAME is actually a mistake in the tech2, where its indicating a remote transfer request (RTR) which is incorrect. Not only is it incorrect, but Bosch has actually coded it into their DLL to just enable that specific bit for the RX flags but doesnt even actually perform the RTR which would normally occur with a RTR CANbus frame.

Basically I am having to add the same stupid hackery into the OBDX DPDU API so that tech2win will actually pickup the message. In doing this, basically this would make this DPDU API likely invalid for any other software that uses DPDU since I would highly doubt they would have the same stupid mistake.

I understand developers are only human, and I make mistakes like anyone else... but I am amazed that manufactures didn't try to have these problems fixed over the years as both the J2534 and DPDU become a giant bandaid to fix multiple issues in multiple softwares implementing the protocol wrong

[gmtech825]

Basically I am having to add the same stupid hackery into the OBDX DPDU API so that tech2win will actually pickup the message. In doing this, basically this would make this DPDU API likely invalid for any other software that uses DPDU since I would highly doubt they would have the same stupid mistake.

I understand developers are only human, and I make mistakes like anyone else... but I am amazed that manufactures didn't try to have these problems fixed over the years as both the J2534 and DPDU become a giant bandaid to fix multiple issues in multiple softwares implementing the protocol wrong

the engineers are "forward thinking" they rarely ever go backwards to fix anything. it's very frustrating. they should hire you to figure this out for them.

[ironduke]

So it looks like nothing has changed.. The new and improved techline connect is never new or improved.. every update seems to break it even worse. They're now fighting an immo problem and trying to learn or add keys is now a lottery.. Seems tlc likes to simply shut down in the middle of programming sometimes now too. Used to be a rarity but with some modules it's now more than a 50/50 shot.

[Tazzi]

I fully understand why there’s only a few tools on the planet that support tech2win.

It’s got to be one of the worst things I have ever had to design for. Even after all of this work, there’s still more hickups I need to fix before it actually fully moves into the menus. Just before heading to bed, iv noticed it’s randomly setting a flag to do a loop back message for a tester present message along with also performing a indication TX successful.

So after it’s already successfully communicated to the ecu and displayed information to the user... It’s next step after the user clicks continue is to now do a loop back test, which is also checking for the TX indication. By definition, this shouldn’t send to the CANbus line but the MDI appears to still send it… so I’m unsure if that’s a design flaw of the MDI… or is it being done because tech2win might keep the loop back test enabled and doesn’t actually disable it

It makes me worry about even using tech2win after seeing how it all works. For once, being ignorant really is bliss.

[ironduke]

I fully understand why there’s only a few tools on the planet that support tech2win.

It’s got to be one of the worst things I have ever had to design for. Even after all of this work, there’s still more hickups I need to fix before it actually fully moves into the menus. Just before heading to bed, iv noticed it’s randomly setting a flag to do a loop back message for a tester present message along with also performing a indication TX successful.

So after it’s already successfully communicated to the ecu and displayed information to the user... It’s next step after the user clicks continue is to now do a loop back test, which is also checking for the TX indication. By definition, this shouldn’t send to the CANbus line but the MDI appears to still send it… so I’m unsure if that’s a design flaw of the MDI… or is it being done because tech2win might keep the loop back test enabled and doesn’t actually disable it

It makes me worry about even using tech2win after seeing how it all works. For once, being ignorant really is bliss.

I wonder if it has anything to do with the tech2 and the Candi module?? I know it's using the MDI but tech2win is some kind of emulator for the tech2, right? I just remember the Candi module disconnecting and the tech2 erroring out 1 hundred times a day for no reason, lol.. Those commands might be left over from that??

[exo3901]

On a E40(gto), I have never been able to use tech2win correctly with a vxnano or mongoose cable. Using software supplied by vx, official stuff from TDS, and even had a tech remote in and install some 30day version of it. All scenarios had limited functionality and would randomly crash or tell me there was no communication. If I recall, basic engine data was all I could really see, until it crashed. No idea if this is platform specific or device/software specific. Just wanted to mention it as the recent issues described reminded me of when I was messing with it. Received a GT earlier this week so if any routine tasks need a log or something I wouldn't mind helping.

[Tazzi]

On a E40(gto), I have never been able to use tech2win correctly with a vxnano or mongoose cable. Using software supplied by vx, official stuff from TDS, and even had a tech remote in and install some 30day version of it. All scenarios had limited functionality and would randomly crash or tell me there was no communication. If I recall, basic engine data was all I could really see, until it crashed. No idea if this is platform specific or device/software specific. Just wanted to mention it as the recent issues described reminded me of when I was messing with it. Received a GT earlier this week so if any routine tasks need a log or something I wouldn't mind helping.

Once I have this working on a few ECUs I have here plus also some GMLAN stuff, we can then try it out on a E40 and see whats going on.

Im not surprised the vxnano doesnt work with it, personally never got mine working with tech2win either, but I would say its because the devs didn't want to keep looking further into it to fix all the little problems I keep coming across.

[Tazzi]

Woohoo! Progress!

Gotten into the main menus, and can now read live data, DTCs and everything else.

There is one last issue I need to resolve and that is dealing with the tester present messages, I have built in functionality for this into the OBDX cable so it should be a simple fix.
Basically when we receive the following frame to transmit : 101 FE 3E, this is our typical tester present message. On the canbus, this would actually be transmitted as: 101 FE 01 3E where our 101 is the header, FE is extended header, 01 is length and 3E is tester present mode.

If I was to send the command without any formatting, the OBDX would send 101 02 FE 3E, since it has not been made aware of the extended address requirements. After setting a couple more commands, the OBDX will be aware to search for the FE byte at the beginning, and use this as the ended address, and calculate the length byte after it.

*Edit
And there we have it.. tech2win working for viewing live engine data on an E38.
Ill jump into my car after I sort out gmlan, which "should" just be a matter of setting the correct protocol... but will need to confirm.

tech2windefeated.PNG (46.48 KiB) Viewed 1111 times

[Tazzi]

I can confirm GMLAN is working... but... again in a sketchy way.

Tech2win is opening both HSCAN and GMLAN at the same time.

Basically I am setting a variable that detects the GMLAN request, then prevents tech2win from changing the protocol to HSCAN unless it completely closes both logical protocols which it does after exciting that modules menu.

Tech2win does make a "beep" noise when entering the VE radio menu, although I believe it has to do with the high voltage wakeup message, Im pretty sure Im suppose to send something back to tech2win to acknowledge it.

While trying to go into the VE BCM menu, it begins communication and then pops up saying loss communication... this is because tech2win again opens a GMLAN and HSCAN at the same time... so not sure how to deal with that other then hardcoding filter values that are on each protocols

Now... I THINK... it opens 2 HSCAN protocols.. and 1 gmlan... so maybe... I can look for the double HSCAN and switch that that???

[Tazzi]

Problem not solved.

But can confirm both GMLAN and HSCAN do work.

Now.. our main issue is 2 GMLAN and 2 HSCAN CAN instances are opened... and we need a way to work out if HSCAN or GMLAN is going to be used overall.

A very complex method to this.. is changing protocols each time a new write to canbus is made, then checking what the current protocol is set to... then changing it across.. setting the filters.. ect. This could work but is genuinely a mess to deal with.