E
I've heard that non-real time operating systems (e.g. Linux, Windows) don't have 100% compliant implementations of the ModBus standard. Apparently, due to hardware limitations, these OS's can't measure the t1.5 and t3.5 framing times defined by the standard.
Exceeding t3.5 does not matter for sending of packets. It does matter, however, for slaves receiving broadcast messages. In theory, a master could broadcast several frames with only t3.5 between each frame. If a slave can't detect the t3.5 silence between frames, then it will think that all the frames are one message. I've been told that the solution is to use a different mechanism based on "implied length".
If master nodes in the real world use a much longer time between frames, is that documented anywhere? Is it t10, t100, t1000? Our communication board will be performing some webserver functions, which may occupy the processor for long periods of time. I want to make sure that between the ModBus driver code and our higher-level software we can meet whatever the unofficial standard is. I also need to make sure that our final test procedure doesn't impose unrealistically tight (or loose) timing requirements on our final system.
Exceeding t3.5 does not matter for sending of packets. It does matter, however, for slaves receiving broadcast messages. In theory, a master could broadcast several frames with only t3.5 between each frame. If a slave can't detect the t3.5 silence between frames, then it will think that all the frames are one message. I've been told that the solution is to use a different mechanism based on "implied length".
If master nodes in the real world use a much longer time between frames, is that documented anywhere? Is it t10, t100, t1000? Our communication board will be performing some webserver functions, which may occupy the processor for long periods of time. I want to make sure that between the ModBus driver code and our higher-level software we can meet whatever the unofficial standard is. I also need to make sure that our final test procedure doesn't impose unrealistically tight (or loose) timing requirements on our final system.