一客户拿了一个CP441-2（带MODBUS主站狗）过来，说是和FUJI的温控表做MODBUS通讯不上，客户带来了温控表和441，正好公司实验室有一套冗余的414-H系统，以前也没有用过441,正好做个实验，嘻嘻！客户说他按照手册上说的作，就是通不上，把客户的程序拿过来，把硬件组态改一下，下载，硬件正确。把客户的程序看了一下，原来441的MODBUS通讯不是用FB7，FB8，而是用BSEND，BRECV，以前还真不知道。先把客户程序下载下去，触发BSEND发送，441上的TXD灯不亮，查看BSNED参数，发送区选的是DB块，发送长度为6，查看
DB块里的数据，有数据，好象没什么问题。不管怎么样发送灯应该亮啊。后来一想，BSEND，BRECV应该是是基于连接信息的，问客户有没有建立连接，客户说没有。打开NETPRO，果然没有，建立一个PTP连接到OTHER STATION，协议选MODBUS MASTER ，下载。呵呵，感觉应该差不多了，再次触发BSEND发送，TXD灯还是不亮，一通查，没办法，先用ASCII方式通讯一下吧。在硬件组态里把441的MODBUS协议改成ASCII,把NETPRO里的连接也改成ASCII连接，下载，OK，BSEND发送正常，441的TXD灯亮了，说明硬件正常。难道是狗的问题，又查了一通。包括把狗拿下了看了看有没有坏，嘻嘻！再仔细一想，MODBUS方式下，TXD灯都不亮，说明MODBUS程序都没执行，或者执行有错。再打开发次的数据块仔细看发次的数据为02，01，00，00，00，00 。仔细对照MODBUS协议格式，发现问题了，把数据改成02 ，01 ，00，01(这里00也行)，00，01，再次触发BSend，TXD灯亮了，呵呵，果然是数据格式不对，MODBUS狗的程序收到不对数据直接丢了，但也不报错。这是需要SIEMENS改进的地方。接上RS232-485转换器，用电脑模拟MODBUS SALVE,再次BSEND发次，TXD先亮,rcv灯也亮。说明数据正常反回了，再调BRCV，查看接收缓冲区，没有收到数据，用BRCV的NDR信号去触发一个计数器，计数器也没有计数，又查了一会儿，想到RS485是半双工的，就把程序改了一下，让RCV块不是一直执行，而是发送完了之后执行。再下载程序，OK接收数据正常。接收数据块里接收的数据是不包含MODBUS帧头，帧尾的数据。