本文接《为什么我离开了PLC编程行业(上)》内容。
在截止日期前一周，当大部分故障排除工作完成时，外部工程公司的项目经理提出要求，在PLC程序中实现手动模式：必须能够在显示屏上输入代码，选择电机、泵、阀门，将这些设置为手动模式，并切换这些执行器的输出。这是一个巨大的变化，为了实现这一点，我必须将所有输出执行器移出单个步骤，并在将位输出到实际执行器之前，将其与条件自动/手动模式位相结合。更改这将非常耗时。我当然提出了反对意见，但项目经理坚持要求必须加入这个手动模式。我正考虑给高级工程师打电话。
为什么我没打呢？我在想……这种整个编程方法根本毫无意义。中央步进控制FB写得非常紧凑，虽然你可能会在PLC中使用极端智能的编码来节省空间，并允许使用更小的PLC型号，但节省空间就会写出无法阅读的代码，然后又浪费更多空间去写冗余代码，这是没有意义的。我不得不花费数月时间输入所有这些条件和执行器的列表，这既令人沮丧又耗时，而且最终证明在需要更改时非常不灵活，就在我要做的第一个项目中就遇到了这个问题。中央步进控制FB没有按预期工作，这非常奇怪，因为如果它到处都在使用，那么它应该能够正常工作。在截止日期前一周才提出手动模式的要求，这完全出乎意料。如果这种编程方式到处都在使用，项目经理怎么可能不知道这个请求将意味着需要更改编程呢？现在我知道，我应该要求把这些要求的更改写在纸上，这样就不会有任何争议了，但请记住，我刚从大学毕业，我不知道该如何处理这种情况。但回到问题上：为什么我没有给高级项目经理打电话？再想一想……这五个月来，我一直在输入这些无聊的条件和执行器的列表……我真的想把这个作为职业吗？
我记得我在大学期间参加的PLC课程。我们有做过这些PLC编程练习。因为我在高中时就已经做过一些PLC编程，所以我知道有一种简单的方法可以避免复杂的梯形图逻辑编程：只需使用标记定义状态，当满足下一个步骤的条件时设置下一个标记，并使用反转标记来重置前一个步骤的标记，很容易做到。我们的小组是所有小组中最快完成这些练习的。当老师发现我使用这种方法时，她给我布置了特别的作业，要求我不能使用这种状态编程方法，以让我改掉这种编程习惯！现在，两年后，我在这里，面对着这一大堆复制的代码，根本没有更改的余地，因为如果我需要在一个步骤FB中更改某些内容，为了保持一致性，我必须在所有步骤FB中都进行更改……这不是很讽刺吗？这显示了基于状态的编程实际上是多么低效和不灵活。我必须做出决定。
我评估了更改以允许集成手动模式而无需重写所有内容的可能性。有一个解决方案：你可以在当前扫描周期中再次重写输出，因为缓冲输出只有在扫描周期结束时才会写入到实际输出中。这是一个糟糕的设计，因为现在你必须跟踪PLC程序中哪个输出是实际写入的。这可以避免重写所有的步骤FB，但有一个问题：我必须避免程序在手动模式下跳转到下一步。不运行中央步骤控制FB是不行的，因为有些输出依赖于步骤FB内的输入：这是一个Mealy型状态机，而不是Moore型。还剩下两个选项：在每个步骤FB的下一步中添加手动条件，但这样做我必须更改每个步骤FB。因此，重写中央步进控制FB的代码以避免在手动模式下步进是剩下的最后一个选项。这花了一天时间，实施后我没有遇到任何问题。
然后是对最新代码的测试，因为我必须添加这个手动模式代码，而且我们只剩下一周时间了，我们必须熬夜进行测试和故障排除，直到每天凌晨三四点。这包括在比利时奥瓦尔附近阿尔登地区冬季可能最冷的酒店房间里夜间编写代码。请注意，如果外部工程公司的项目经理没有要求手动模式，这个项目上周就已经完成了。周日下午，也就是截止日期的前一天，它准备好了，在短短5周多一点的时间里，它已经完全编程、实施并测试完毕。
周一早上，我所在公司的部门主管给我打电话，询问项目的进展情况。我回答说我们遇到了很多问题，但项目已经完全实施并投入使用了。他要求我明天到现场去。第二天他并没来现场，这让我感到奇怪。那天我还与外部公司的项目经理通了电话，那次通话中并没有提到什么紧急的情况。
那天晚上，我被叫到了人力资源部。人力资源部的人说他们听到了关于我的一些不好的事情，说我很固执己见。之后我一直在问自己这些问题：难道我没有向外部公司的项目经理抱怨过他们没有提前要求手动模式，导致我不得不重写步骤控制功能块(FB)吗？难道我没有向她解释过我必须更改步骤控制FB才能让手动模式正常工作吗？为什么部门主管没有问我对发生的事情的看法？为什么截止日期刚好设定在我6个月试用期结束的前一天？为什么部门主管一开始就没有为这个项目指派项目经理呢？
一些观察：我很确定部门主管没有看过我的代码，因为：我是在巨大的时间压力下决定重写这个步进控制FB的，而且这些更改可以很快恢复。我说的只是一页AWL代码！我没有告诉他，所有的更改都只在我的笔记本电脑上，直到他不在办公室的最后一天。此外，我还记得有一次部门主管非常粗略地审查了我的代码，只花了最多10秒钟，还有另一次他处理了一个5周的工作，他说他可以在一个周末完成。这绝对是我职业生涯中遇到过的最糟糕的雇主。他没有提供任何指导，只是利用我来输入成千上万行枯燥的代码。
这些事件让我重新考虑了我的职业生涯。很可能我只是被雇来做那些枯燥的录入工作，以减轻他们的工作负担。显然，这种编程方式的真正意图是为了让某人能够轻易地被替换，这在PLC编程中是非常容易的。自动化领域是一个非常保守的领域：公司对PLC技术的主要担忧是其可靠性和可用性。公司宁愿坚持使用已经证明可靠且不仅替换零件容易获得，而且程序员数量也众多的昂贵PLC技术(提示：西门子)。很多PLC程序员只是技术人员，只是用于现有基础设施的维护。这意味着我必须与很多愿意接受更低工资的人竞争。这显然不是一个最好的工作环境，所以我决定换一个领域。
我决定换到网络领域。互联网刚刚开始兴起并变得流行起来，这是一个充满新技术且正在成为主流的令人兴奋的新领域：TCP/IP、思科、网络浏览器、防火墙、Linux、Windows NT、代理服务器、Exchange、电子邮件。
我申请了一家翻译公司的初级职位，负责管理公司的网络和服务器。两周内我就找到了新工作，而且薪水更高。我记得我去应聘的那天，当我走进大楼的门厅时：我看到大楼是这家公司与另一家公司共享的。左边是翻译公司的标志，但右边竟然是我过去五个月一直在为其工作的那家外部工程公司的标志！……
说真的……(想想看，我们国家有十几万家公司！)
所以你可以想象，一年后，我遇到了去年一起工作的项目经理。我问她项目后来怎么样了，我写的代码是不是都被扔掉了？她说：“没有没有，你的代码里有很多非常棒的想法！”
如今，当我再次审视自动化行业时，我看到了这些工业PC，它们在Windows机器上运行着实时内核，速度比PLC快得多。但当我检查编程环境时，发现同样的编程技术仍然适用。虽然实施了一些改进(比如IEC 61131-3、面向对象编程等……)，但当我尝试屏幕编程时，我想起了在SCADA工作时那种同样的恐惧：处理GUI元素是多么的不灵活。
如今，当我审视专业的IT世界时，我看到了所有这些技术正在以非常结构化的方式改变着这个领域：大规模叶脊数据中心、虚拟化、融合、去重、Docker、软件定义网络、微分段、软件应用、Puppet、云网络等等，不一而足。在编程方面，Python正在向前发展，并推动着像lambda、列表推导式、生成器、装饰器等函数式编程概念。新的数据库概念如NoSQL已经出现。非常快速的开发和交付流程被广泛应用。下一代网络技术物联网(IoT)将更进一步改变格局：现在你将得到所有这些内置无线网络的设备。然后还有数据科学和机器学习……
与IT行业相比，PLC行业缺乏新的PLC编程概念，而这些概念本可以极大地改变这个行业。原因显而易见，维护和保养现有设备的优先级高于尝试一些新的技术，并且需要冒着这种技术失败时没有支持的风险。它仍然是一个非常代代相传的行业。所以，如果问我我还愿意回到自动化行业吗？不，我不打算再回到PLC编程了，但对于那些愿意进入这个行业的人，请三思：“软件正在吞噬世界”。这种情况会持续多久，我不知道。
后续
自从我写下这篇文章后，我一直在问自己，我究竟在什么时候能够意识到这种微观管理其实是为了控制，而不是为了支持管理。第一件奇怪的事情是，项目工程师在逆向工程状态图，因为他本可以向外部工程公司索要这些图，但这仅仅表明了一次迁移。我收到的第一个实际暗示是在我前往设施之前与经理的最后一次通话中。在解释完我要做的事情后，他突然跳到另一个话题上。他说在这个项目之后，他会继续和我一起工作，将他基于状态的S5编程方案迁移到新的S7编程语言。当他在解释这件事的时候，我问自己：“为什么你现在要谈这个？”S7语言大多是向后兼容的，所以他可以在10分钟内迁移他那只有20行的步骤控制块。不幸的是，我在测试期间忘记了这次简短的对话。回想起来，现在很清楚这次迁移工作是多么微不足道，这也直接表明他只是想让我相信他在项目结束后还想继续雇用我。这件事发生在我职业生涯的早期，当时我以为发生在我身上的事情都是正常的。现在，随着我的工作经验越来越丰富，我可以说我的第一直觉大多是正确的，而自我怀疑往往是我背叛自己的原因，换句话说：当事情不合逻辑时，背后一定是有原因的。
现在，这些事情给我上了一堂人生课。看看这些事情：经理真的从这种策略中受益了吗？实际上没有：他不仅解雇了正在从事他项目的工程师，而且最可能的结果是项目经理接替了这个角色，不得不“纠正”一切。我知道这件事的结果，他在我被解雇后的第二个月就决定离开公司了。所以项目经理只是看了看我的工作就决定离开了。巧合吗？我认为不是。对我来说，这开启了我职业生涯中的一条新道路，我再也不会仅仅根据事情呈现给我的样子来假设它们了。
作者：Jurgen Kobierczynski
