西门子S7-300CPU代理商
西门子S7-300CPU代理商
西门子S7-300CPU代理商
西门子S7-300CPU代理商
西门子S7-300CPU代理商

西门子S7-300CPU代理商

参考价: 面议

具体成交价以合同协议为准
2023-07-19 17:43:02
425
属性:
产地类别:进口;
>
产品属性
产地类别
进口
关闭
上海邑斯自动化科技有限公司

上海邑斯自动化科技有限公司

免费会员6
收藏

组合推荐相似产品

产品简介

西门子S7-300CPU代理商
某现场使用S7-200 SMART 自由口通讯协议接收仪表数据。以常用的字符间定时器作为接收消息的结束条件。

详细介绍

  西门子S7-300CPU代理商
 
  自由口通讯是工业现场常见的一种通讯方式。由于依靠编程实现,通讯对象通常又是一些仪表、打印机等第三方设备。因此碰到的问题相对较多。处理起来也比较棘手。通常自由口通讯的第一步,就是对S7-300 通讯端口进行定义,如波特率、数据位、校验位以及停止位等。
 
  那么这些参数的含义是什么?它们的定义又会对通讯产生怎样的影响?在故障诊断中如何调整?下面我们就通过几个案例给大家做个分享。
 
  案例一:字符接收缺失
 
  故障现象
 
  某现场使用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接收消息。
 
  通过以上两种方法,就可以帮助我们解决当从站故障或通讯电缆损坏时,通讯接口一直处于接收状态的问题。
 
  特别是由于某些情况下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个停止位。
 
  根据如上的数据帧,该如何区分出哪些是数据呢?
 
  我们知道每一个数据帧包含多个字符,每一个字符都包含起始位、数据位、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并不是一个完整的组帧结构。
 
  通过以上的分析,我们了解了为什么线路接反后,会得到不一样的数据。通过了解自由口通讯的数据帧结构的方式,我们就能够准确的判断出问题背后的原因。
 
  总结
 
  以上分享了几个常见的通问题以及处理思路。 实际在工业现场中我们会遇到各种各样的通讯方式和形形色色的通问题。可能是工业以太网的、Profinet通讯的、也有可能是MODBUS RTU通讯的……
 
  那么如何快速准确的处理项目上可能会遇到的各种通问题呢?西门子工业1847学习平台上的《S7-200 SMART通讯小技巧》系列视频希望能够帮到您。在此系列视频中,我们归纳总结了一些典型应用场景下通问题的处理方法和注意事项供大家参考。初步规划内容如下:
 
  •您了解自由口通讯端口参数的定义吗?
 
  •自由口通讯之XMT指令
 
  •自由口通讯之RCV指令
 
  •不使用RCV指令如何接收数据?
 
  •自由口通讯接收不到数据如何排查?
 
  •MODBUS RTU如何估算数据的刷新时间
 
  •PROFINET IO通讯诊断方法以及通讯读写等技术内容
 
  西门子S7-300CPU代理商
上一篇:S7-300/S7-300F的用途应用 下一篇:巧用 SIMATIC PLC SNMP 库查询 IP 地址冲突
热线电话 在线询价
提示

请选择您要拨打的电话:

当前客户在线交流已关闭
请电话联系他 :