0.1 标准化功能

所谓PLC的标准化功能，就是一些常见的可以供所有人重复使用的函数或者实例化功能，比如一个电动机的控制功能、西门子的Epos的功能块（Function Block，FB）：FB284/FB285。

但谈论标准化功能的时候也要分情况探讨，看这些标准化功能的作用范畴。

1.产品供应商或者独立的组织

比如西门子这样的供应商，其提供的库或者功能一定要让所有的人都能使用，比如Epos的功能块、基本运动控制库LAxisCtrl及其他很多类似的库，由于这些标准化功能要供各个行业使用，所以它们不能有很多局限性的东西，比如里面应用到M寄存器等类似的变量（因为这些变量开发者可能会用到）。因此，这些标准化功能一般都是需要实例化的功能块或者一些函数，并且里面的程序变量一般都是静态变量或临时变量。

由于潜在使用者是各个行业，所以这样的功能块或者函数的功能一定是针对产品的功能，不会涉及具体工艺（飞锯控制库属于工艺标准库，不是功能库），这样用户只要参照文档即可像使用PLC自带的指令一样方便，并不会对自己的程序带有任何负面的影响。

还有一些独立的组织，常见的比如PLCopen组织，他们定义了一整套运动控制的相关指令和方法，这些指令就是各个PLC厂商都在应用的MC指令。用过不同品牌PLC的人肯定会发现，其运动控制指令从名称到实现方式都很相似，不同的只是依据各个品牌的特点做了一些相关的改进。

2.设备开发商或者系统集成商

这类开发者开发的标准化功能都是只有在自己公司的项目上才有使用价值，对于第三方用户来说，只有思路的参考价值，并不能直接使用。

比如电动机控制，若要将电动机所有存在的可能性功能做在一个标准功能块，电动机是工频控制还是变频控制，有没有多段速控制，有没有方向的切换，远程起动还是本地起动，不同控制方式的错误诊断等，把这些功能全部实现的话，那这个功能块的引脚会非常多，使用起来会非常复杂（在PCS7中经常看到很多引脚）。

对于一个设备开发商或者系统集成商来说，仅用于匹配他们的电动机控制需求可能没有那么多，同时对于一些工艺设备来说，往往简单的一个电动机功能块也只是工艺设备需要的底层功能块（因为电动机的控制需要结合工艺需求实现不同时序要求，Epos也可能是工艺设备的底层块）。这个时候，这个标准功能就没有必要大而全，也没有给第三方使用的必要。反而，这样的标准功能块的效率会更高，对于和工艺的匹配最精确。

由于不需要考虑第三方的使用需求，这个时候该模块可以结合自身程序架构编程。有的程序架构中可能会使用一些M寄存器的变量，这些变量都是自身程序架构中已经定义好了的，即使有需要使用的时候也会有一些预留区域，在设计标准功能块的时候就需要结合自身程序架构理念，实现工艺和程序架构的无缝匹配。

这也是很多国外以前的程序中M变量频繁出现的原因，因为这些程序和自己设备工艺以及程序架构是无缝匹配的，同时也不需要像西门子一样提供给可能存在的所有从业者使用。

这样的功能块对于其他人来说不是标准功能块，但对于该设备开发商或者系统集成商来说，这就是他们的标准化程序，是他们效率和质量的倍增器（3～4个工程师一年可以做2～3个投资过亿元的大型项目，这是笔者的实际经历，这就是倍增器的加持效果）。

在Portal优化使用的时代，不建议使用M寄存器。

3.设备编程原则

具体到一个设备或者对象，在编程的时候怎么去开发标准的程序呢？答案就是遵循事物本来的面貌去（面向对象）做一个系统的开发和应用。

如图0-1所示，有个工件需要从设备1传送到设备2上。为保证工件能完全到达设备2，更多的人都是在设备1末端光电器件被触发后，延时足够的时间来确保工件能完全传送到设备2上。

以上思路并没有问题，但实际调试发现针对不同的传送速度（工件不变），这个延时时间还得慢慢调整，否则要么工件还没有完全到达设备2，要么就是延时太长降低了设备的工作效率。

但我们的程序是工件实际轨迹或者说本来面貌的完全体现吗？

显然不是，时间只是工件传输过程的一个表象，工件传输的实质是位移，即工件在离开光电器件后还需要向设备2的方向再移动一个距离L（跟设备1和2的速度以及时间相关）。

这才是这个工件传输过程中的本来的面貌，本书内容要强调的是，所谓的编程，是现实的实际内容在程序世界的再现或者重构，这样的程序才能更加灵活，适用性更强。后续章节中，也会有这个相关内容的介绍。