APP下载
登录
MODBUS 是采取一问一答的协议, 如果物理层 ( 硬件层 ) 使用 RS-232 或是 RS-422 因为是 “接收” 与 “发送” 分离, 因此一般不会发生传送遗失问题; 但如使用 RS-485 时, 因为是 “接收” 与 “发送” 同在一条传输线上, 因此容易造成资料遗失.
造成资料遗失的问题取决主因是 [ Master发送最后一笔资料后哪时释放发送权 ] 问题 ? 根据标准 MODBUS 规则是等待 四个 传输字符当间格. 举例来说 在 9600,E,8,1 传输率上则必须间格 ( 1.1416ms * 4 ) 既一般说的 4ms 空闲时间.
但; 实际上有一问题; 如果产品定义只是 MODBUS I/O 这 [空闲问题] 可能可以接受, 因为 CPU 可以有很充分时间等待; 若产品是 人机或是PLC 这4ms可能就会有问题, 当然解决方式可以使用双CPU来解决, 既是用一颗CPU专门处理传输问题. 因此许多人机与 PLC 都是以最后一个字符传输完毕来区隔; 事实证明这种传输方式也是有效. 但要让整体传输能缩短空闲时间其实可以在接收MODBUS码五个以内 ( 依句柄不同 ) 既能得知总共会接收多少个码; 因此既可缩短或几乎不需要 空闲时间 .
但不管是双CPU或是单CPU来处理 MODBUS 协议处理, 想要减低传送时间耗损, 我们必须在解析MODBUS协议的工作上充分利用其传输特性. 并避开 ”盲点” .
如下照片, 我们可以用以解说 “盲点” 误区
1. “1”是Slave1回复Master, 在发送最后一笔资料立即Master 既马上回复.
2.是 Master 传送完毕, 被呼叫到的 Slave2 回复状况, 这回复是Slave2 故意延迟一个传送字符时间.
这是已经避开误区的做法, 但避开误区的理论则为如下 :
1.主机 ( 上位机 如 PC / HMI / PLC ) 有许多传输部分处理都是引用高阶内核去写, 常见使用 “C语言” 开发. 在这我先声明不是批评 “C语言 “, 但因为一般上位机很复杂, 如果没有一些功力很难用原生汇编语言来写. 因此 使用者很难自行完全掌握目前工作时序.
2.上位机处理 “传送 / 接收 “ 都是用 “中断” 来处理, 也就是对上位机来说 由其 “传送 / 接收 “ 应件完成的 中断来引发进一步数据处理.
3.由第 ”2” 状况我们可以得知照片 Slave1 回送后 Master 可以马上发送理由. 因为对 Master 而言它确实是完整接收完资料, 其短暂的延时则为其数据处理时间.
4.由第 ”2” 状况我们可以得知照片 Master 送完后 Slave2 必须延时一个字符时间发送理由. 因为对 Master而言它确实是完整发送完资料, 对Slave2而言它确实是完整接收完资料, 但如果Slave2马上将RS485 硬件切入发送模式并开始发送, 对 Master 而言其发送刚结束也正准备离开 “串移中断程序” 此时Master并没放开 RS-485 硬件发送模式, 这时将会引发 “总线冲突” 此冲突会导致 主机 接收硬件第一时序第一个位无预期错误. 但糟糕的是这会引发主机 “接收硬件” 开始工作, 而导致错误.
5.由上 “4” Slave2为了要避开冲突. Slave2 在接收完 Master 后也静空一个 “传送字符时间” 在将 RS-485 由接收转为发送.
×
热门文章
