Snipped and appended where needed...

Thanks for the quick response..

Actually, I have changed the sthreshold to various points....right now it's sitting at 1 character. I've had it up to 512 - all with the same results.

Are these fixed or variable sized chucks of data you are sending to the scale? Any chance that the scale is also outputting XON/XOFF ? These would show as CHR(17) and CHR(19) in your input stream. See here for a VB reference. Any chance of getting a port monitor in the line - the little gizmos with the LED's. You could then see if the hardware HS is what is stalling the output...

There is only one cable involved, and the port is open from beginning of program to end as it intercepts received info from the scale as well as sending info to it for internal processing. The scale appears to be taking it's time processing what's coming in, but my understanding of handshaking leads me to believe that the Fox program should wait.

Not at all - once you dump your data in the buffer, you can go merrily on your way to something else if needed, depending on the quantity of data. I would not expect to do something like a FILETOSTR() of a 10MB text file and dump that out without a little more control - if you want the PC to do anything for quite a while :-)

If you want to test the outbuffer, lose all your current timer/debug/whatever testing of it and try something like this in your .OnComm.commevent=1

DO WHILE THIS.outbuffercount>0
  DOEVENTS
ENDDO

and now present a messagebox or whatever of the status.

One other question: if I use the mscomm1.output to add information to the buffer before the buffer is empty, will that overwrite the buffer or append it to the end?

SWAG, but I believe it appends up to the outbuffersize. This relates to my above question about the data packet size. You may need to take this in account.

Last thought: I suspended my program just after the mscomm1.output = string command and saw in my debug window that the outbuffercount was 57. It sat there (as there was nothing attached to my port at the time) until I typed the following at the commandline:

l_count = mscomm1.outbuffercount

This command changed my debug property to 0!

Most frustrating!

Indeed. What version of VFP, BTW? I really don't think that the debugger is very useful at this point, and may even be upsetting the apple cart. I'll see if I can repeat that here.

If you have 2 ports available, I would obtain a loopback cable and pound the thing using 2 instances of your form and 2 ports.