pymodbus v2.5.3 RTU服务器framer帧丢失及亚秒性能问询

pymodbus v2.5.3 自带的同步RTU framer 完全支持1s以内间隔的请求处理，常规工业场景下100ms间隔的轮询都可稳定运行，你当前用的600ms请求间隔远低于framer性能上限，不存在性能不足的问题。

• 测试逻辑不符合Modbus RTU半双工交互规则：你当前采用"只接收请求不回复"的测试方式，会导致客户端等待响应超时后直接触发重传，前后两次发送的帧会在服务器串口缓冲区形成粘包。而RTU framer是靠3.5字符静默间隔判定帧边界的（9600波特率下该间隔仅4ms不到，115200波特率下仅0.3ms），粘包后framer会把两帧拼接成一帧做CRC校验，校验失败直接丢包，这是半数包在校验阶段丢失的核心原因。
• 串口超时参数修改未生效：pymodbus v2.5.3的同步RTU服务器不会直接使用你手动设置的串口超时值，framer会在初始化时根据当前配置的波特率自动计算读超时阈值，你手动修改为500ms或者3s都不会覆盖内部计算值，调整后自然没有效果。
• 特殊功能码帧被内置校验规则拦截：你需要处理的功能码43（MEI）自定义帧、广播帧，如果只在业务回调层做处理，framer会先按照内置的标准Modbus帧长度规则做校验，部分厂商自定义的MEI帧长度不符合标准校验规则，会被framer直接丢弃，根本不会流转到业务处理层。

• 废弃"只收不回"的性能测试逻辑：按照Modbus RTU半双工规范，客户端必须等收到服务器回复后再发下一个请求，正常交互场景下帧间隔稳定，不会出现粘包问题，只收不回的测试结果没有实际参考价值。
• 特殊帧处理逻辑前置到framer层：重写RTU framer的包校验方法，在内置CRC、长度校验执行前先做字节序列匹配：遇到字节序列为00 2b 0d 01 01 7c 77的广播请求直接清空缓冲区丢弃；遇到字节序列为01 2b 0e 01 b4 70的设备ID1的MEI请求，直接走自定义的设备标识回复逻辑，跳过内置的功能码43标准校验流程。
• 适配系统调度抖动：如果部署环境系统实时性一般，可以将framer内部用于判定帧结束的t3.5间隔参数适当放宽到10ms，避免系统调度导致的帧间隔波动触发误判，该参数对应ModbusRtuFramer类的_t35属性，初始化framer后直接修改即可。

内容的提问来源于stack exchange，提问作者Perzade