I think I've figured out what's going on. I havn't had a chacne to plug up my 633 and test my theory though.
When VB recieves a single byte from it's device it instantly calls the OnComm routine. So, for EACH Byte it get's, it call's the oncomm.
My solution is to have two timer's. One a sleeper, and the other to delete the value.
It's kinda a complex workaround, but VB doesn't really do well with Comm ports.... Anyways, the method that I've always done with the Comm ports works, and works reliably.
I'll submit sample code on how to fix it so that it can get more than just hte 128.
Also, I'll modify the sample 633 code to work with reporting back stuff like fan reports, and stuff like that.
I might just make a API dll for the 633, I have one out for the 632 and 634. Then you wouldn't have to deal with alot of the other problems.
You'd just have code like this:
screen.clear
screen.write(1,1,"hello world!")
etc.
and it would raise events too. When it get's a fan report, it'd call the following subroutine and then you do with it what you want:
private sub FanReport(RPM as double, FanNumber as integer)
end sub
And you'd do what you want with that. It's relativly easy to make that, but it does take some time, a little bit of bug checking, but it works nice.
Also, your program wouldn't have a MSComm control on it anywhere.... the program would deal with that.
Anyways... Lemme know what you think about the API DLL, and if your interested.