西门子EMQT16模块资料

西门子EMQT16模块资料

     节前，S7-200 SMART发布了V2.5版本，补齐了所有的大家希望应该有的通信功能，PNIO，S7，OUC，Modbus-TCP，DP-SLAVE，Modbus-RTU，USS，其中支持PNIO协议的IO设备功能是这次V2.5发布的重点。本来这是预料之中的事情，另外我的观点是SMART的IO设备功能并不能起决定性的优势作用，整体而言，SMART的通信功能已经是同级别PLC里很强悍的存在了，多一种选择而已，有总比没有强。因为疫情的关系，整个假期闲暇无事，就上网学习了《揭秘——S7-200 SMART V2.5 新功能》这一课，也做了一些测试，发现课程中的例子其实还是有些问题的。

       课程中讲了一个如何控制115台S7-200 SMART的例程，该应用的行业和场景语焉不详，但给了个图说明了用户的原先的方案与采用PNIO协议 IO设备的方案对比：

       课程中推荐S7-200 SMART作为IO设备通信的较大理由是，S7-1500单CPU带IO设备的数量即达到128个，较终解决方案比原先解决方案只需要一个S7-1500 CPU即可。最后课程里也没有说明，用户是否真的实施了该方案，真实的效果如何？

       我之前做过不少类似的项目，包括S7-1500采集上百个S7-200 SMART数据的案例，以我的经验，客户还是会坚持原先的方案。原因有以下几点：

一，PNIO的传输数据不算多，128字节，传浮点数就32个，S7通信至少可以传50多个浮点数；如果数据是整体传送，还要带时钟标签的话，有效数据传送量偏少；

二，S7通信只需要单边组态，单边编程，通信只关联IP地址；PNIO通信需要双向组态，双向编程，通信关联设备名与IP地址；

三，S7-200 SMART的IP地址是可以通过在线修改或程序修改的，但设备名只能是在线修改；我猜想用户的115套PLC的程序是一摸一样的，但如果SMART的IP地址是固定设置的话，那就变成了115套不同的程序；如果选择从其他途径获取IP地址，则至少也要MICROWIN编程软件联机115次修改IO设备名；这对安装调试及维护都是不利的。而S7通信方案，对于SMART只要一个程序就可以了，可以通过SD卡统一复制程序，通过人机界面或其他APP终端工具修改IP地址，*使用编程软件。

四，类似项目的通信拓扑结构，基本上就是星型或树型结构，布线距离不是很确定，较端的个别站会达到100米多的距离，另外交换机也大多采用低端的普通多口商用交换机，交换机是否支持PNIO协议不确定，PNIO通信对通信质量的要求较高，这种情况下能否保证通信质量就很难说了，而S7通信在这种条件及这个距离上大多数都是可以稳定通信的。

五，这种系统，有必要需要达到10毫秒级别的，这么快的数据采集吗？

       所以，SMART作为PNIO协议IO设备的方案，一定是较佳解决方案吗？还真不一定。

       我的解决方案是用 CPU1512SP-1+CP1542SP-1 共二套，数据量少走S7协议，数据量大走OUC，上位机与底层设备网段隔离，S7-1500一套程序，S7-200 SMART一套程序，较大限度地降低项目实施的工作量与难度。

        以下是我对于SMART基于TCP通信的一些对比：

本篇讲一下在S7-1200/WINCC做报警的具体实现方法。 

在进入主题之前，先吐槽一下AB。

我本来认知上既然所有PLC都是计算机， 那不仅西门子PLC，其它品牌的PLC也都可以实现。 而且，业界一直传闻的是，AB的PLC性能特别强大，编程环境特别自由，比西门子好用多了。

 我自己多年前使用的感受，也想当然地以为1769比S7-300更接近计算机，各种与计算机相关的需求自然不在话下。

但这次组织在AB系统下做标准化项目，令我大失所望。 而主要承担开发工作的同事，曾经多次跟我进言AB PLC多好用，用起来多舒服的，这次也吃尽苦头。连续撞墙掉坑之后，跟我感慨，认识到西门子反而比AB PLC自由多了。 

做报警功能，在PLC编程中嵌入字符串功能，把报警信息文本做出来，我们目前在AB的系统中还没找到实现方法。希望有AB高手能实现的话，不吝赐教。

西门子EMQT16模块资料

在S7-1200和WINCC中，具体实现的思路其实很简单。

首先在PLC中建立FB块ALARMB

接口如下：

各管脚的定义：

ENA, 触发位，需要一个上升沿。

INFO1,INFO2, INFO3,为3个字符串，用于绑定需要的文本，通常只用1个。

（我前面吐槽AB的就是竟然INPUT管脚都不能支持字符串类型 ，不能直接赋值字符型常量值到管脚上，希望有AB高手能指导我们一下）

SEP为链接字符串的分隔符

PV为嵌入过程值

输出值

Writing：WINCC报警触发信号。

MSG：WINCC报警信息文本。

其它为程序逻辑需要的辅助变量。 其中有一个BUFF的数组，我这里设置了上限80。具体结合CPU的性能和系统的规模，可以修改。 

程序的逻辑很简单:

当ENA到来时，整理组织报警字符串，并送到BUFF的空闲位置中。如果不为空，则提升一个位置，直到80个都满，则溢出报警。 （说明此程序崩溃，有系统报警丢失）

而在BUFF中有数据的情况下， 则不断执行FIFO, 把报警信息送到MSG，并触发报警信息位Writing。

WINCC中收到报警信息后，则PLC程序取消 发送，过一个延时，再次发送下一条。 

取决于WINCC报警系统和PLC的通讯能力，过去是所有报警信息是并发的，而现在是串行发送，性能当然降低不少。 所以需要延时。 触发时需要延时，以保证WINCC能收到报警。 而取消触发时也同样需要延时，需要一定长的时间，以确保WINCC收到报警离去，下一次再来时才会接收新的报警。 

BUFF的功能实现了在同一时刻有多条报警信息触发的情况下， 报警信息不会丢失，但因为有延时， 会导致后发送的报警条目的时间和WINCC报警系统中记录的时间不一致。 所以程序中在报警信息文本中备注了误差时间。

其实我更期待有更好的办法，写入到WINCC的报警时间，也能从PLC中获得，就OK了。 这需要再研究。

然后在主控制程序，或者需要触发报警信息的位置，均插入一条对ALRMB的调用，这里示例了2个：

注意，FB虽然是多次调用，但使用的背景数据块只有1个，等于是这个实例被重复调用罢了。 

WINCC的项目中， 则非常简单， 只需要建立一条报警条目，触发信息即为ALMB_DB.Writing， 报警信息的内容为嵌入一个字符串型的变量，ALMB_DB.MSG。

根据项目规模的大小， 如果一个报警通道的BUFF会拥堵，则可以再开辟一个通道， 即ALMB多调用一次，WINCC中也再增加一条报警。但无论如何，比需要多少个报警，就在WINCC中建立多少个条目， 要方便多了。 PLC编程思路也不容易被打断。 产生了什么报警，直接把描述信息记录在当场即可。 

对于WINCC来说，一直有一个问题， 即嵌入报警的变量和触发变量同时赋值的话，在产生的报警信息中，嵌入变量值不够新，还是旧的值。 这个问题官方有一篇技术文档提出了解决方法， 也是本文描述的方法可以成功实现的一个重要基础。 

西门子中国与西门子医疗中国今天宣布将进一步为中国抗击新型冠状病毒疫情提供支持。公司各业务集团众志成城，将共同捐赠价值为1500万元人民币的西门子医疗设备帮助中国抗击疫情，并鼓励员工开展自愿捐款，参与公司的积极行动。

本次捐赠的设备将主要包括当地急需的CT、移动DR等在内的西门子医疗设备。这些设备对武汉当地医院进行新型冠状病毒肺炎的诊断和筛查至关重要。此次疫情爆发后，西门子医疗于1月21日凌晨**时间响应，向武汉当地医院提供用于重症监护的超声设备，并在10个小时内**速完成启动调货任务。与此同时，西门子医疗德国总部集结**资源，调用较优化的洲际货运航班，**全力**中国的移动DR设备需求。西门子工程师在武汉宣布“封城”之际仍深入疫情**，以确保设备的安全抵达和及时装配。此外，西门子先进的配电设备正在为建设中的武汉*二座应急医院——雷神山医院的电力运行提供支持。

“在这样一个关键时刻，西门子坚定支持为抗击疫情所做的所有努力。这场战斗不仅仅是中国之战，也关乎整个国际社会。”西门子大*区总裁兼**执行官赫尔曼（Lothar Herrmann）表示，“西门子已做好准备，提供进一步的必要支持，决胜疫情。”