言

自由口通讯是工业现场常见的一种通讯方式。由于依靠编程实现，通讯对象通常又是一些仪表、打印机等第三方设备。因此碰到的问题相对较多。处理起来也比较棘手。通常自由口通讯的***步，就是对S7-200 SMART 通讯端口进行定义，如波特率、数据位、校验位以及停止位等。

那么这些参数的含义是什么？它们的定义又会对通讯产生怎样的影响？在故障诊断中如何调整？下面我们就通过几个案例给大家做个分享。
案例一：字符接收缺失

故障现象

某现场使用S7-200 SMART 自由口通讯协议接收仪表数据。以常用的字符间定时器作为接收消息的结束条件。程序中规定定时器时间寄存器SMW92=5ms，传输7个数据位，偶校验。实际测试时发现当通讯波特率为4800bps、9600bps、2400bps时均可以正常接收到仪表数据。但是当波特率设置为1200bps时，却只能接收到首字节的数据。 

案例分析

1200bps波特率代表每秒可以传输1200bit，1秒等于1000000us，可以计算出每一个bit需要的时间约为833.33us。 

传送的数据由多个字符组成。每个字符由1位起始位+7位数据位+1位校验位+1位停止位=10位构成。 

可以计算出传送1个字符需要的时间为8333.3us，即8.333ms，也就是说传输1个字符至少需要8.3ms。 

如图1所示。如果字符间定时器SWM92小于8.333ms,则接收到一个字符后终止，后面的字符无法接收到。 

 

图1.计算发送一个字符需要的时间

 

图2为字符间定时器作为接收结束条件的示意图。接收到每个字符的停止位时重新启动字符间定时器，字符间的时间超出 SMW92中指定的毫秒数，接收消息功能将终止。之后接收到的字符被忽略。因此会出现以上的故障现象。

解决的方法是：调整波特率或者调整定时器SMW92的时间。想必您对自由口参数以及接收条件了解之后，对以上问题便有了深刻的理解，当然也就更好排查。 

 

图2. 使用字符间定时器作为接收结束条件

 

案例二：接收无法终止

故障现象

某现场，当从站故障或者通讯电缆损坏时， 接收端CPU 的通讯端口始终处于接收状态。并且无法发送数据。由于一直接收不到数据，后续的读写操作也无法进行。

当遇到这种情况，我们该如何结束当前端口的接收状态，以便继续执行后续自由口的发送和接收操作呢？

案例分析

有两种处理该问题的方法： 

1. 使用任意字符检测作为接收消息的起始条件，选择消息定时器和其它结束条件组合作为接收消息的结束条件。 

原理如图3所示，这种接收条件下，RCV接收指令触发的同时开始计时，计时时间到则结束信息接收。也就是说这种方式下，接收操作只和接收时刻和消息定时器两个因素相关。 

当触发RCV指令并且到达消息定时器设定的时间后，即使没有接收到任何数据，也会结束当前的接收状态。反之，如果消息定时器的时间到达，但是实际接收数据还没有结束，晚于定时时间到达的信息将被忽略。

 

图3 使用任意字符开始消息接收和消息定时器终止消息接收 

 

2. S7-200 SMART CPU 在发送完成中断中执行 RCV 指令并捕捉信息接收的开始时间。如果捕捉间隔时间超出一定时间依然未接收到信息，则认为信息接收超时，通过程序人为终止信息的接收。 

使用图4中的BGN_ITIME指令记录执行RCV时的起始时间，图5中的CAL_ITIME指令记录执行RCV的经过时间，当执行RCV的时间超过100ms,则禁止RCV接收消息。 

 

图4 使用捕捉时间间隔指令处理程序 

 

 

图5 使用捕捉时间间隔指令处理程序 

 

通过以上两种方法，就可以帮助我们解决当从站故障或通讯电缆损坏时，通讯接口一直处于接收状态的问题。

 

特别是由于某些情况下PLC发送的数据，仪表并没有接收到时。此时仪表也不会反馈数据给PLC，则PLC会一直处于等待状态。即使此时仪表或者线路恢复正常，仪表由于没有再次接收到PLC的数据请求，也不再会反馈数据的问题。 
案例三：字符接收异常

故障现象

S7-200 SMART A使用自由口通讯协议发送数据给S7-200 SMART B，PLC A发送的数据为16#41和16#42，但是PLC B接收到的数据是16#5F和16#2F。接送和发送的数据不一致。故障现象如下图所示： 

 

图6为PLC A的程序，利用自由口发送指令XMT发送16#41、16#42。 

 

图6 PLC A利用XMT指令发送16#41、16#42 

 

图7为PLC B，利用RCV指令接收数据，接收到2个数据，分别是16#5F和16#2F，同时注意到接收信息状态字节SMB86***低位为1,即“终止接收消息，原因可能为奇偶校验、组帧、中断或超限错误”。 

 

图7 PLC B 利用RCV指令接收数据 

 

为什么会出现这种情况？其实***终造成该故障现象的原因是通讯线路接反。下面我们从数据帧的角度来分析问题原因。 

 

案例分析

如图8所示，为PLC发送的正常的数据帧结构，包括1个起始位、8个数据位、无校验以及1个停止位。 

 

图8 发送的数据帧结构 

 

根据如上的数据帧，该如何区分出哪些是数据呢？ 

 

我们知道每一个数据帧包含多个字符，每一个字符都包含起始位、数据位、0或1个校验位以及1个停止位，其中起始位作为每一个字符的起始标志，为低电平，即只有当检测到了起始位后，之后的数据才会被识别为数据位。 

 

***个起始位之后的数据为2# 0100 0001=16# 41， 

第二个起始位之后的数据为 2# 0100 0010=16# 42， 

当线路接反，PLC发送的数据帧为以下结构，

 

图9 接收的数据帧结构 

 

同样的，我们需要找到低电平的起始位，如图10所示， 

 

图10 接收的数据帧结构 

 

***个起始位之后的数据为2# 0101 1111=16# 5F 

第二个起始位之后的数据为 2# 0010 1111=16# 2F 

我们注意到，2F之后没有高电平，即没有停止位，所以PLC B接收到数据后报故障是由于组帧错误，即接收的到16#2F并不是一个完整的组帧结构。 

 

通过以上的分析，我们了解了为什么线路接反后，会得到不一样的数据。通过了解自由口通讯的数据帧结构的方式，我们就能够准确的判断出问题背后的原因。