ALDL logger VB10

Programs / Tools / Scripts
User avatar
Jayme
Posts: 2585
Joined: Sun Mar 01, 2009 8:59 am
Location: North Coast, NSW

Re: ALDL logger VB10

Post by Jayme »

could always just make it in c#... ? ive played with it a bit, its not super difficult if you already know your way round vb. although I did have lots of help from someone who knows C like the back of his hand :P
ejukated
Posts: 443
Joined: Wed Mar 04, 2009 8:52 pm

Re: ALDL logger VB10

Post by ejukated »

EFILive is written in Delphi not vb
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: ALDL logger VB10

Post by Tazzi »

Jayme wrote:could always just make it in c#... ? ive played with it a bit, its not super difficult if you already know your way round vb. although I did have lots of help from someone who knows C like the back of his hand :P
True but since Iv gotten this far dont want to start again unless it is an absolute must do!
ejukated wrote:EFILive is written in Delphi not vb
And that would be the reason why!

So at this moment, the listening to chatter part is working great! Except.. sometimes doesnt want to stop displaying chatter but will get to that. Have no missing bytes or frames while listening.
Although I did have to cancel the command counter, the addition of this to the background worker made it just a tad too slow and started missing bytes (seems to be a processing speed issue?). Will need a separate background worker to do that side of things, will just pass string off to new background worker possibly.. although I suspect alot of "background worker is busy" since theres more to do for the "frame counter" side of operations. So to overcome that I was thinking of passing each frame into an array or database that the second backgroundworker can continuously grab the next frame. Unless theres a better idea?

Next annoying part that I am yet to understand is why it sometimes does not pickup the entire received frame once a frame has been sent in. I know it is sent correctly. Program picks up a response, and sometimes gets the whole frame but other times it only picks up the Device ID and Message length as these two are found separately.
Pretty much, When a frame is sent, Device ID is extracted and then used to compare with all incoming bytes. As stated before, it finds the echo response first, then all other responses with the same device ID are then displayed.
So when desired device ID is found, it then grabs the following byte as the message length, then a readline(ALDLFramebuffer,0,(FrameLength+1)) is then used to grab the rest of the message, including the checksum hence the +1.

So logically speaking, each byte is stored in sequential order in the buffer.. so if I find the device ID an message length.. how can it miss the rest!
Im having a feeling that I may need to for/while loop a readbyte() instead of readline. Could be another processing speed error when using the readline() operation. I dont see why that would be an issue.. but could be the same "glitch" as with the vbnewline that I had at the start!
charlay86 wrote: It is pretty low speed communications, I don't really see any reason why it should be dropping data, maybe it is a limitation of visual basic.
Low speed... :lol: it is in comparison to other communication speeds. Cant imagine attempting this for 8192+ speeds.. maybe VB wasn't the best choice.. least the general method can be applied to a different language.

Makes you appreciate the real effort that VL400 put into his program! as im sure he came across a few of these.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
User avatar
charlay86
Posts: 584
Joined: Thu Sep 17, 2009 2:00 pm
cars: VT S1 SS (L67)
Location: Perth, WA

Re: ALDL logger VB10

Post by charlay86 »

It is probably more efficient to retrieve the whole frame from the buffer once the line is idle, and then examine the first few bytes, that way you already have the whole frame. Perhaps the readline problem is an end of line character conversion issue, I am not that familiar with VB but perhaps there is a binary mode that handles the data differently?
User avatar
antus
Site Admin
Posts: 8237
Joined: Sat Feb 28, 2009 8:34 pm
cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Contact:

Re: ALDL logger VB10

Post by antus »

VB6 is a very different beast to the later .net versions of VB. VB6 needed mscomm32 for serial stuff, which itself is a native x86 dll. Some of the major packages that deal with faster bus speeds are written in vb6. Then with the .net versions of VB, the basic language is converted to microsofts interpreted language, IL. Which is the same for VB or C#, or most of the other visual studio languages. Thus, functionally equivalent code in different languages generates the same IL. The language can do it. There is likely something wrong with your approach or a bug in your app. Perhaps the rx interrupts are happening too quickly and the serial buffer is getting overwritten before you clear the data out of it. How have you set up the serial timeout options, particularly the inter-byte timeout?
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
User avatar
VL400
Posts: 4991
Joined: Sun Mar 01, 2009 2:54 pm
cars: VL Calais and Toyota Landcruiser. Plus some toys :)
Location: Perth, WA
Contact:

Re: ALDL logger VB10

Post by VL400 »

Lots of trial and error to get .net half happy, and the way my code ended up is certainly not how ms would expect it to be written. I am not using readine, just read byte ( initially the device id and byte count and then the rest in one hit). It still drops bytes but only on vt and later when listening to chatter, efilive trial does a much better job so have not done that much to see why it does it.

The echo frame I do what charlay suggested, read the bytes (I have an expected bytes count value from the TX code), confirm they match what was sent and then set a flag to say echo done. Some commands will have a reply the same as the sent frame so its not a fool proof method.
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: ALDL logger VB10

Post by Tazzi »

charlay86 wrote:Perhaps the readline problem is an end of line character conversion issue, I am not that familiar with VB but perhaps there is a binary mode that handles the data differently?
At the moment Im using the readline function.. and I stepped through the program, When stepping through slowly, it grabs all the data precisely. But when letting it go by it self, it doesn't always grab all the received frame! Maybe the readline isnt totally reliable, will give a go with using a loop with readbyte() until message length is met.
In saying that, the chatter function uses a readline and grabs all the info perfectly?
antus wrote:VB6 is a very different beast to the later .net versions of VB. Some of the major packages that deal with faster bus speeds are written in vb6. The language can do it. There is likely something wrong with your approach or a bug in your app. Perhaps the rx interrupts are happening too quickly and the serial buffer is getting overwritten before you clear the data out of it. How have you set up the serial timeout options, particularly the inter-byte timeout?
Well yeah I am questioning whether I have a bug in the receiving end, am using the same method as used for listening to chatter. I think you may be onto something with "clearing the buffer", as once the com2 is connected it does not clear the data.. might clear buffer before frame is sent, could be the issue, I didnt think of that!.
Would make sense since VL400 enables and disables the COM port each message, probably clears buffer once disabled or messaged received.
Serial timeout option is set to 50ms, seems to be good, if it doesnt receive anything, it waits another 50ms, repeats a couple times if nothing is picked up then ends. With the "inter-byte timeout", do you mean the time between bytes received? Was unaware of such function! or would I need to make up a quick worker to grab time of byte received and find the difference between the next byte received.
VL400 wrote:Lots of trial and error to get .net half happy, and the way my code ended up is certainly not how ms would expect it to be written. I am not using readine, just read byte ( initially the device id and byte count and then the rest in one hit).
The echo frame I do what charlay suggested, read the bytes (I have an expected bytes count value from the TX code), confirm they match what was sent and then set a flag to say echo done. Some commands will have a reply the same as the sent frame so its not a fool proof method.
:lol: Yeah Im getting the feeling Im straying further and further to the "Ideal" way of this logger to be written.
Im guessing when you say in one hit.. your still using read byte but loop it round to grab the rest?
Well seems the echo frame is under control then, As when playing with the VY/VZ clusters, they send back the same frame when there unhappy and need to be reset (after spamming them with codes), now flags the echo response then grabs the next frame with the Device ID.

Will try out clearing the buffer and using only read byte to see what happens. Cheers. :thumbup:
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
User avatar
antus
Site Admin
Posts: 8237
Joined: Sat Feb 28, 2009 8:34 pm
cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Contact:

Re: ALDL logger VB10

Post by antus »

Not sure what you need for VB, but essentially whatever sets these things up in the drivers/physical interface - this is the underlying windows API. You usually dont need to touch it for normal applications, so its not documented in many examples of serial I/O on the net. The interval timer is the time between bytes, so you can handle really short gaps with one read. But I agree with the others.... best to handle it on a byte to byte basis anyway.

http://msdn.microsoft.com/en-us/library ... 85%29.aspx

Code: Select all

typedef struct _COMMTIMEOUTS {
  DWORD ReadIntervalTimeout;
  DWORD ReadTotalTimeoutMultiplier;
  DWORD ReadTotalTimeoutConstant;
  DWORD WriteTotalTimeoutMultiplier;
  DWORD WriteTotalTimeoutConstant;
} COMMTIMEOUTS, *LPCOMMTIMEOUTS;
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: ALDL logger VB10

Post by Tazzi »

Well I cant seem to find a readintervaltimeout function in vb, seems the best option I have is to do something like this..
When a byte is received could do something along the lines of:

Dim PreviousTime As Long = 0 'only for first byte recieved
ALDLByte = readbyte() 'grab the byte
Dim ReceivedTime As Long = Now.TimeOfDay.TotalMilliseconds 'current time
TimeDiff=ReceivedTime - PreviousTime 'time interval between bytes
PreviousTime = ReceivedTime 'use time value for next byte

Seems simple enough.. Just hope that when we are speaking in such small intervals and times, that by grabbing the time before/after the readbyte function that it doesn't give values far from an actual true time. Time between bytes should be something around 1-2ms or so? or is it more?.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
User avatar
antus
Site Admin
Posts: 8237
Joined: Sat Feb 28, 2009 8:34 pm
cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Contact:

Re: ALDL logger VB10

Post by antus »

Im not really sure, its just a thought. In an ideal world there should be no time, but in noisy car applications and with non standard speeds and in an ecu where so much stuff is very time critical and interupt driven its always possible. I know I do set those timeouts in my code, but I didnt have to change them much.

I also dont use overlapped I/O, just call a blocking read when im expecting data and wait for the next byte and let the serial stack handle buffering.
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
Post Reply