0610 【万泉河】S7-1200 PLC中实现WINCC报警

总有人问起， S7-1200和S7-1500在功能上有什么区别？

也总有来咨询标准化程序学习的朋友来问， 标准化烟台方法的程序通用于S7-1500和S7-1200吗？

我总是简单回答：嗯， 通用。

而其实这个通用，只是99%的通用。 其实还剩下1%。

而这1%，是S7-1500独有的性能，除了S7-1500以及旧一些的S7-400/300， 其它的PLC型号， 不管是西门子的S7-1200, SMART 200 ，以及其它所有品牌，AB, SCHNEIDER, OMRON, MITSUBISH, BECKHOFF, B&R等等外国品牌，以及未列出的国产品牌，一概没有。

（嗯， 我又成功给自己挖了个坑，欢迎有熟悉这些品牌的同行， 发现其具有相同的功能的话， 勇敢地来打我脸）

这个功能就是PLC中触发WINCC报警，即S7-1500中的PROGRAMM ALARM功能。

这部分功能在以前发表的文章《【万泉河】报警也是分层的》 中有过描述， 在专著《PLC标准化编程原理与方法》中也有提及。

https://mp.weixin.qq.com/s/7E22wI84bSXLBMJ4fcEBxg

标准化编程的核心要义是模块化， 而模块化的核心是要方便移植，不仅仅在同品牌的不同项目中移植， 最好还能方便跨品牌的移植。 所以通常来说，我们做程序模块的时候会尽量避免使用一些特殊指令，以防止程序需要移植的时候相关功能不兼容。

所以，如果基于上述的原则， PROGRAM ALARM是不应该在程序中使用的。

这个功能对传统的编程方法来说无所谓，有没有都可，即便有这个功能也很少有人用到。 然而，对标准化烟台方法的架构来说，则实在是太诱人了！其诱惑力足以抵消我们对上述原则的坚持。 或者，即便我们未来有移植的需求，我们也情愿这部分的功能发生改变，而另外再单独增加工作量实现。

想想啊， 原本能占据一个项目设计工作量一半以上的工作内容， 可以瞬间减小到0，那相当于工作效率提升无穷大， 而对整个项目，也直接相当于效率X2。

这种诱惑， 相信对任何追求设计工作高效率的同行来说，都无法抵抗。

所以， 换一个说法， 我们在S7-1500项目中使用PROGRAMM ALARM 功能，其实是在等待其它的品牌和型号成长起来，启动未来他们也具有同样的功能。这是我如此期待被打脸的原因。 打脸对我来说意味着喜讯。

而在这些品牌具备可替代功能之前， 尤其S7-1200注定不会提供此功能的话， 就一直想有机会自己做程序功能来实现。

而其实要实现这样的功能， 基础的要求并不高。

1，  PLC支持字符串数据类型；

2，  上位机报警文本信息支持嵌入PLC变量，并且变量类型支持字符串类型。

对于S7-1200的PLC，第一条要求可以满足，而对于WINCC，第二条要求也可以满足。

当下其它品牌型号的PLC，大部分也能支持条件1了。 而WINCC之外的其他上位机软件以及触摸屏，是否能满足第二条则具体看所使用的软件设备功能。

由此可以实现：在程序运行到相应的状态，需要触发报警时，则调用FB功能块，激活报警的同时，将文本内容赋值到变量值。如S7-1500的PROGRAMM ALARM 函数， 或者S7-300的ALARM_S一样。

即， 不同的报警信息， 其实是通过公用的报警条目，报送到上位机， 然而因为变量内容变化， 因而实现了报警信息的不同。

然而这其中就存在了一些问题

1，  由于共用通道，就必须考虑如果多个报警同时发生的情况下的调度问题， 如何避免同时多发的报警导致信息拥堵，错乱， 以及丢失。

2，  必须确保报警触发信号到达之前， 变量信息已经先期在上位机变量刷新更新，以确保信息正确。

我在去年曾经尝试过使用1个公用通道实现报警传送的实现，然而调试过程中非常闹心。 因为首先要考虑到信息并发情况下导致的拥堵和排队，而排队等候之后上位收到的时间戳就延后了，就不能准确记录和展示信息发生的时刻了。

有考虑过在信息中再备注时间偏移值，然而想想也太恶心了， 跟客户根本无法交代。 所以调试完成即束之高阁，并没有投到实际应用。

最近接了个WINCC做批次报表的活，以往这种需求都是用用户归档来做，然而这次的用户软件已经购买，设备已经在现场运行，不想再增加选件费用及安装软件。所以决定用WINCC报警来实现。 后来在实施过程中逐渐发现， 也要用到共用通道， 也同样需要面对多并发的情况。 所以就想到了这其实和PLC系统报警是同一个问题。 尽管那是S7-1500，但实现之后可以用于S7-1200实现下位产生报警。

为了避免拥堵和丢信息，决定使用多个报警信息7001-7020, 然而这些报警信息的内容格式都是相似的，所以可以用EXCEL复制生成。所以其实即便通道数量不够， 要再增加通道，也很简单。

而在PLC程序中，则通过循环判断，选择空闲的通道发送变量数据以及触发其报警记录，即报警通道和报警编号并不是固定不变的。是根据运行中的情况自动调度实现的。

当然， 如果未发生信息并发的情况，所有通道都空闲可用，那就全部信息只使用7001报警，而如果出现并发，则会逐渐增加通道7002，7003.....直到所有通道都用光。

这需要在调试时测试发现， 并在发现有存在超载的情况后随时扩展更多的报警通道。

所以，开辟的通道的数量其实与设计的PLC系统的特性相关。 比如同时产生报警的可能性，比如通讯质量， 上位机的处理速度，数据内容文本的长度等等， 都会是影响因素。

我们当然可以开辟足够多的通道以避免冲突，然而，如果系统的负载情况并没那么严重，却开了过多的通道冗余， 对系统反而造成了累赘，也是比较尴尬的。

所以，虽然上述的理论并不算很复杂， 我也已经在实际的批次报表中完成了应用实现， 然而并不能做到完全的封装固化作为标准模块使用，仍然需要根据项目应用随时调整修改参数到适应应用。

所以， 如果读者对这里描述的功能感兴趣，也可以自己尝试实现。 甚至包括其他品牌的PLC，以及对应的HMI和上位机系统。 理论上都是通用的。

也是未来实现标准化应用的一部分。