WINCC项目可以集成在STEP7中，以集成方式做，你用过吗？

1，有何优点及缺点？哪些优点使你选择集成，又有哪些缺点导致你放弃集成？
2，有没有一些应用技巧与大家共享？

欢迎大家热烈参与讨论！

一直在这么做，好处就是1.WINCC中不用在手动建任何变量，完全STEP 7导入。
2.变量全部为结构变量，有利于用自定义对象快速链接变量。
缺点：1.STEP 7中基本放弃了FC,全部改用FB，太占用内存空间，原来313能干的活现在要用315.
2.更改FB后，FB引脚名称没变，地址变动，要重新生成DB。不然只更新BLOCK，导入后WINCC地址不会变。
3.哪些变量要导入，哪些变量不要，项目初期要考虑周全。不然项目做的差不多了，再更改引脚属性，自己都不想再编译了。
4.编译经常出错。中间点取消，step7就会死掉。
呵呵，缺点好像比有点还多。不过确实节省了不少力气。
另外，采用STEP7中做报警的方式，报警消息怎么批量导入啊？？我导出的文本全是乱码。

一、关于将WinCC项目与STEP7项目集成方式，我一直都是这种方案的推崇和倡导者。其优点简要总结如下:
1、便于STEP7项目和WinCC项目的集成化管理，和项目文件的集中统一归档，和项目文件的的备份。

2、便于STEP7项目和WinCC项目的集成化仿真调试，缩短项目开发工程师的现场调试时间，减少项目组态程序调试出错机率。

3、WinCC项目中过程变量（Process Tag）由下位的STEP7项目程序灵活掌控，向上位的WinCC项目中自动传送，无需手动添加，还可避免手动添加变量易出错的机率。并且自动传送生成STEP7项目程序块的结构变量（Structrue Tag）。过程变量（Process Tag）名称很有规律，便于管理和维护。

4、WinCC项目中的报警归档（Alarm Logging）组态可由下位的STEP7项目程序灵活掌控，向上位的WinCC项目中自动传送。

5、WinCC项目中的过程变量归档（Tag Logging）组态，也可由下位的STEP7项目程序灵活掌控，向上位的WinCC项目中自动传送。

二、以上三大自动组态集成的优点，足可以使WinCC项目组态工程师们节省一半以上的项目组态时间，大大提高了WinCC项目组态的工作效率。
三、此外，STEP7项目集成方式的WinCC项目，也便于相互联网的多台WinCC工作站的项目文件维护和管理。例如:可以将安装有STEP7和WinCC软件的PC电脑作为工程师站（ES站），那么和STEP7集成的WinCC项目则就放置在ES站上集中统一组态修改。之后再将ES站上的WinCC项目依次分发下载至对应运行的WinCC工作站上，且对应激活运行的WinCC工作站还可不停机或不退出运行，就能实现后台项目文件和前台监控画面文件的修改。

我个人认为：用集成方式，肆无忌惮使用PLC内的资源，导致了PLC装载存储器爆满；同时也浪费了宝贵的WinCC外部变量点数；采用集成方式，貌似方便了些，可是为此付出了代价！另外,虽然用集成方式可以用STEP7导入变量到WinCC，可是在WinCC里面还是需要去手动连接变量到对象！万班也提到，分列式方式：用EXCEL建好变量导入到WinCC，我也觉得比较方便，而且灵活，比较节省资源！WinCC变量的命名和管理也很重要！呵呵......我个人觉得：根据使用者对两种方式的理解，都可以选择自己熟悉的方式！当然，还要看使用者是节约资源型人员还是大刀阔斧型人员哈！仁者见仁，智者见智吧！

1、看来支持将WinCC项目集成在STEP7项目中的人们不多呀！
2、让我猜测一下：一定是对PCS7系统比较熟悉，或做过PCS7项目的人，一定支持WinCC项目集成；反之对STEP7和WinCC系统比较熟悉的人，一定不支持将WinCC项目集成。对吧！
3、PCS7系统与STEP7+WinCC方式系统，在项目设计方式和思维理念上是不同的，如果按STEP7+WinCC方式理念去设计开发PCS7项目，是肯定很别扭而不成功的。
4、那么STEP7+WinCC方式的系统，真的就只能分离设计，而不能相互融合，让它产生1+1＞2的效果，从而演变成一个准PCS7系统？
5、关于这个疑问，我在多年以前就在思考分析，并在后续的项目开发设计中不断的尝试和创新，也有了一些经验总结。本人将在不久以后空闲的时间总结出来与大家分享吧！此间，也望大家踊跃分享自己在WinCC项目集成开发使用中的经验。

剑忠大侠说的很有道理。
做过PCS7的喜欢集成方式，很少用PCS7的不喜欢集成方式。
我分析有以下几点：
1.集成方式确实占用很多的系统资源；使得相对的造价提高；
2.前期使用集成方式确实带来很大的方便，但后期如果有修改，需要OS编译，需要下载，会浪费一些时间；
3.集成方式更多的需要采用结构化的编程，例如更多的使用FB块而非FC块；
不过集成方式的优点也是很多的：
1.大量的重复性工作可以降低；例如WINCC,STEP7不需要手动建立两套TAG。
2.项目标准化的东西可以不做；例如WINCC握手连接等；
3.可以使用REF参数化组态；例如OS建立；
4.ES工程师站可以得到充分发挥；例如下载方式；
5.结构化编程，WINCC可充分利用结构变量；
6.对于控制IO点数较多的项目，集成方式可以节省大量的组态时间；
7.不仅仅WINCC与STEP7可以集成，WINCC FLEXIBLE也可以与STEP7集成；
8.采用结构化编程，使用结构变量，利用FACEPLATE组件，可以连接结构标签，大大缩短了WINCC变量连接时间；
9.对于更改FB管脚的问题，可以在编写FB块得时候预留一些管脚，可以解决后期修改带来的不便。

喜欢用EXCEL做
一般最初的模板是用集成的，后面的改动都用EXCEL，每个项目我都建一个系统的EXCEL表，wincc报警，wincc变量记录，SCL的源程序，符号表等都用这个文件，查找修改维护都很方便。

刚好手头有个项目，前天刚做完下位，这两天在掂对上位。就尝试了一下集成，可我现在还是放弃了。
首先，我不熟悉PCS7，没有PCS7的项目经验。对剑忠大侠说的1和2，我无所谓，对WINCC程序的备份我宁愿用项目复制工具，不带数据库；分立方式也同样能够仿真。对3、4、5我没有发言权。
这次尝试集成我采用的万版提到的在WinCC中选择S7变量的方式，可是选择的时候打开过程很慢。选择之后自动建立的是结构变量，但是这些变量无法编辑：不能复制、不能剪切、不能修改。我不知道如果我不小心建错了的话怎么办。鼓捣了半天也没搞明白怎么编辑。所以我决定放弃了。匆忙之中完成的程序，在完善及调试过程中不大可能不修改。
尝试过程中还遇到一种情况：在下位编程中根据习惯使用的几个连续的位，但在上位中我需要通过一个整数变量来读取这些位从而达到画面上我要实现的一个效果。于是这个变量就不能从S7变量中选择了（否则需要修改下位的变量表了）。
另外：对于万版提到的无缝，我是有疑问的，如果达到这样的无缝，WinCC中是不是要浪费很多点数？否则怎么区分哪些变量是需要传送到上位的？
我想，对于大点数的系统来说，使用集成的方式或许是合适的。而且使用集成方式是一定要有经验、有时间，能够在项目初期就计划的非常周全。
对于中小项目，尤其是调试过程中可能有较多修改的项目，恐怕还是分立的方式比较方便，而且，中小项目往往还是要考虑成本的，不能有太多的资源耗费。
所以我还是觉得，分立方式更适合我。每个项目从初期开始就要建立EXCEL表格，从下位到上位，所以只要好好安排一下这个EXCEL表格，以这个表格为基础，建立下位变量、生成上位变量，还是比较方便的。不管怎么说，我还是坚信：适合的才是最好的。

eaglesky兄：
1.对于PCS7来说，可以说除了了WINCC静态画面需要在WINCC中组态，其他的都可以在下位进行组态；当然如果对于点数少的项目，这种方式的优势未必体现的出来；但对于点数多的项目，优势是非常凸显的。
2.那么对于AS-OS集成的方式，我想其核心的理念还是与PCS7一致的。只不过受成本限制，受资源限制等等，达不到PCS7那样的全部功能。但很多的方便条件也是很凸显的。剑忠大侠和我的帖子中已有相应的描述；
3.对于变量上传的功能，需要哪些变量上传，可以通过“打小旗”的功能实现。如果是全局DB，可通过DB里“打小旗”确定哪些变量上传，当然可以实现各种类型变量的上传；对于背景DB，可以通过对FB块的管脚同样通过“打小旗”的方式定义哪些变量需要上传；
4.对于OS下装的方式，我更加推荐这样使用，因为这样的操作更加人性化，更加方便，只要组态好下载路径，以后就无需修改，简单的几个操作就可实现客户机，服务器的项目下载；而且是可以“CHANGE DOWNLOAD”的。我想项目复制的方式，实现这个功能很困难的；而且这所有的工作都可以在ES中同时完成。而且REF的方式，更是简化了多个OS站的重复性修改和组态工作；
5.对于结构变量的使用，确实有些地方不够人性化；例如我定义了"单位"管脚，可以下位通过选择，或者输入的方式定义“单位”的工作，通过OS编译就可以实现WINCC中PO的单位，但如果修改了单位，那么还需要再次OS编译；因此对于这样的问题，我往往会把经常修改的局部变量还是通过WINCC中实现。这样就不需要重复性的OS编译。毕竟OS编译还是有些费时间的。

我也是在使用过PCS7开始使用这种集成方式的。不过虽然我使用过3次PCS7做项目，但一直还是用PLC的编程方式。所有的画面都是在WinCC里做，把PCS7那些自带的功能画面全部废弃了。项目小了还可以，大的项目确实太费时，可是由于自己本人水平有限还是不太会使用PCS7的编程方式，一直还是用PCS7的壳里面的东西还是PLC的方式。
另外一点个人觉得PCS7中自动生成的那些功能画面确实考虑挺周全，可是许多功能在实际的项目完成后使用人员从来都不使用。只好彻底的用PCS7的壳，编程方式还是老一套的PLC。
最近又接到一个从业以来最大的一个PCS7项目，想彻底的使用PCS7，可是自己感觉还是有点力不从心，不知道还是以以前的方式做，还是彻底使用PCS7的编程方式来做？？很纠结！！！！！！！！

用全集成方式，其中有几种不同概念
一：是WINCC项目集成到STEP7项目中，这点是非常好的。
二：前面说了很多靠编译自动生成变量，其实实现的方法不外乎对DB和M插小旗，对FB定义S7_M_C属性生成结构变量。从而节省了自己手动建立变量的工作。
三：在方法二的前提下，可以做标准化的子画面连接变量或结构变量。
四：使用报警功能块实现在STEP7下建立并编译自动生成报警。
五： 凌波微步 大侠说到可以实现归档自动上传，还请问您是用SFB做的还是只需要设置变量属性？
以上也会相应的带来相应的问题：
一：当碰到授权点数非常有限的情况，目前授权点数只能完成基本功能，而通常我们自己做的标准块和子画面会考虑功能齐全而需占用更多授权。
二：自动上传的变量都建立在通道根目录下，无法分组。会导致连接变量的时候比较麻烦（除非你在起名的时候有非常好的规划）
三：有改动需再次编译（当然也可手动建立），但尤其是涉及报警的时候，更是需要。

个人能想到的暂时是这些

1.呵呵，我好想在这个帖子中没有提到过“变量归档”自动上传的功能啊。
2.不过对于PCS7确实有此功能；个人觉得AS-OS集成方式也可以实现，不过我么可有实践过；
3.思路：对于要上传归档的管脚定义S7_ARCHIVE属性；
4.OS属性中勾选“CREAT/UPDATE ARCHIVE TAGS”;
5.在OS编译时，选择"CREAT/UPDATE ARCHIVE TAGS";
6.以上步骤可以尝试一下是否可以上传归档变量。
PCS7的原理是这样的。

关于集成的做法，只在自己全包全揽上下位的时候试过；WinCC的变量无需再建，出错率低，但是缺点也明显：1，STEP变量调整或者增添后需要重新编译；2，DB的变量无法多选，一次标签，只能一个个单独标签(插旗)。
分立的做法比较灵活，上下位是不同的人在做，而且现场变动比较大也没关系，缺点就是需要自己再建WinCC变量，而且有时会连错PLC地址:(
当前的项目就是分立做的，因为下位是别人写的，而且项目不成熟，现场改动比较大，使用集成的方式的话，总是疲于编译，再编译(因为项目管理或者实施的问题，亦或者编程人员考虑不周，接口定义不严谨)。
我个人的看法是：如果项目接口考虑比较周全，且事先定义的比较完整，又或者是上下位都是自己做，可以考虑使用集成；如果现场变化的可能大，又是上下位由不同的人做，分立或许会更加方便。

一、哦！好几天没来查看此贴了，一直在写项目总结。今天看到万斑主与凌侠关于WinCC与STEP7集成方式的探讨方案有分歧了。这主要是大家从不同的思维方式、不同的实现工具，去达成解决方案而出现的分歧。这也是难免的。
二、在此，我谈一下关于将WinCC集成于STEP7中的一些个人见解，欢迎指正：
1、既然是要将WinCC集成于STEP7项目中，那么在STEP7中能完成WinCC中组态的功能，就一定要交给STEP7中完成，否则，就不能充分发挥WinCC集成的优越性、一致性。所以，如果采用Excel、Access等工具的导入/导出功能去完成WinCC的组态功能，尽管方便灵活，但这毕竟不是WinCC在STEP7中集成化后完成的。属于单纯的WinCC组态编程技巧。
2、因此，在项目设计初期，就应在STEP7程序编程设计中事先规划和架构。项目总设计师必需要有统筹规划上下位组态程序的衔接，上下位接口的信息传递、上下位组态程序的资源消耗、上下位组态程序的人员安排和开发工期等经验能力。
3、如果要将WinCC组态工作分担在STEP7中集成化完成，那么就必然要借用PCS7的开发方式、系统架构、思维理念，才能充分发挥集成化的优势。
4、将WinCC组态工作分担在STEP7中集成化后，必然加剧STEP7项目中软硬件存储资源的消耗，但却带来程序简洁、增减（伸缩）灵活、组态高效、调试和维护方便等诸多优点。
5、熟悉或做过PCS7项目开发的工程师们应该知道CFC的很多功能块都有FACEPLATE。所以，在STEP7编程中功能块的设计和开发，是做好WinCC项目集成的关键所在。有了众多而完善的功能块，一致的功能块I/O接口，才能为上下位的信息传递架构好通道。
6、有很多工程师在将WinCC集成在STEP7中后，由于项目程序未统筹规划好，导致使用别扭，反而被束缚止步，甚至还后悔不已。
7、SIEMENS不愧是世界上最难以入门学习和复杂难用的产品。它的产品说明书尽管厚实详尽，但对初学者却反而不易掌握。SIEMENS的每一款自动化产品开发，几乎都考虑到市场应用的通用型，和用户使用的可开发性。
8、WinCC项目集成在STEP7中后，导致STEP7与WinCC相互关联、密不可分。同时也导致STEP7与WinCC相互牵连影响，加大了设计人员的使用掌握难度，是SIEMENS众多自动化产品开发中一个较为典型的复杂应用技术。也是长期从事SIEMENS自动化产品使用的工程师们议论的话题、一个较为难以跨越的技术难点。
9、目前，我正做完一个硬件为两套S7-400、I/O点数约1800个、软件为STEP7+WinCC和配CFC工具，并且将WinCC集成于STEP7方式中、工艺对象为干法水泥熟料线项目。不久以后，我会将此项目中WinCC集成化设计的经验总结出来，供大家分享。

1.WINCC以前的版本有CONFIGRATION TOOL和Variables Import/Export可以实现导入导出。
2。WINCC V7 SP2版本以后这两个软件不存在了。因此目前最新版本不可通过这种方法实现了。
3。使用系统功能块可实现报警自动上传：
SFB 36 "NOTIFY"
SFB 31 "NOTIFY_8P"
SFB 33 "ALARM"
SFB 34 "ALARM_8"
SFB 35 "ALARM_8P"
但这些功能块因使用的CPU类型有所限制；具体可以参看在线帮助；
Block type-----Required space (in bytes) in the working memory of the CPU
NOTIFY-----200 + 2 * Length of the associated values specified at SD_1,...SD_10 at the first call
NOTIFY_8P -----200 + 2 * Length of the associated values specified at SD_1,...SD_10 at the first call
ALARM-----200 + 2 * Length of the associated values specified at SD_1,...SD_10 at the first call
ALARM_8-----100
ALARM_8P-----200 + 2 * Length of the associated values specified at SD_1,...SD_10 at the first call
AR_SEND-----54

首先感谢凌波大侠及时回答我的问题，但是我还是要说你没看明白我的问题，我不是说wincc中导入报警消息，而是采用step7中做报警的方法，报警消息导入step7的DB块中的批量方法。另外给你更正个错误，WINCC 7.0sp2以后 CONFIGRATION TOOL和Variables Import/Export这两个工具是仍然有的。。而且挺好用，尤其是CONFIGRATION TOOL，在excel中做变量归档，报警消息非常之好用。只不过我想在step7中做报警罢了。

二：前面说了很多靠编译自动生成变量，其实实现的方法不外乎对DB和M插小旗，对FB定义S7_M_C属性生成结构变量。从而节省了自己手动建立变量的工作
---------------------------------------------
顺便请教一下，如果用多重背景数据块，如何实现？

关于采用STEP7中做报警，是WinCC集成于STEP7中后的强大功能，现我给大家列出一个示例，简要讲解实现方法供大家参考吧！
1、首先必需在STEP7中调用SFB36"NOTIFY"、SFB31"NOTIFY_8P"、SFB33"ALARM"、SFB34"ALARM_8"、SFB35"ALARM_8P"等报警系统功能块才能完成（见楼上凌侠提供的介绍资料）。但要提醒大家注意：这些个ALARM功能块由于要传递ALARM文本信息，所以每调用一个ALARM功能块要占用120Byte以上的存储空间。
2、以使用SFB33"ALARM"块为例，在FC块的Network程序行使用STL工具书写调用如下：

图中，SIG端口的变量地址DB200.DBX14.6（装钢区域急停），就是报警触发变量。
3、然后，在SFB33"ALARM"块的伴随数据块DB3300中右击，在弹出的浮动菜单中单击“Object Properties”项，则弹出如下图示对话框：

选择“Attributes”标签项，然后在“Attribute”中键入“S7_m_c”；在“Value”中键入“true”，“OK”对话框。
4、之后，又在伴随数据块DB3300中右击，在弹出的浮动菜单中单击“Special Object Properties”→“Operator Control and Monitoring”项，则弹出的对话框“General”项中先勾选“Operator Control and Monitoring”，后点击“Save”退出，
5、再在伴随数据块DB3300中右击，在弹出的浮动菜单中单击“Special Object Properties”→“Message”项，弹出如下最重要的报警对话框后，按图示填写组态报警文本，以及组态“Message class”选项为“Alarm－high”。
注释：“Alarm－high”和“Alarm－low”选项默认会在HMI上显示红色报警行；而“Warning－high”和“Warning－low”选项显示黄色报警行。因此，用户可按报警变量出现的轻重缓急组态选择。

6、最后，在WinCC集成组态配置好的OS(1)中编译（Compile）后，即可将报警变量地址DB200.DBX14.6、报警信息文本（Message Text）、报警信息类别（Message class）等，自动组态在WinCC的“Alarm Logging”中了。

7、试试看！打开WinCC的“Alarm Logging”中的组态变化吧！

那你使用SFB34"ALARM_8"或SFB35"ALARM_8P"功能块吧，一次可编程组态8个报警变量。见如下图示：

哦，刚才万斑主提到“alarm8p方式如果不能更好的接受批量的EXCEL信息，以及准确识别中文字符，那么竞争力恐怕比不过用configuration tool直接导入报警到WINCC”的问题，我的见解如下：
1、单独使用Alarm8和Alarm8p的方式的确既耗资源，又比不过Excel工具的批量化导入/导出功能强大。所以，项目设计开发人员一定要有使用经验，要会扬长避短，发挥Alarm8和Alarm8p的优势，避开它的使用劣势！！
2、那么Alarm8和Alarm8p的优势在哪里呢？在于将Alarm8和Alarm8p直接集成嵌入于控制对象功能块的开发中去，这样就可以先为这个功能块定义好报警文本的“域字符”，然后在程序调用每个带报警的功能块时只需正确填写好功能块的控制设备代码、名称和注释，就能实现调用功能块后伴随产生对应控制设备的报警文本了。
3、“域报警文本字符”其实就是报警文本的函数字符，其外观可见我在67楼那张图片中的“PV: $$BlockComment$$ HighHigh Alarm”、“PV: $$BlockComment$$ High Alarm”、“PV: $$BlockComment$$ Low Alarm”、“PV: $$BlockComment$$ LowLow Alarm”、“$$BlockComment$$ Channel Fault”这些字符。这是我自定义的PID功能块中，测量值PV高/低限、PV值超高/超低限，和偏差值ER高/低限报警，和测量值PV通道故障报警，全集成于这个PID功能块中了。如果是批量化使用PID功能，报警组态时间和效率绝不亚于Excel的导入/导出功能。
4、所以，其实我在54楼中提到了，如果是将WinCC集成于STEP7中，关键是要分析和研发控制功能块，要将控制功能块集成进WinCC的变量名称传递、报警传递、过程值归档传递（如果是PCS7系统，还可实现WinCC操作画面图标Block icon的传递）。
5、接下来不久，我会将干法水泥熟料线项目中的功能块开发总结与大家分享！

如何通过FC实现的结构变量呢？莫非是在WINCC自己创建的结构变量？
1.FC块没有S7_M_C的属性，不能通过上传的功能；
2.采用AS-OS集成的方式，使用FB块，可以通过设置FB的S7_M_C的属性，通过“打小旗”的方式，能够自动上传结构变量，而且通过结构变量可以通过FACEPLATE生成器或者FPT的方式实现窗口画面的方式，方便快捷，而且可以作为功能库保留，以后其他的项目也可以使用，一劳永逸。
3.其实我觉得FB,FC的功能，根据其命名就能很好的区分；
FB=功能块
FC=功能
区别是什么？FB是块，套用PCS7的PO概念，也就是过程对象；例如一个电机一个PO，一个类型；一个阀门一个PO，一个类型；
而FC是功能，即实现的一个子系统的功能，例如所有的电机一个FC，所有的阀门一个FC，所有的模拟量处理一个FC。。。

呵呵，有些跑题了~~~

1.结构变量不意味着所有的FB块中定义的变量都要上传的；
2.FB块中定义的变量需要上传的可以通过“S7_M_C”的方式实现；
3.使用FB块的这种方式与你在WINCC手动建的结构变量没有两样；
4.大量的DB不意味着浪费资源；也不意味着不好管理；
5.背景DB自动生成，不像全局DB需要手动输入；
6.使用背景DB就好比你在硬盘中分区，分区中分文件夹一样；
7.使用AS-OS的上传功能，也可以简化WINCC中的工作；节省了重复性的工作；
8.FB,FC的使用还是根据个人的喜好吧。没有对与错的概念；
9.PCS7也不意味着可以无顾虑的使用，还是要根据CPU的能力来定的；在某些情况下，我也会将一些占用大量储存空间的功能块舍去的；

我们做的项目一般都是300-500点的系统，CPU一般都是冗余。
我前几年做的都是选用的STEP7+WINCC。
一个项目前期准备得在家不停的做要一个多月，即使如此到了现场还得有不停的修改，现场变一个量程，我得修改STEP7里的量程，WINCC的趋势上下限，因为做的有显示文本告诉操作工量程范围，也得修改。PLC建变量，做程序，WINCC建变量，连画面，做报警，添趋势，加上有手误，建变量建错，连变量连错等。一般买1024授权，最终做完用到800-1024授权不等。这还是每个授权点都是单做。若是想做成标准化的块，授权就会超了。而且因为联的变量太多，每到有那个点不显示，总是自己先不放心，查一遍，是不是自己哪做错了。一套项目若是用了1000点授权，实际在使用中，不下3000次对变量建立和动态连结，想控制连错变量的风险是个问题。也带来在现场服务时间长问题。
不过在那个年代，因为也不知道有这些好方法，所以也不觉得有什么，认为理所当然的。
这两年年开始使用PCS7， 加上可以做自定义块和面板。那感觉真的不一样。
今年再做STEP7+WINCC项目，就觉得非常难受。（因为我们的授权是比较紧张，所以不敢把某些功能做成标准。）而我们的电脑旁边就是全厂的DCS，用的PCS7。而我做的WINCC借用了PCS7的画面导航，所以操作工老说，你们怎么不能设报警值啊，你们怎么不能点LOOP功能啊，你们怎么不能屏蔽报警啊.......
给领导抱怨时候，领导形容是“吃惯好面馍了，吃不了窝窝头了”：）

如果不担心授权问题，采用STEP7+WINCC方式，也完全可以很快和少出错。STEP7侧用ALARM-8，块也做成功能全的标准块，WNCC侧多建几个画面模板，模拟量显示不直接联变量，而是做一个画面窗口，某调用结构变量的子画面，（相当于BLOCK ICON）。等等方法和技巧，就有了用武之地

嗨，授权问题，我觉得才是STEP7+WINCC做项目规划的首要问题。

1、肯定用过。当然，是在STEP7中采用了CFC工具完成的。你可以看看我在前面讨论用过的图片中发现项目里有个“Charts”节点。
2、哦！我在此告诉大家一个技术细节：在STEP7中使用“插小旗”方式只能上传DB或M存储区中的BOOL、INT、DINT、REAL这些简单数据类型（Data Type），却不能传递Char、String、Array等这些复杂数据类型。而CFC工具却可以传递Char、String数据类型，但我没发现能传递Array数据类型，望大家给予补充和验证！
3、CFC将功能块中定义的“blocktype”、“comment”、“areaname”等字符串，和块上传变量定义的“unit”、“shortcut”等字符均上传至WinCC的“Internal tags”中，以Text reference类型自动生成，还不增加WinCC的外部I/O变量的数量，可真是一个强大的利器。

在以前的发帖中谈到我会将熟料干法水泥项目中，关于WinCC与STEP7集成方式做设计的经验与大家分享一事。经过这么多天的准备，现总结如下：
熟悉干法水泥生产的特点的人们都应该知道：干法水泥是围绕生料磨（立磨）、煤磨、水泥磨，和回转窑的工艺特点而设计布局生产设备的，因此简称“三磨一窑”的特点。其中回转窑是烧制熟料水泥的核心设备。
一．控制系统方案设计
1、选型特征
控制系统设计以回转窑的窑头和窑尾两端为界，布局两套S7-400系列PLC。考虑到性价比的因素，没有选用PCS7系统以及针对水泥行业的CEMAT软件，而采用STEP7 V5.4 SP5、WinCC V7.0 SP2英文版软件系统；主机架硬件也是选用CR3底板（6ES7 401-1DA01-0AA0）、PS407 4A（6ES7 407-0DA02-0AA0）、CPU414-2DP（6ES7 414-2XK05-0AB0）、CP443-1（6GK7 443-1EX20-0XE0）模块，CPU存储卡1Mbyte（6ES7 952-1KK00-0AA0）。
分布式I/O系列模块也采用ET200S架构IM151-1（6ES7 151-1AA04-0AB0）而非ET200M。5台操作员站和1台工程师站全部采用DELL 380系列台式PC，WindowsXP SP3英文版操作系统。
I/O数量设计约1800点，冗余约15%，实际约1300点。统计数据表如下:

正常生产时，工业以太网络（Industrial Ethernet）的通讯流量极大。为防止工业以太网络出现通讯瓶颈和干扰，所以窑头窑尾两套S7-400系列PLC与中控楼内的所有操作员（OS站）和工程师（ES站）分别采用光纤传输介质通讯。
由于BOSS未见过非PCS7系统里使用CFC工具，开始不赞成。但在与BOSS的软磨硬泡下，最终答应使用CFC工具，但却警告别把项目给弄砸了。
2、控制功能简介
窑头S7-400用于煤磨机、水泵站、空压机站及窑头部分设备的控制；而窑尾S7-400用于原料场、生料粉磨、均化库顶、均化库底、窑尾、窑中等部分设备的控制。
（一）窑头CPU414-2DP模块有两个ProfiBus DP通讯网络，其中X2端口（即DP）连接有煤磨区域DIO[3#]、煤磨区域AIO[4#]、窑头区域DIO[6#]、窑头区域AIO[7#]、窑头区域ADIO[8#]，共5个ProfiBus DP通讯站点；X1端口（即MPI/DP ）连接有喂煤皮带秤[9#]、窑头转子秤[10#]、窑尾转子秤[11#]、窑头蓖冷空气炮[12#]，共4个ProfiBus DP通讯站点。
（二）窑尾CPU414-2DP模块也有两个ProfiBus DP通讯网络，其中X2端口（即DP）连接有原料场区域ADIO[3#]、生料磨区域DIO[4#]、生料磨区域AIO[5#]、废气处理及均化库区域DIO[6#]、废气处理及均化库区域AIO[7#]、窑尾区域ADIO[8#]、窑尾区域AIO[9#]、窑尾区域DIO[10#]，以及窑尾空气炮[12#]和固体冲板流量计[30#]，共10个ProfiBus DP通讯站点；X1端口（即MPI/DP）则连接有立磨机锁封阀油站[4#]、立磨机磨辊加压油站[5#]，共2个ProfiBus DP通讯站点。
由于生料配料系统控制柜放置在生料库底，便于现场皮带秤的就地操作、调试和维护，但却造成与窑尾S7－400系列PLC的长距离通讯干扰。所以，生料配料系统配CP243-1以太网模块与窑尾CP443-1模块采用光纤介质、TCP/IP协议通讯。

二．CFC程序设计简介
尽管争取到能在项目中使用CFC工具，但我始终忐忑不安CPU上那块1Mbyte的存储卡是否够用。于是翻阅大量的干法水泥控制工艺技术资料，反复的分析、研究和比对程序设计方案和架构。
1、功能块简介
功能块的规划设计是做好STEP7与WinCC相互集成的关键环节。为了既方便设备控制驱动，又便于WinCC画面组态，使用SCL工具最终开发了如下功能块：

（1）S_MOTOR——不带报警电机单向驱动；
（2）S_DRV_A——带报警和电流测量保护和轴温保护的电机单向驱动；
（3）S_DRV_P——带报警和电流测量保护以及带跑偏限位开关的皮带运输和提升机单向驱动；
（4）PulseDRV——带报警和电流测量保护和轴温保护的软启动双向触发控制的电机单向驱动；
（5）S_VALVE——带报警和限位的单向气动阀驱动；
（6）D_VALVE——带报警和双向限位及互锁保护的电机双向驱动；
（7）VFDRV——带报警和电流测量保护和轴温保护的变频调速驱动；
（8）IN_D8——带模块故障诊断报警、通道信号仿真强制的8点数字量输入DI驱动；
（9）OUT_D8——带模块故障诊断报警、通道信号仿真强制的8点数字量输出DO驱动；
（10）IN_A4——带模块通道故障诊断报警、限幅、量程标度、信号方向组态、通道信号仿真强制的4点模拟量输入AI驱动；
（11）OUT_A2——带模块通道故障诊断报警、量程标度、通道故障时安全值替换模式选择、通道信号仿真强制的2点模拟量输出AO驱动；
（12）ALARM_A——带上/下限和超上/下限报警，和可选择过程值归档的模拟量输入功能块；
（13）MEASURE——不带报警和可选择过程值归档的模拟量输入功能块；
（14）OP_A_V——带阀位反馈的手动调节阀驱动功能块；
（15）OP_TRIG——带运行反馈的电磁阀和切断阀驱动功能块；
（16）PID_CTRL——带测量值PV、偏差值ER报警和限幅（HLM/LLM）、内/外设定值（LSP/RSP）切换、手/自动无扰切换（SP_TRK）、积分饱和限幅（Integral Action Hold）的PID功能块；
（17）HV_DRV——带报警和电流测量保护轴温、振动保护，油站系统保护，以及其它综合保护的10KV高压电机驱动；
（18）AIRPOWER——与空气炮通讯功能块；
（19）SYS_BELT和RW_BELT——与配料秤和配料控制系统通讯功能块；
（20）RAWM_DRV——与立磨机通讯驱动功能块；
（21）Pump_DRV——油站系统驱动功能块；
（22）ARC_CTRL——弧形阀时序逻辑控制功能块；







2、功能块I/O参数简介
由于自定义功能块众多，但很多I/O参数的功能和作用类同，所以I/O参数的命名是有讲究的。其命名原则是：功能和作用类同的I/O参数一定要同名（例如：R_L_SW、Run_FB、Fault_FB、Start_RPB、Stop_RPB、AUTO_SW、In_Lock、RST_PB、Q_RUN、Q_STOP、Q_STUTAS、Q_ALM等），以便于在WinCC中使用变量前缀（Tag prefix）和编写全局脚本（Global s cript），以及组态趋势曲线（Trend）等。
（一）常用Input参数
R_L_SW——操作模式选择。0＝就地；1＝远程（备妥）（Type：BOOL）；
Run_FB——被控设备运行（或应答信号）状态。0＝停止；1＝运行（或应答）（Type：BOOL）；
Ready_FB——被控设备准备好状态。0＝未准备好；1＝准备好（Type：BOOL）；
Fault_FB——被控设备故障状态。0＝正常；1＝故障（Type：BOOL）；
TEMP_ALM——被控设备轴温测量超限报警。0＝正常；1＝超限（Type：BOOL）；
Start_RPB——被控设备HMI启动按钮（Type：BOOL）；
Start_LPB——被控设备就地启动按钮（Type：BOOL）；
Stop_RPB——被控设备HMI停止按钮（Type：BOOL）；
Stop_LPB——被控设备就地停止按钮（Type：BOOL）；
Start_A——被控设备自动启/停命令。该参数使能受AUTO_SW参数切换控制（Type：BOOL）；
AUTO_SW——被控设备“手动/自动”启动切换命令。常用于与外部设备间互锁切换操作（Type：BOOL）；
POS_RPB——被控设备HMI正启动按钮（Type：BOOL）；
NEG_RPB——被控设备HMI反启动按钮（Type：BOOL）；
POS_FB——被控设备正运行（或正应答信号）状态（Type：BOOL）；
NEG_FB——被控设备反运行（或反应答信号）状态（Type：BOOL）；
POS_LIMT——被控设备正限位状态（Type：BOOL）；
NEG _LIMT——被控设备反限位状态（Type：BOOL）；
RST_PB——被控设备故障后HMI上复位命令（Type：BOOL）；
In_Lock——被控设备是否启用电流、轴温等测量值超限的联锁。0＝解锁；1＝联锁（Type：BOOL）；
Current——被控设备电流测量值。（Type：REAL）；
OP_U——被控设备HMI阀位给定或变频速度给定值。（Type：REAL）；
FB_U——被控设备HMI阀位反馈或变频速度反馈值。（Type：REAL）；
DT_T——设备在HMI上启动后应答信号（即Run_FB）、模式切换信号（即R_L_SW）丢失监测时间值设定，以及故障信号（即Fault_FB）、准备好信号即Ready_FB）；另外，DT_T参数也用于软启动的倒计时设定值。（Type：INT）；
U_AH/U_WH/U_WL/U_AL/HYS——这5个参数用于带电流测量值的被控设备电流测量值上/下限，或超下限设定值。（Type：REAL）；
（二）常用Output参数
Q_RUN——被控设备启/停外部驱动。1＝启；0＝停（Type：BOOL）；
Q_STOP——用于触发型被控设备的停止命令触发。1＝触发停；0＝触发启（Type：BOOL）；
Q_STUTAS——被控设备启/停状态。1＝已启；0＝已停（Type：BOOL）；
Q_ALM——被控设备有报警。在HMI上操作复位时，如果故障信号解除，则该参数复位（Type：BOOL）；
四．自定义功能块使用统计
以下是我统计的本项目中以上自定义功能块的使用计数排序表如下：看看就知道功能块的集成开发使用的重要性和高效性。

五．窑头窑尾存储容量统计


通过以上图片所示，使用CFC工具后，窑头窑尾CPU的存储容量使用的确很大，1Mbyte的存储卡均已达到约80%，但毕竟还是给做成功了。忐忑不安的担心也终于稳定，算是给我一个惊喜的奇迹呀！
六．WinCC组态画面设计
由于在STEP7的功能块中已集成了变量上传（Process Tag）、变量归档（Tag Logging）、报警组态和归档（Alarm Logging），以及变量单位（unit）和变量注释（shortcut）的生成，所以在WinCC中就只需对画面布局（Layout）、块图标（BlockIcon），和块操作面板（Faceplate）进行设计了。
经过统计，在WinCC中上传的过程变量（Process Tag）约4170个；过程对象（Process objects）约172个；变量归档（Tag Logging）约325/512个；报警归档（Number of Messages）约1932个。
可惜的是STEP7+WinCC毕竟不是PCS7，块图标（BlockIcon）变量既不能在CFC中编译指定后自动连接，且还需在WinCC中逐一制作设计。而被控对象外观结构的不同，以及功能的多样性，导致我用了很多时间做了不少于30个设备块图标（BlockIcon）模板、和20多个设备操作面板，再使用变量前缀（Tag prefix）连接法完成。
还好，WinCC V70版本以后，增强了的界面渐变功能，使得界面就比以前版本更美观丰富，画面颜色和风格也更多姿多样了。关于我在该项目设备操作面板的一些外观组态，可在本论坛以下链接地址中分享：
http://www.ad.siemens.com.cn/club/bbs/post_elite.asp?_id=5&a_id=843760

仔细拜读了您的文档，
能否帮我指点一下几个小细节
1：我看您说“过程对象（Process objects）约172个；”：过程变量是指相当于DB块插小旗后编译上去的以结构形式生成的变量吗？因为只在PCS7中有类似的名词概念，没有单独在STEP7中做CFC，CFC是否有此授权限制？
2：我看您做了IN_D8，OUT_D8，IN_A4都是做了带模块故障诊断报警，输入参数中有子站号槽位号等，请问是用SFC读诊断吗？还是有什么更好的方法。
而且我看您还做了PID_CTRL，太厉害了。
3：用CFC可以完成“变量单位（unit）和变量注释（shortcut）的生成”，是否利用他们的前缀功能，也可把他们用于块图标和面板。
若是这样的话，真的可以推翻我以前的很多做法。

我从德国网站的文档
《用于 STEP 7 和 WinCC 的实例块》
看到有一些现成的块可以下载。

剑忠大侠的这些块中有没有从这里获得呢？
或者直接取自PCS7的库？

1、过程对象（Process objects）是我用PCS7版本打开本项目时，观察到的对象数量约172个。记得从WinCC V6.2版本以上后，就增加了一种“WinCC RC POxyz”授权。这是专为使用PCS7系统时，为简化WinCC的外部I/O授权数量计算方法，而将在AS侧使用的功能块与在OS侧上对应使用的操作面板（Faceplate）数量进行计算。一个操作面板（Faceplate）就是一个过程对象PO，也就占用一个PO计数，每个过程对象PO可以支持40个左右I/O变量。
由于我这是个STEP7+WinCC的项目，所以还是以WinCC使用的I/O变量规模计数，也就是过程变量（Process Tag）约4170个。在此给你们带来的概念混淆表示歉意！
2、“IN_D8，OUT_D8，IN_A4”这些是我专为使用CFC工具时开发的I/O驱动功能块，但不适用于无CFC工具的组态编程，具有模块故障诊断报警、限幅、量程标度、信号方向组态、通道信号强制等功能。该系列功能块核心就是使用了系统功能SFC5（GADR_LGC）。
3、用CFC可以完成变量单位（unit）和变量注释（shortcut）的生成，当然可以利用它们的变量前缀（Tag prefix）连接法功能。在给你的回复中（95楼 ）已有图片显示，CFC将块中的变量定义的“unit”、“shortcut”等字符上传至WinCC的“Internal tags”中，以Text reference类型自动生成，还不增加WinCC的外部I/O变量的数量。

1.AS-OS与PCS7的框架的区别我是明白的。AS-OS没有多项目的概念。PCS7具有多项目概念。
2.剑忠大侠的这个做法其实有些偷梁换柱的感觉了（其实我也这么做~~哈哈）。
3.我曾经犯过一次错误，跟大家分享，希望给大家提个醒：
3.1曾经AS-OS（WINCC FLEXIBLE）方式做过一个项目，当然是在PCS7软件的STEP7模式下；
3.2由于项目是3套一样的，所以利用了多项目的理念，建立3个项目；
3.3结果打开WINCC FLEXIBLE后，一直同步，无法正常运行；
3.4过了一段时间，我才恍悟，STEP7是不具备多项目的架构的；
3.5处理成1个项目后，出现的问题得到了解决！
3.6提醒大家如果使用PCS7软件的STEP7模式，还是要注意两者的本质区别。