0524 【万泉河】不一样的触摸屏报警方法

0524 【万泉河】不一样的触摸屏报警方法

当然，也不仅仅触摸屏了， 上位机也是。 不过我们本文就以触摸屏为代表了。来讲述这个问题。

先复习一下传统的触摸屏报警的做法。

我们传统的触摸屏报警的做法是，在PLC程序写完之后，会整理出来一个完整的报警点表，第一列是PLC中的点位地址，第二列是报警文本，然后还会有报警类型，报警级别等其它的列。

然后不管是自己做触摸屏，还是多人分工，有人专门做触摸屏程序，就是拿到了这个点表之后，逐条录入或者再人工整理下点表的格式适应触摸屏软件的格式规范，然后批量导入到触摸屏中。

这应该是传统以来PLC行业做报警记录的做法。

这种做法的缺点是：
1， 工作量比较大。
报警点表里面的信息其实都是人工逐条整理的。 前者，点位地址，需要对着PLC程序逐个录入，后者，报警文本其实都是PLC工程师逐条录入的。
通常的共识，一套设计优秀的系统，必定要有完整的报警记录以便于故障追溯。所以经常会有一套PLC程序本身很简单，但要把报警信息做细做全了，工作量反而比逻辑的处理更大。
所以，我们可以评估认为，一套控制系统中，做报警信息的工作量完全有可能要占到整个PLC程序工作量的一半。只算PLC程序，不包括触摸屏画面。
而且，这个工作通常还需要逐渐丰富的。 比如我们一套行业设备，开始的时候能够成功运行完成工艺要求，报警部分也就简单提示各种运行故障和运行信息。 然而当设备要逐渐成熟的时候，就会更细致的报警信息。 比如运行中某个行程开关的接线松了，或者继电器的触点坏了，都能判断得到，都能通过文本报警方式提供给操作人员，那么就可以在生产操作中快速定位故障点，快速故障修复，提高效率，减少停机损失。
然后，客户就会更接受这样的设备，是一台对用户高度友好的设备。而不是故障停机以后维修人员对着程序和图纸，扒拉电线调试三天三夜，最终才定位到某个不起眼的元件故障导致。
（多说一点，如果PLC行业的设备都能达到足够的用户友好，都能有丰富的自诊断功能，那么这个行业的客户也不会都要盯着要源程序，以及禁止PLC程序加密了。如果不是设备复杂，如果平常一个不懂程序的操作人员参照设备的提示就能修复设备故障，所有的生产工厂老板才不愿意花高价格养一批能搞程序的维护工程师呢！）
2， 比较难改动。
比如一套设备，经过上述的步骤一点点精心调教，终于功能比较完整了。然后换一个客户，再供一套新设备，稍微有一些改动。
比如配置接口变了，增加或减少了几个控制元件和设备，或者系统工艺升级了，原本的变频器改为了伺服，或者原本的限位开关改为了模拟量。
总之，设备整体95%与原来的相同，但好死不死总有那么5%与以前不一样。当然这也就是非标设备的特点。 如果完全一样，工程师还没活干了呢！图纸直接打印下发到车间，工厂就持续生产就行了。 工程师顶多起个保驾护航的作用。
那么摆在设计者面前就是个两难的选择。
如果完全从头做，这种天量的文字处理数据处理的工作量，想想都头疼。 而且分明是已经干过了一次了， 还这样重复劳动， 那会更头疼。
而如果沿用原来的设计，在其基础上增删改查，那头疼程度一点都不少。需要把旧系统中作废的一一挑出来，新增加的内容再逐条加进去。所使用的变量点位还有可能有重叠。而如果稍不留心，漏加了一条或者漏减了一条， 也非常难发现。要想发现，除非等设备到了现场，运行了五六年了，用户在使用中发现某条诊断功能缺失，或者多出来一条看不懂的诊断提示，再把工程师喊去现场售后服务，才有可能发现。    
3， 难以传承
看出来了，如上位所述的设计结构，除了设计者本人，后人是完全没办法接手的。 前人做到了多少功能，而多少功能没做到，做漏了，完全心里没数， 那么给到我手里让我再增加的功能，我也难保完全做到位。而且，即便做的不完整的地方，也无法审查。 设备生产功能正常，完成验收，调试工程师就撤了，项目奖金也早拿到手了。  等发现问题，都找不到责任人了， 甚至，调试的工程师早离职跳槽都不知道多少次了。 完全一笔糊涂账了。

那么有没有更好的解决办法呢？

当然有，而且早就有了。

S7-300/400和PCS7的时候就有，就先不提了。

在TIA PORTAL中，S7-1500中有program alarm功能，可以实现在PLC中组态设置报警，报警信息直接发送给触摸屏和WINCC。 即，上位机是不需要做任何设计工作的，直接可以收到PLC送来的完整的信息数据。包含时间戳和信息文本，信息类型等。

而在PLC程序中，也可以做到报警信息处理跟随程序逻辑。比如设备发生故障，在逻辑中读取这条故障信息之后，紧跟着来一个报警上传指令，把这条故障的完整描述报给上位机。 等于是，把原本写在注释中的文本内容，直接写到了程序里。

那么当在旧设备基础上升级为新设备时，所需要删除的部分， 程序逻辑和报警的段落一同删除即可。 而要增加的设备，也同样只需要增加相应的段落。

而其实在标准化烟台方法的架构里，逻辑都是在设备类库里完成的，那么多一个设备和少一个设备，也只不过是多一个实例化调用和少一个实例化调用的区别。 所以可以认为，对报警信息的管理可以做到0工作量，完全不需要再关心了！

这是西门子PLC的解决方案。

特点是PLC和触摸屏之间报警信息部分，不需要通常的变量采集和通讯，而是走了特殊的通道。然而也正因为这个通道是特殊的，所以这个功能的实现必须是PLC和上位机同样支持才行。甚至，这个功能也只在西门子的少数产品型号中才有。 比如S7-1500，与TP触摸屏以及WINCC。
而S7-1200, SMART 200, KTP触摸屏等，则一概不支持。 做不到这样的报警信息直接生成。 所以很长一段时间，我做项目的时候都是要求上位的触摸屏必须用TP，下位PLC必须1500,400。由此多花了不少钱。

西门子内部产品尚且如此，跨品牌就更别提了。 到目前为止还没听说过有哪一家的触摸屏或者SCADA品牌能实现直接读取S7-1500的报警信息。

我在把PLC标准化编程烟台方法从西门子到其它品牌移植拓展的过程中，就一直非常关心对方平台对上位机报警功能的支持。 然而除了ROCKWELL AB有提供了工具间接可以实现之外，其它品牌大都不具备。

所以后来移植的方案上位机都没移植，而是直接沿用使用了WINCC。这部分功能就只能放弃了。

所以这些品牌的系统中的报警都是通过整理点表后导入的传统方法实现的。 当然，标准架构下的报警信息都还比较有规律，甚至也可以规划自己开发软件工具实现。

今年以来，一直在编写新书《倍福PLC标准化编程烟台方法》，TC2部分做的还是与WINCC对接，然而到TC3部分，我就做了与其自带的可视化的对接，画面部分内容已经完成。

现在面临要做的则是PLC做上位机报警。

在倍福系统中（包括TC2中也有，只不过不够成熟），有一个TC3 EVENT LOGGER的系统组件，它独立于PLC程序，而在TWINCAT中单独运行，提供报警信息队列服务。 PLC程序中将报警发给EVENT LOGGER，然后其它的人机界面甚至其它的PLC，可以来收听读取这些报警信息。

在VISU中有一个event table控件，就是专门展示这个报警信息的。 然而倍福家做的就比较麻烦，不像西门子中只需要把控件拖入就能运行。 而是还需要在PLC中单独做一个读取程序，将系统报警信息读取到一个数组中，控件需要绑定到数组，才可以展示报警信息。


倍福官网中有完整的介绍，链接：
https://infosys.beckhoff.com/english.php?content=../content/1033/tc3_plc_intro/3524194955.html&id=

然而悲剧的是，我捣鼓这个已经快个把月了， 一直没搞定。所以，书写到这部分，卡壳了。

囧囧囧囧囧囧囧囧囧囧囧囧囧

我希望有做过这部分功能的同行，能给下指导。同时，有对这部分功能感兴趣的同行，也不妨研究下。 我这里搜集了一批相关的资料和例程，有想研究的可以跟我联系获取。

另外，虽然我研究要的VISU3的功能，其实实际应用中很少见到这样的配置，大多数应用还是使用了专用的触摸屏。 那么，理论上来讲，倍福提供了完备的各种语言的接口，所有触摸屏其实都可以实现event logger读取功能的。

我们希望会有越来越多的触摸屏产品可以直接支持这种EVENT LOGGER，或者有人发现已经具备此功能的产品，不妨帮忙做个宣传。

你看不懂有情可原。