Frustrated Modbus

[shawn]

I got it, I'm still not sure what difference it made between using the rs 485 and the rs 232 bus, but I fixed the RCSTA.2 error problem. Turns out reading the RCREG clears the frame error. So I put the routine that checks for the error after the routine that reads out the RCREG when a character is detected. That seems to make sense in my mind.

So this is how it tested out. I set the scan rate on my Modbus Master to 1mS. Obviously that is rediculous but I wanted to dump all I could at it. I sent a function 3 command from the Master to read 8 one word registers every 1ms. What I got was 1308 TX RX round trips in a minute with no errors on the master or the slave. That comes out to roughly 46mS per TX RX round trip which I thought was pretty good since every byte sent and received takes about 1mS. There was 31 bytes in every TX RX round trip, so theres about 30mS. Then there is a 4mS wait for end of frame delay. That puts me up to 34mS, so it looks like I am waisting 12mS a second which I would like to get down but I am not to worried about at this time.


I am going to keep posting problems with this project on this post, and eventually I will post the final modbus code on here.
Thank You
Shawn

[HenrikOlsson]

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.