最近看到一些探讨标准化程序的写法，我也一直在寻求更适合自己的方式。对于这些东西我分享下自己的看法和现在手头做的设备程序结构，希望大家也分享下更好的做法，互相学习，提高工作效率。

首先我觉得要说的是标准化模块化程序是相对而言的，如果你的程序非常简单，就谈不上标准化这些，抬手就写是最快的。如果你的程序比较复杂可能需要考虑结构是否明了，功能划分是否清晰，后面不断修改优化，是否产生交叉干扰，添加删改是否简单便捷等等，也就是这些需求促使我们一步步把程序走向标准化模块化。

标准化是为了提高效率和方便维护，适合自己的才是最重要的，我现在做的设备是半标准化，半非标，每台设备有改动，也有不少类似之处。

1、OB块。通常只写调用FB或FC块，以及少量的比较通用的公共程序。

2、FB块。我尽量把设备按照工艺或硬件结构分成几大功能，每个功能写个独立的FB块。功能和功能之间的交互定在IO管脚。IO管脚大多是硬件IO，加少量的功能交互点位。FB变量的命名我有自己的一套习惯，输入输出管脚的变量如果是硬件IO都加上I_或Q_。静态变量里面和触摸屏交互的变量全部带前缀，如按钮H_  状态显示M_  报警E_ 参数D_ 提示W_  其他中间变量，计时器等都按功能命名不带前缀。这样做主要是为了做屏幕时不遗漏和好归纳。另外参数D类型变量都需要断电保持和范围限制。有时候为了1个FB能适应不同的要求会写一些冗余程序，加上模式选择输入管脚，哪种机型就填写对应管脚012…，尽量手头少些程序版本，多整合到一起。

3、FC块。以上程序写完后剩余的一些小功能，外围报警检测保护等完善功能写在这里。FC程序不做管脚，仅作为程序功能的分块，FC程序内的变量采用硬件IO和全局DB变量。我会建1到2个全局DB块，用作这些FC的中间变量，以及一些其他必要的功能。这些DB变量命名方式和背景DB的静态变量命名一样，和触摸屏交互的都带前缀，不交互则不带。原则是尽量不用M变量编程。

4、DB块。大多是对应FB的背景块，名称默认。会手动建立1到2个全局DB，用作非FB程序中的使用，以及FB交互的传递变量等。

5、报警。报警检测都是程序里处理好的bool型，但是屏幕只能是word型，如果添加单个报警处理比较麻烦，还需要在屏幕写报警文本对应。我参照的网上之前有人分享的，把报警在PLC转换成文本，然后在屏幕显示的思路做的。这样添加报警只要拉到报警接口就好，不用做其他任何事。缺点是这样做报警比较占用PLC内存，过多的报警不适合。我用的报警大概100条左右。

6、基本都是用优化的块。优化的块能够在DB里单独设置断电保持。有时候碰到用的1200PLC但不是西门子屏幕时就很痛苦，并且这个屏幕不支持标签通信，只能绝对地址。虽然也有一些屏支持了标签通信，但是真的不好用。1200配绝对地址通信的屏幕时，如果将原来优化的FB改非优化，会导致不能单独设置D参数的断电保持，全局断电保持是有问题的。另外DBX.DBX X.X这样的方式太长太容易出错。所以我采用的另外创建变量，然后进行映射，映射时变量分读变量写变量，断电保持变量和非断电保持变量。映射的变量可以选择M变量或全局DB。衡量最简便我创建了2个非优化DB变量DB1 DB2，分别读变量M E W  写变量H D进行映射，用EXCEL建的的SCL，工作量尚能接受。

这个方式相比用西门子屏幕是很麻烦的，但又有什么更好办法呢？或者在FB内将和HMI交互的变量建成读写及保持的3个结构变量，外面映射时更方便？

以下是我报警模版的程序