S7通信探讨

大家好！

如下图片S7-GET PUT 通信

一直以来对REQ的处理都是采用系统时钟脉冲或者自己采用定时器进行脉冲触发，这样就会由于种种原因，例如间隔比较短的发送（发送频率高资源占用多）在PC/PG与PLC建立连接时会导致通信卡死，那么为了合理的规划这个S7通信是不是不应该采用DONE/ERR作为条件触发REQ？类似于MODBUS 的轮询。

希望大家一起探讨一下。

当然也有人会说要速度快为什么不进行PNIO通信，这里只探讨S7不要建议与S7通信无关的，谢谢！！

功能块管脚说明：

CALL “GET”    ,%DB1    //调用 GET，使用背景DB块：DB1；    

REQ　    ：=%M0.7    //系统时钟 2秒脉冲 ；    

ID    ：=W#16#0100    //连接号，要与连接配置中一致，创建连接时的连接号，如图5.所示；    

NDR    ：=%M2.0    //为1时，接收到新数据；    

ERROR    ：=%M2.1    //为1时，有故障发生；    

STATUS    ：=%MW4    //状态代码；    

ADDR_1    ：=P#DB1.DBX0.0 BYTE 10    //从通信伙伴数据区读取数据的地址；    

RD_1    ：=P#DB3.DBX0.0 BYTE 10    //本地接收数据地址；    

https://www.ad.siemens.com.cn/productportal/prods/1500published/Comm/Comm_4.2/Comm_4.2.html

这个题目很好，小白期待探讨学习

楼主厉害厉害。。。

这还用讨论吗？

不是早就说过了不要用时钟直接触发通信任务吗？真是有愧于你这点网龄和积分了哟！

文档编号 48955385

看看这个

我的理解为先触发PUT~再触发GET~是不是等同先发报文再接收解析报文

我现在的做法是20ms间隔触发 上升边缘触发PUT 下降边缘触发GET 

主帖引用的是官方的例子  我自己做的是使用TON 上边缘下边缘触发

我的理解：S7  GET 和PUT都是异步通讯，一般会延迟一段时间周期才会收到Done和Error信号，周期受限于带宽，CPU扫描速度，通讯数据量，连接个数等，有些是不变量，有些是变量，比如某些操作可能占用带宽，比如监视多个程序，扫描某些设备等，下载，启用某些组件读写控制器数据都可能导致这个时间增大，我还见过一些资源分配不合理导致S7通讯缓慢的问题，

只要触发控制参数REQ的时间间隔足够长，也就是牺牲实时性，是没有问题的。但是用Done和Error来触发下一次请求就可以优化这个问题，Done和Error也可能由于编程逻辑问题，导致REQ不再触发的编程bug也时常听闻。而定时触发就像永不停歇的机器，有安全感。

使用DONE 与ERR触发有一点类似于MODBUS 通讯的方式，但是不知道为什么官方的S7通讯例子基本上都是使用CPU的时钟存储器来触发例如10HZ或者0.5HZ这样的频率来执行REQ。

另外提到的带宽与通讯REQ的请求间隔问题，这一点非常与感触，的确是PC在线连接时会大大占用带宽，这个时候S7通讯会卡死，S7通讯间隔时间越短 越明显，那么就需要合理的规划S7 REQ的请求应该是怎么样的，所以才想到是不是应该与MODBUS指令那样使用DONE/ERR作为条件更加合适。

你这不是轮询的概念，只是触发控制参数REQ的另一种方式，轮询是：

1 有超过一次Get Put总量的数据需要通讯，可能需要N次

2 只调用一次Get Put功能块

3 通过动态写入，指定第1次，第2次发送接收参数“ADDR ”  “SD”

这样做好处是节省了通讯任务资源，但是牺牲的是实时性。这才是轮询

通过DONE和ERROR,再根据需要，加上一定的发送延时（延时时间可调）。

完全通过脉冲发送不就是个开环嘛，很可能发生上一次发送没有完成，就触发新的发送请求了！