急停判定的作用是：在急停常闭中断时，输出急停激活信号，且在按下复位按钮之前，保持急停状态不变。

这意味着我们要记忆状态，但是IEC61131-3标准Function是无状态的，而且也不接受指针、引用作为参数。

方法一自然是使用Function_Block，但是为这个简单的功能建一个FB，有点杀鸡焉用牛刀之感；何况其中只有一个BOOL型状态变量，我并不确定这个FB的实例会占据多大的字节空间——对这个FB中的BOOL型变量究竟是否会被优化与其它外部BOOL型变量合并，我更是持怀疑态度。

方法二是借用函数式编程语言的惯用操作，状态由外部存储和管理，FUNCTION只接收老状态，经过计算后返回新状态。由于FUNCTION本身无状态，所使用的参数和局部变量都分配在栈上，这种方式更符合我的品味，所以这里采用这种方法。
其声明如下：

FUNCTION CheckEmStop

VAR_INPUT
    btnEmStop_nc: BOOL;      // 急停信号常闭点
    btnReset: BOOL ;         // 复位信号
    oldEmStopActive: BOOL;   // 老状态
END_VAR
 
VAR_OUTPUT
    newEmStopActive : BOOL;  // 新状态
END_VAR

代码实现非常简单，直接按业务逻辑进行翻译即可：

阅读剩余部分

这世上更优秀的事物并不会因其更优秀而得到更广泛的认可和传播，反倒是那些追求简单甚至于简陋的东西会形成更广泛的生态。

初学编程的那两年，我曾是Python的坚定拥趸；再后来的几年，伴随着我变成了静态类型的狂热份子，我逐渐对Python失去了兴趣。事实上，选择静态类型还是动态类型，在很大程度上还只是团队偏好问题。但比起这种团队偏好问题，它的缩进语法、和类型推导能力和F#的比起来更像个残废——这一点板上钉钉，无地可洗。但这些并不妨碍F#是一个冷门的编程语言。同样优秀的还有Rust，也长期处于这种尴尬的境地。另一方面，随着Python生态越来越好，越来越多的热钱涌入其中，这些热钱促进Python不停进化，又反过来促进更良好的生态。

谁都知道，在编程领域中，优秀的工具会让你犯更少的错误，但是更严格的约束会打击初学者的信心，过高的学习曲线会引来一些人的恶评。反倒是那些简单的工具组合，甚至放任人类自由“犯错”，会形成更良好的生态，比如bash，语法简陋，却由于种种机缘巧合，成为Linux中的标配。

最近我又重新审视Python推崇的那个格言：

Keep it simple, stupid

刚开始奉之为圭臬，后来不以为意，再到如今又觉得耐人寻味。

编程语言如此，其它的人和事也是如此。那些活得更好的业务和产品，是更高技术含量的吗？显然不是。历史的潮流如同奔腾的长江滚滚向前，我们这种无名之辈裹挟其中，注定不能独善其身。