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.