Hi Shawn,
I'm glad you got it going. Reading RCREG clears the error but what causes the error in the first place? I guess if it works and you get the data you expects there's no problem really but why does it indicate framing error?

Your function 3 request from the PC is 8 bytes (Adress(1), Function(1), StartingAdress(2), NumberOfRegs(2), CRC(2)) and the response is 21 bytes (Adress(1), Function(1), ByteCount(1), Data(16), CRC(2)) so there should be 30 bytes if I'm not mistaken. Why is there 31?

Also, I think that the interframe delay is applied by the PC too which means that it too has to see the line idle for 4ms before it calls the frame complete - even though it knows how many bytes to expect. Then IT needs to process the frame before it's ready to send a new one. And I don't think the PC timing is very precise so it's hard to say exactly how long it's actually waiting. Obviously I don't know the exact details of how MBPoll works but I think your timings may be a bit better than you think.

Turn on a LED when the RX interrupt fires the first time in a new frame and turn it off when you pull the "RTS"-line low, that will tell you exactly how long time the PIC is spending. Of course, there's not much to do to the time it takes receiving and transmitting so perhaps set the LED when the 4ms timer timesout and reset it when the first character is put in the TXReg, that will show you exactly how long it takes to actually process the frame. (Or use a timer to measure the execution time, put its value and in of the registers you're reading and you'll get the result in MBPoll).

/Henrik.