热门搜索:

上海西邑电气技术有限公司成立于1996年。在西门子公司广大同仁和工控领域各界朋友的关怀下埋头发展,一路走来已成西门子合作伙伴中的佼佼者。总部设在上海,办公面积1500多平方米,员工150余人。

    西门子WINCC软件

    更新时间:2020-09-20   浏览数:16
    所属行业:机械 电工电气 工控系统及装备
    发货地址:上海市金山区  
    产品规格:西门子WINCC软件
    产品数量:100.00台
    包装说明:全新原装
    单 价:面议
    型号西门子WINCC软件 颜色白色 尺寸80*80*80 产品别名西门子WINCC软件 用途工业 西门子

    西门子WINCC软件

    WinCC与S7-1200 CPU的OPC 通信

    WinCC V7.2以前版本中没有与S7-1200 CPU 通信的驱动,所以WinCC与S7-1200 CPU之间通过以太网的通信,只能通过OPC的方式实现。S7-1200 作为OPC的Sever端,只需设置IP 地址即可。上位机作为OPC 的Client端,通过SIMATIC NET 软件建立PC Station 来与S7-1200通信,实现步骤见 SIMATIC NET OPC 。
    建立好PC Station 后,WinCC中的实现步骤如下:

    1. 建立所有WinCC中要用到的变量

    首先在OPC Scout中建立好所有WinCC中要用到的变量,步骤 OPC scout 

    2. 添加新的驱动

    打开WinCC 软件新建一个项目,用鼠标右键点击“变量管理”,在快捷菜单中点击“添加新的驱动程序”,添加新的驱动:Opc.chn。如图1所示。



    图1. 添加一个新的驱动new driver, OPC driver

    3. 在WinCC中搜索及添加OPC Scout中定义的变量

    首先用鼠标右键点击OPC Groups ,在快捷菜单中点击“系统参数”,如图2所示。


    图2.进入系统参数system parameter

    然后选中OPC.SimaticNET,点击“浏览服务器”按钮进行搜索。如图3所示。



    图3.选择服务器浏览

    4. 建立新连接并添加所需变量

    在变量列表中选择所需要的变量,点“添加条目”按钮添加所需变量,此时会自动要求你建立一个新连接,并将变量添加到这个连接中,如图4所示。

    西门子WINCC软件

    图4.添加变量并建立连接new connection,connection name,select connection

    成功添加完变量后,WinCC中变量显示,如图5所示。完成以上所有配置,就可以在WinCC里监控这些变量了。



    图5.从OPC Scout中成功添加变量item setup


    当我逐步掌握这些通信的原理和背景知识,就可以游刃有余的解决来自客户的问题和处理各种相关的案例。只能说“天空飘了5个字,那都不是事!”。然而,当问题出现,解决相关问题的知识都不是独立存在的,都是要各种相关的系统知识去尝试从而解决它。而且当我面对这些问题的时候,从来没有绕路过去,即换个模块,换台设备或环境试试,都是要正面面对它,即使棘手,也还是要不断的测试,推论,再测试,再推论,直到发现真正的原因。


         当S7-1500PLC横空出世的时候,相关的通信一样我也要过一遍,看看是否存在一些不同,或者特殊的地方,已解决来自客户的问题。绝大部分的通信行为性能都是和S7-400PLC相同的,没有质的改变。然而在CPU1500的X1接口存在一个选项,称为 “Limit data infeed into the network” (CPU1518的X2接口也有该选项) 。这个选项根据手册和在线帮助,我没有看明白到底是限制外来的流量还是自己产生的流量,而且为什么1500CPU有这个选项,300/400PLC却没有?


         为了弄清这个基本方向,我向总部求证了这个该参数的作用。原来300/400PLC都是有的,只不过没有开放,都是默认勾选的,而对于1500PLC这个参数开放了,我们可以根据自己的应用来调整该参数。那么此参数的作用是用于限制控制器所产生的NRT数据对于整个网络的影响,例如,即使产生大量的TCP/IP的数据涌进网络中,使能该参数,通信负荷可以被限制且平滑的进入到网络中,而不必产生负荷高峰,从而影响到其它的数据通信。


                                  

     

          那么需要实验来验证一下限制网络负荷是如何限制的。取两个1500CPU,设置Communication Load为50%,目的就是不限制时间片上的通信。建立若干个TCP的连接,在一侧全部是TSEND,另一侧全部是TRECV,以尽可能快的频率去触发发送使能,参考前面的AN Q0.0的程序,只需要改成M0.0即可,然后使用跳转程序逐一投入发送功能块,通过Wireshark进行抓包,然后使用Wireshark IO graphs进行分析,分析发送TCP的帧的带宽流量。结果如下,左侧的图形使能了“Limit data infeed into the network”,右侧图形中CPU没有使能该参数,由于操作失误,左侧图形中的1,2发送同时投入,所以会看见比右侧的高,然而这并不影响终的结果,接着投入3,4,5,发现到第5个发送投入时,左侧的限制非常明显,约为14Mbps,而右侧图形中没有做相应的限制,占用网络带宽约为20Mbps。这就是这个参数的作用和意义!那么这是否与Communication Load有一定关系呢?还是和OB1的循环周期相关呢?后者说限制负荷高峰这是一的方法吗?


         这些问题似乎前面都提到过,都是老问题了,需要澄清这些问题,看来是需要老生常谈了。

                    

     

     当你弄清楚事物运动的本质,那根据此事物的任何问题都可以迎刃而解。所以理解TCP的发送功能块的参数,例如Done或Busy,就可以解释和理解一些现象,解决现场出现的一些问题。不过,在探索TCP/IP通信的过程中还有许多问题和概念需要去澄清和理解。通过测试,可以发现在TCP的通信过程中,存在两个缓冲区,一个是Shadow Buffer,另一个是堆栈Buffer。根据前面的测试,证明前面的推论是正确的,也就是说Shadow buffer的大小与发送数据的大小一致,而TCP/IP的堆栈大小为固定的8K,也就是滑动窗口的大小是8K,用来调节发送端的发送数据的速度。


         为了进一步证明两个Buffer的作用和概念,实验仍然是必不可少的,此时,网线连接一切完好, 而接收功能块的使能为0,也就是说在建立正常的收发后,关闭接收功能。此时,还是按照之前的收发4K,那么发送6次后,Done=5,Busy=1。这表示在接收侧具有和发送侧一样的缓冲区,大小一致。前三次发送,填充了接收侧的2个缓冲区,分别是4K和8K,后三次发送,填充了自己的2个缓冲区,分别是8K和4K,这进一步证明两个Buffer是存在的,而且对于堆栈Buffer大小是固定的8K,属于系统特性,对于Shadow buffer应该是和发送和接收的DB大小一致。


         在测试的过程中,还发现了一个奇怪的现象。就是在接收侧CPU重新启动后,建立TCP连接,接收功能块T_RECV不使能的情况下,还是按照上述的方式发送4K数据,那么发送5次后,Done=4,Busy=1。通过改变收发字节的数量,例如1K,反复测试的结果,都是类似的。那么发送了5次,前二次填充了接收侧的堆栈Buffer,为8K,后面三次填充的是自己的2个缓冲区,分别是8K和4K,这就表明Shadow Buffer生成需要使能相应的功能块,否则不能创建相应的缓冲区,而Stack Buffer属于系统特性,是随着TCP连接的建立而存在的。


         上述的测试都是收发的数据长度小于数据一致性8K字节,那么如果大于8K会是如何呢?测试收发16K,那么还是按照先前的测试条件,测试结果发现,发送2次,Done=1,Busy=1,这是怎么原因?如果按照之前的判断结果,Shadow buffer应该是16K,堆栈Buffer是8K,应该发送3次,Done=2,Busy=1。然而实验的结果表明不是的,这说明哪里出了问题,或者理解有误。这又该如何判断呢?


         经过分析,还是从数据一致性入手,按照前面提到的方法测试数据一致性大小为8K,即[8191]和[8192]自增1的程序来判断,确实是8K的数据一致性。那么是不是Shadow buffer的大小大就是8K呢?带着这样的假设,如果发送2次,Done=1,Busy=1,那么意味着次发送16K,占满了接收侧的Shadow Buffer和堆栈Buffer,分别是8K,总共是16K,第二次的发送占满自己发送侧的两个缓冲区,也是总共16K。经过多次验证,表明Shadow buffer的大确实是8K。


         那么前面有些结论并不是十分的充分,现在我来总结一下,Done信号表示的是DB区的全部数据通过Shadow Buffer推送到堆栈Buffer才置位。因为从16K数据可以看到,第二次的16K的发送实际上是有8K数据从Shadow Buffer推送到堆栈Buffer中的,但是Done并没有置位,次的完整16K是经过了Shadow Buffer推送到堆栈Buffer中的,Done置位。Shadow Buffer,只有当调用TSEND或者TRCV时,Shadow Buffer才生成,且大是8K,如果收发的DB长度小于8K,那么Shadow Buffer的大小与DB的大小一致,否则,保持大的长度为8K。


         此外,终从这些测试和结论,还能够得出新的结论就是Shadow buffer的大小决定了数据一致性的大小,这个结论应该具有普遍性,也就是说S7通信的数据一致性也应该是由Shadow Buffer的大小来决定的。是不是真的是这样,我们拭目以待吧。


    西门子WINCC软件



    http://www.hyzdhxt.com