on 7/22/2000 11:00 PM, futurebasic-digest-help@... at
futurebasic-digest-help@... wrote:

>> I am trying to read a serial port after sending a command to a device. The
>> data coming back has been read by various methods (most garnered off
>> examples on this list). The problem is that it works most of the times, but
>> every 5th, or 10th, or 20th read (it varies), I get extraneous characters,
>> first couple of characters missed, or just plain jibberish. I know the
>> device is sending out correctly because I have a second computer paralleled
>> (read only) on the serial line running a terminal program and it returns the
>> expected data every time (hundreds of returns). What am I doing wrong? Here
>> is what I am using:
>> 
>> characAvail=LOF(thePort,1)
>> LONG IF characAvail
>> characToRead=characAvail
>> IF characToRead>255 then characToRead=255
>> READ FILE thePort,@x$+1, characToRead
>> POKE@x$,characToRead
>> END IF
>> 
>> I am polling during null events, 38,400 baud, expecting a 9-byte return.
>> 
>> Thanks!
>> 
>> rod k.
>It seems to me that the problem could be one of timing.  For example, suppose
>the device is in the middle of sending a 9-byte message at the moment you
>execute the "characAvail=LOF(thePort,1)" statement.  It could be that at that
>instant, only (say) 4 of the bytes have yet been transmitted.  In this case
>charaAvail will be set to 4, and x$ will end up containing only the first 4
>bytes of the message.  If you loop back around and execute this code again,
>then you'll pick up the other 5 bytes, but then x$ will be set to that string
>of 5 and you'll have overwritten the first 4 that were in x$ before.  Unless
>you have additional code that is collecting these "partial" results from x$
>into another string, you can lose data.
>
>I think I would do it like this:
>
>1. Send the command to the device, then immediately set a global string
>gReturnMsg$ = "".
>
>2. In your null-event handler, put code like this:
>
>  WHILE LOF(thePort,1) > 0 AND LEN(gReturnMsg$) < 9
>    READ #thePort, c$;1 'reads exactly 1 character
>    gReturnMsg$ = gReturnMsg$ + c$
>  WEND
>
>  That way, every time your null-event handler is called, zero, 1 or more than
>1 characters will be added to gReturnMsg$.  Then all you need to do is
>periodically check the length of gReturnMsg$.  When LEN(gReturnMsg$) = 9,
>you've received the full message.
>
>- Rick
> 
>> We find that
>> 
>> READ #port,a$;0
>> 
>> is more likely to fly, in that it sucks in a byte if there's one in the
>> buffer, and doesn't hang up if there's nothing there.
>> 
>> If you know the incoming format (as you seem to), it is possible to sort of
>> synchronize to the first character, and get the rest in a single whack, as
>> long as you poll it to find out when the rest of the 'sentence' is there.
>> 
>> READ #port,a$;0 is very slow, so beware of that.
>> 
>> Someone else mentioned that all of the ports found with FBInitserialports
>> can be opened and then closed. If you're concerned with the DTR line, you'll
>> find that FBInitserialports also opens all of the ports in sequence and
>> closes them. The DTR will be flapping in the breeze like crazy while this is
>> going on.

I think the timing part is my problem. I need speed but I need the program
not to hang if someone pulls the cable or takes the machine off remote (or
turns the machine off). Too bad there's not a simple way to do this. I'll
some of these versions and see what kind of results I get. Many thanks.

rod k.