热门搜索:

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

    西门子WINCC V7.4软件

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

    西门子WINCC V7.4软件

    当我逐步掌握这些通信的原理和背景知识,就可以游刃有余的解决来自客户的问题和处理各种相关的案例。只能说“天空飘了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的循环周期相关呢?后者说限制负荷高峰这是一的方法吗?


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

                    西门子WINCC V7.4软件

     

        上述的测试中,对于300PLC无论在禁用还是使能“By PLC” 的情况下,发送数据给WinCC都是通过CCP进行的。因而这样通信的效率确实比较低,因为数据的发送周期取决于CPU的循环周期,特别当CPU的周期时间过长的情况下。不过随着CPU版本的升级,300PLC可以通过时间片的方式与WinCC进行通信,这也说明版本的升级不仅仅修改了一些Bug,也在实际上做了硬件性能的提升。在CPU版本V3.2版本之前,300PLC只能通过CCP的方式与WinCC进行数据交换,无论是否使用 “By PLC” 。而V3.2版本之后,CPU支持OCM功能,在CPU属性中可以激活,这表示CPU可以使用时间片来替代CCP做的通信。

     

     

     

                                

     

                     

     

                      

     

         这样激活OCM功能后,再做测试看看通信的行为如何?还是根据前面的一些测试条件,发现当激活“By PLC”时,数据的推送仍然发生在CCP,数据通信行为不变,这表示仍然数据的推送周期取决于CPU的循环周期。当取消“By PLC”,那么当WinCC画面上同时存在多个刷新周期变量时,变量读任务响应周期等于画面变量的刷新周期,因为此时数据的响应在CPU中发生在时间片。所以总结来说这进一步说明在300CPU与WinCC通信时,不建议使能 “By PLC”。

     

         那么对于400PLC与WinCC的通信行为又是如何呢?前面文章中其实表明与300PLC不同的是400PLC通信多数发生在时间片。使用同样的测试条件和方法进行400PLC的测试,当禁用“By PLC”时,由于400PLC与WinCC的数据交换发生在时间片,那么数据通信行为与300PLC的OCM方式一样。激活“By PLC”,S7-400PLC会给每一个WinCC分配6个循环读服务,共16个,PLC会根据WinCC画面的变量刷新周期进行推送,这种方式与300PLC不同,发生在时间片。而当在WinCC画面上设置变量的刷新方式为“upon change”,如果PLC的数据在不断的变化,由PLC自行决定推送周期,该周期由PLC自行计算,无法得出准确公式。但肯定一点就是不是数据一变,PLC就推送该数据。

     

         激活“By PLC”&“Change Driven transfer”时,当WinCC画面上同时存在多个刷新周期变量时,根据变量的刷新时间判断变量变化,CPU才会推送这些变量数据给WinCC。也就是说判断变量是否变化,取决于画面变量的刷新周期,CPU会根据此时间内判断数据是否发生变化,变化则发送数据至WinCC。然而经过测试发现一个很有趣的过程就是数据变化才进行推送,仅对DB数据有效。即当画面上的变量为DB区时,根据变量周期发现此数据发生变化,则会推送变化数据给WinCC。

                            

     

         如果画面存在其它地址区域。例如M区数据,无论数据变化与否,CPU都会按照画面上变量的刷新周期进行推送。即即使根据变量周期发现此数据没有发生变化,也会推送这些数据给WinCC。这样的使用 ,设置“Change Driven transfer” 并没有起到真正的作用。

                          

     

         所以在这种情况下的通信优化方式,即使用DB区,甚至按照前面的结论好是连续的DB区。一方面可以减少推送的报文数量,大程度的装载有效数据,另一方面可以按照“Change Driven transfer”,真正是变化的数据才会被推送,减少网络负荷。


         以上就是S7-300/400PLC与WinCC画面变量通信的通信行为。整个测试过程,看似结论很多,但其实很简单,关键在于使用以前的通信概念进行分析和总结,多做,多看,多分析,多总结,很快会发现问题的所在,发现通信的行为以及背后的概念和原理。

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

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

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

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

     

     

     

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

     

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

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

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

     

     

     

    西门子WINCC V7.4软件


    http://www.hyzdhxt.com