OBDX Development - Developer Tools and Suggestions

[Tazzi]

I have now 100% simulated the MDI, no warnings appear when opening tech2win since it thinks its a MDI connected.

But... no joy still. So... it has to be a timing issue occuring. The OBDX tools are WAY faster then the MDI, so I have tried putting in artificial delays to make it match up.. but something is still missing.

[kur4o]

T2win uses some virtual com port drivers which might be very picky on timings. Maybe you can try to log some of the communication there to see where it fails. The 94 v6 pcm always fails to get communication, and that might be the reason why some ALDL modules don`t like t2win.

[Tazzi]

Im only a few milliseconds different from what tech2win is doing..so I honestly do not understand why its not working.

I am going to proceed with making the DPDU tester app a bit longer, and make a perfect timestamp log using the MDI.. and then replay it with OBDX when tech2win is connected.

If that still doesnt work.... then I will be literally out of options.

[MudDuck514]

Hi all,

Tazzi, great work you are doing here.
Would it be permissible to look at how the VCX Nano is able to communicate with T2Win?

Just a thought since I am NOT a programmer.

Mike

[Tazzi]

Hi all,

Tazzi, great work you are doing here.
Would it be permissible to look at how the VCX Nano is able to communicate with T2Win?

Just a thought since I am NOT a programmer.

Mike

Yeah it is a possibility to look at what they do also. I believe when installing the dpdu for tech2win, it completely breaks the other tools. But that’s likely because it deletes the other tools dpdu registration where tech2win checks.

I *think* the issue might be related to ‘when’ the callbacks need to be actually sent. I might be doing them too late, or too early.

Actually now that I think of it… I wonder if tech2win wants to manually poll for the received frames… maybe? Since it has made calls for checking the queue even when no callback request has been sent from the OBDX api.
Finely monitoring what the MDI does should help confirm when events should be fired and what ‘kind’ of event should be fired.. these could be the only things left that I don’t have.

*edit
Couldn’t help myself but test out a few things.
1) tech2win will only send the VPW frame once, and does not do any manual polls to get event updates if the dpdu api does not make a callback.
2) if I line up a bunch of events to process and make only 1 callback, tech2win will keep polling these events in the queue until it receives a “no events available”.

So with that in mind, maybe there needs to be a specific sequence of event callbacks to satisfy tech2win. The events that I add to the queue appear to be correct.. but maybe it requires a specific number of callback requests to t2win.

This mdi logging should enlighten all of this. I wonder if t2win needs to see the “no events left” before it receives the actual pcm response?

[Tazzi]

... 3:30am and Im calling it a night!

Things confirmed so far:
1) Sequence of calls is important.
2) Tech2win does make some calls to the event status more then what the MDI even sends as callbacks. So mimicing the MDI's callbacks is important.
3) Got call backs working in a D-PDU API tester application, so I know my callback structure must be correct since it works in both my DPDU DLL and also DPDU tester program.

I still need to implement a PDUGetEventItem request into the tester app to automatically run when a callback occurs. Along with properly matching the StartPrimitive commands to match the MDI logs previously.
This callback situation is the ONLY unknown... and at least I can use the tester app to properly check I am receiving the exact same information back.

[antus]

Is it more like an packets ready callback, where you might queue multiple packets, tell T2W to take a look, let it grab all the frames, send it the 'no more'. then go back to adding new frames. maybe you need to track head and tail of your queue, so t2w can pop packets off the top, while you add new ones to the bottom (in a memory safe way).

say

1. packet 1 arrives in queue, queue is empty, you write it to the tail (which is the same as the head in an empty queue.
2. you tell t2w there is data
3. packet 2 arrives in the queue, you write it to the tail behind packet 1
4. t2w reads packet 1
5. packet 3 arrives, you write it to the tail
6. t2w reads packet 2, then packet 3, then tries to read packet 4
7. you say 'no more packets'
8. packet 5 arrives, goes to the tail (which again is the head).

so then if it was C you'd need a mutex so you can do this in a memory safe way, but perhaps c# has something to give you a linked list without you needing to worry about those details.

[antus]

Does your documentation cover about 4 receive type scenareos like this one? Are you coding to these workflows? This sounds like what you are describing. The final note also says it can be mixed with other types of requests. Could it be that you have implemented this correctly, but there is another type of request you need to handle differently, too?

[Tazzi]

Correct, that’s the method I am trying to follow.

Now something interesting I missed before though. “A callback is only initiated when an event is placed into an empty queue.”.

I have been firing events on EVERY item put into the queue.

So.. maybe need to check it the queue is empty first. Then add the item.

[antus]

Yeah I think thats the other way of talking about how it'll keep pulling messages after you give it the receive notification and until you send PDU_ERR_NO_ITEM.

It sounds like that could be it. The second notification callback on the T2W side probably overwrites the first one, which never completed, so its out of whack and maybe loosing some internal data and leaking memory.