热门搜索:

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

    西门子WINCC V7.5亚洲版软件

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

    西门子WINCC V7.5亚洲版软件

    PCS 7 OS画面创建与Graphic Designer图形编辑器应用

    PCS 7OS项目为集成式项目,过程画面在SIMATIC Manager 工厂视图中插入,而不是在WINCC图形编辑器中直接插入。

    应该为每一个工厂层级创建惟一的PDL文件,并为该层级分配ASOS

    西门子WINCC V7.5亚洲版软件

    工厂层级名称和PDL文件名不能包含特殊字符,不建议使用中文名,如要显示中文,可以通过修改显示ID名称来实现。。

     

     

     

    OS编辑后,会根据工厂层级结构生成画面树结构。

     

    并在过程画面中根据AS程序插入对应的块图标。在OS项目中,除了用户创建的过程画面PDL文件外,还有大量以@符标识的系统画面文件。OS的运行需要这些系统画面文件进行支撑。

    块图标的位置可以根据P&ID图进行位置调整并保存。而静态画面背景、管道流程等工艺图形需要用户自己在图形编辑器中绘制。

    也可以在画面中插入WINCC的智能对象、控件进行一些自定义功能,参考WINCC的帮助文档。

     

     

     

       掌握和理解PLC的时间片和CCP通信,对于测试WinCC和S7 PLC之间的通信性能,是事半功倍的。因为对于PLC一方,那里已经没有秘密了,剩下的WinCC一方只需要根据以前的实验和结果去推测,应该不会很难。


         通过Wireshark抓包,可以看见前面实验的测试结果。序列7,由WinCC向PLC发送请求任务-读数据,在大约3秒钟左右,PLC发送读响应-序列13。中间间隔了3秒钟左右的响应时间是那么原因?与画面周期的2秒有关,还是CPU的循环周期5秒相关?序列23,由WinCC向PLC发送的请求任务-写数据,经过大约4.4秒,序列34做出该任务的响应。 这4.4秒应该对应了PLC的循环周期?然后序列36重新再次由WinCC向PLC发送请求任务-读数据,在大约5秒钟左右,PLC发送读响应-序列46。5秒钟左右的响应时间似乎与PLC循环周期的5秒对应。然而这些时间其实都是无法有根据的判断的。

                 

     

         时间还是时间!判断这个问题的关键还是时间!回过头再看,发现序列13,34,46之间的时间差异值是5s,这个时间很精确,这与CPU的循环周期完全一致。那么同前面的PUT/GET Server测试的结果一样,这也意味着CPU的通信响应发生在CCP。而且这里面看报文还透漏一个信息就是Job,也就是帮助文件里面说的 “任务” ,这样就似乎清晰了很多,现在从这里看是CPU的每个周期处理都在处理一个任务,这就能理解帮助文件中提到的禁用循环模式时,一个周期只能处理一个任务。


         此外,从报文里还能看出在这个条件“禁用by PLC”,WinCC和PLC之间的通信方式无论读还是写,都是WinCC发送任务请求,PLC给予任务响应。这样在回过来看报文中的响应时间,3s,4.4s,5s这就好理解了,请求来,一个周期内给予响应。


         这样上述的结论相对来说很清晰,不过这个实验中是PLC的循环周期>WinCC的变量周期,那么再看看PLC的循环周期<WinCC的变量周期时的情况是如何的。PLC的循环周期5秒保持不变,修改画面的变量周期为10秒。序列16,由WinCC向PLC发送请求任务-读数据,在大约4秒钟左右,PLC发送读响应-序列21。序列62和序列69是同样的表现。而序列69和序列21的时间间隔是15秒左右,这是PLC的循环周期5秒与WinCC的变量周期10秒的和!?


          没有看错吧?没有。也就是说目前的测试结果的结论就是在当WinCC的变量周期小于PLC的周期时,基本上按照PLC的扫描周期进行变量的响应。大于PLC周期时,按照PLC的扫描周期与变量的扫描周期的时间和进行变量请求响应。这些仅仅是开始,想必还有更大的挑战在前面等着我。

                    

     

     当你弄清楚事物运动的本质,那根据此事物的任何问题都可以迎刃而解。所以理解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 V7.5亚洲版软件



    http://www.hyzdhxt.com