s7300之间的DP通讯.docx
- 文档编号:26645247
- 上传时间:2023-06-21
- 格式:DOCX
- 页数:15
- 大小:348.46KB
s7300之间的DP通讯.docx
《s7300之间的DP通讯.docx》由会员分享,可在线阅读,更多相关《s7300之间的DP通讯.docx(15页珍藏版)》请在冰豆网上搜索。
s7300之间的DP通讯
s7-300之间的DP通讯
实现Profibus主从站之间的MS通讯
通过图解,说明2个CPU之间通过Profibus实现主从站之间的MS通讯。
这个例子是结合某现场的实际情况来的,实际情况是在2套300系统之间进行数据通讯,由于每个CPU300都带有ET200M从站,所以317的主DP口和315的DP口都只能是主站而不能配置为从站。
并且2套系统之间距离较远,MPI不行,于是就利用了317的MPI/DP口配置成DP口来和315通讯。
1.首先,在STEP7中新建一个Project,分别插入2个S7-300站。
这里我们插入的一个CPU315-2DP,作为主站;一个CUP317-2作为从站,并且使用317-2的第一个端口MPI/DP端口配置成DP口来实现和315-2DP的通讯。
并且创建一个不同于CPU自带DP口的PROFIBUS网络,设定地址。
在操作模式页面中,将其设置为DPSLAVE模式,并且选择“Test,commissioning,routing”,是将此端口设置为可以通过PG/PC在这个端口上对CPU进行监控,以便于我们在通讯链路上进行程序监控。
下面的地址用默认值即可。
然后选择Configuration页面,创建数据交换映射区。
这里我们创建了2个映射区,图中的红色框选区域在创建时是灰色的,包括上面的图中的Partner部分创建时也是空的,在主站组态完毕并编译后,才会出现图中所示的状态。
由于我们这里只是演示程序,所以创建的交换区域较小。
组态从站之后,再组态主站。
插入CPU时,不需要创建新的PROFIBUS网络,选择从站建立的第二条(也就是准备用来进行通讯的MPI/DP端口创建的那条)PROFIBUS网络即可。
组态好其它硬件,确认CPU的DP口处于主站模式,从窗口右侧的硬件列表中的已组态的站点中选择CPU31X,拖放到主站的PROFIBUS总线上,
这时会弹出链接窗口,选择以组态的从站,点击Connect按钮,
然后进入Configuration页面,可以看到前面在从站中设定的映射区域,逐条进行编辑(Edit…),确认主从站之间的对应关系。
主站的输入对应从站的输出,主站的输出对应从站的输入。
至此,硬件的组态完成,将各个站的组态信息下载到各自的CPU中。
通过NetPro可以看到整个网络的结构图。
2.编写程序。
硬件组态完毕,下载,PLC运行之后,数据并不会自动交换。
需要通过程序来执行。
在组态中,input和output区域,也并不是实际硬件组态中的硬件地址,也就是说,input和output并不代表I/O模块的地址和数据。
但是映射区域组态用到的input和output地址,同时也占用了I/O模块的组态地址,就是说,映射区的地址和I/O地址是并行的,不能重复使用。
所以最好在硬件的I/O模块全部组态完毕之后再组态映射区。
映射区的数据交换是通过系统功能块SFC14(DPRD_DAT——ReadConsistentDataofaStandardDPSlave)和SFC15(DPWR_DAT——WriteConsistentDatatoaStandardDPSlave)实现的。
SFC14和SFC15是成对使用的,一个发送一个接收,缺一不可。
数据的通讯也是交互的,可以相互交换数据。
本例中,我们通过简单的数据来验证通讯结果。
首先,我们在程序中插入数据区DB1,前面我们只建立了2个字(2Word)的映射区,于是我们建立如下内容的DB1,为了查看的方便,DB1的前半部分作为接收数据的存储区,后半部分用作发送数据的存储区。
在317和315中我们插入同样的DB1,然后分别在OB1中编写通讯程序。
315(主站)中的程序如下:
317中的程序如下:
其中,程序的LADDR地址,对应的是硬件的映射区组态时本站的LocalAddr中的地址,从站的LocalAddr我们组态的是0,对应的PartnerAddr也就是主站的地址是4。
需要注意的是这里的地址是需要用16进制的格式来表示的,我们组态时是用10进制表示的。
完成之后,我们在各站中插入OB82、OB86、OB122等程序块,这些是为了保证当通讯的一方掉电时,不会导致另一方的停机。
完成之后,将所有的程序分别下载到各自的CPU中,个站切换到运行状态,通过PLC监控功能,设定数据之后,我们监控的结果如下:
上面的表格内容为主站315的数据,下面的是从站317的数据。
可以看到,两个站都分别将各自的DBB4—DBB7数据发送出去并被另一方成功接收后存储在各自的DBB0—DBB3中。
验证中,我们将一个站的CPU切换到STOP状态,可以看到,另一个站的CPU硬件SF指示灯报警,但PLC正常运行不停机。
待该站恢复之后,报警自动消失。
扩展问题:
在一个站的CPU掉站之后,另一个站的接收数据区显示的仍然是最后一次接收到的数据,并且,即使在这种状态下,居然仍然无法修改该数据区内容。
这样就存在一个问题,当前站需要知道当前接收数据存储区的内容是否是实时的数据。
如何判断。
大概思路:
方法1,用以前的方法,在每个数据接收周期开始前,将已接收数据清空。
这样当接收周期内接收不到新的数据时,就可以察觉到。
但是问题是,SFC14和SFC15没有接收是否完成、是否成功等标识位,并且,在接收不到新的数据时,原有数据不能修改。
此方法不通。
方法2,通过别的方式方法检测两个站之间的通讯状态。
心跳?
在SIEMENS的官方文档中,有这样的描述:
主站:
主站掌握总线中数据流的控制权。
只要它拥有访问总线权(令牌),主站就可在没有外部请求的情况下发送信息。
在PROFIBUS协议中,主站也被称作主动节点。
从站:
从站是简单的输入、输出设备。
典型的从站为传感器,执行器以及变频器。
从站也可为智能从站,入S7-300/400带集成口的CPU等。
从站不会拥有总线的访问授权。
从站只能确认收到的信息或者在主站的请求下发送信息。
从站也被称作被动节点。
另外,SIEMENS对SFC14/15的描述也分别是:
用于读取Profibus从站的数据/用于将数据写入Profibus从站。
根据这些描述,通过CPU集成口通讯这种方式下,作为从站的CPU应该属于“智能从站”,但是SIEMENS的描述中,却没有说智能从站和普通的从站之间有什么区别。
那么根据上面的主从站的描述,主站可以主动的获取到从站的数据,并可以自主的将数据写入从站;而从站必须在主站的指令下获取或者发送数据。
而在本例中,这些说法似乎无法成立。
本例中,SFC14、SFC15是成对使用的,不论在主站上还是从站上,主从站之间的SFC14和SFC15必然是需要成对出现的。
也就是说,任何一方没有SFC15运行的的话,另一方的SFC14都读不到数据。
而任何一方没有SFC14的话,另一方的SFC15发送出来的数据也无人接收。
至少从这点看来,看不出主从站有什么区别。
不过,联想到以前曾经做过S7-300和MM430的Profibus通讯,该通讯方式中,显然MM440是作为从站出现的,所以在正确组态之后,只需要在主站(CPU)中写好SFC14/15即可,当然,MM440中我们也写不进去程序。
那么在这种方式中,可以说是完全的遵守了SIEMENS官方文档中的说法。
同时也说明,在“智能从站”这种方式下,并不遵守SIEMENS官方文档中对从站的描述。
再次研究SFC14/15的收发状态,发现,可能是因为数据的存在是过程映像中,所以只要SFC15发送过一次,数据即存在于过程映射中,SFC14随时都从映像中读取数据,所以存在前面说的,SFC14运行过程中,是无法修改接收数据存储区的数据的。
脱离SFC14/15,而使用MOVE方法的研究:
不使用SFC14/15,而是利用组态的时候产生的I/O地址来传数据。
根据创建过程映射区时的组态信息,我们写写出了如下的程序:
在主站315-2DP中:
在从站317中:
其中,M位的使用是测试程序的不同情况下使用的临时点,和本程序功能无关。
由此可见,在这种方式下,因为组态时组态的地址是系统的I区和Q区,所以是可以用MOVE来实现通讯的,但是同时也存在的问题是,这种方式下,通讯所用的I/Q区占用了S7-300的系统区,而S7-300的系统区可使用范围是有限的,所以在系统的实际I/O模块较多时,通讯的数据量将会变得更加有限。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- s7300 之间 DP 通讯
![提示](https://static.bdocx.com/images/bang_tan.gif)