Modbus rtu over rs232, Master sending requests continuously

R

Thread Starter

Rachit Kumar

Hello,

I am implementing MODBUS RTU over serial line (rs232, and later also rs485).

I have read the specification and found nothing stating that the Master should always wait for a response from the slave before sending another request. So, I am considering the case where the Master sends multiple requests, and then the slave processes them one by one, and then sends back the response for all the received requests.

Should I consider this case while implementing MODBUS or should I simple implement the case where Master sends one request, waits for the response from slave (till timeout) and then sends the next request and so on.....
 
The diagram on page 4 of the Modbus Application Protocol Specification V1.1b shows the client initiating a request, the server processing the request and initiating a response, and then the Client receiving the server's response.

While the standard might not explicitly state that the master waits for the slave's response, the diagram shows such and common practice over 3 decades shows that every implementation that is expected to function as a Modbus protocol does exactly that.

You can create any protocol you want, but if you call it Modbus and it doesn't perform like Modbus, the people who pay for data communications using your 'whatever protocol' are likely to get mad, not pay their bills and complain about it on forums like this one.

In answer to your question, you should implement the case where the Master sends one request, waits for the response from slave (or until it times out) and then sends the next request and so on.
 
R

Rachit Kumar

Thanks David for the reply.

I was just not clear about the correct implementation, obviously the whole idea of a fieldbus is that the protocol is understood the same way by all devices on the line.

Yea, so now I know exactly that MODBUS client sends the request, slave processes the request, send the response back to the Master, and then the master sends another request and so on...

This was very critical, because then I would have to buffer multiple frames and save them accordingly. This 'proper' implementation saves me a lot if headache, and is much simpler.
 
Top