Serial.ReadAll does not read all

The serial device is responding to requests for data properly by sending the requested data; however, Xojo does not always receive all the bytes the device is sending. Sometimes it works correctly, but sometimes fewer bytes come into the DataAvailable event than were requested, and the only way to get the bytes that are missing is to send another command to the device, after which the bytes which were not received come in before the bytes coming in as the response to the next command. Let me give an example:

Request: 256 bytes
Received: 200 bytes

… at this point there is DataAvailable event does not fire again, and polling does nothing.

Request: some other 256 bytes
Received: 56 missing bytes + 256 new bytes

It looks like some input buffer in Xojo is not releasing the data to the DataAvailable event.

I’m working with a serial device for the first time, so I don’t know if this is a common problem? How is this supposed to be handled?

Just because the DataAvailable event fires does not mean it has all of it. You have to poll the port and do a read all. Working example from my own application:

[code]while oSerial.BytesAvailable > 0

dim s as string = oSerial.ReadAll
sSerialBuffer = sSerialBuffer + s
oSerial.poll
wend

//Now do something with data[/code]

Of course there’s also the possibility you have a partial message, or a full message and partial of the next so it’s kind of important to tell if you have an end of message. In our application it’s Chr(13) + Chr(10) so I have to split whatever I have and then look at each part.

Thank you, Bob! That was it. Adapted for my Serial subclass …

// 1. collect the data
dim x string 
while me.BytesAvailable > 0
  x = x + me.ReadAll
  me.Poll
wend
// 2. do something

In my case I’m reading raw bytes of FLASH memory and unfortunately there is no checksum or terminating byte sent from the device, so the only way to se if a request is successful is to count the bytes received.

I notice this now works 99% of the time, but every so often there is still an error. But the behaviour changed since adding this code, now after an error crops up, commands simply stop working, which sounds more like something to do with the device.