德国电气工程师编程

现在在美芝做数控镗床加工压缩机连杆的，内孔精镗用的机器厂里买的不是日本的就是意大利的，

倍福PLC也称为PAC，号称是第三代的可编程控制器。我之前一直想找这样的控制器。但是不得不说，最好用的可编程控制器是第二代的，也就是我们现在在用的三菱、西门子这种小方块的PLC。所谓的PAC可能只是炒作。PLC诞生的初衷就是为了做仿电气控制，而且虽然计算机已经十分普及，但是会编程的人还是很少。自动化不可能完全按软件工程那样搬砖，因为自动化行业的需求变化比较大，一般是用户主导的。PAC虽然看起来是我一起在找的高功能PLC，但是我觉得它的定位不是很好。普通PLC的IO模块用并行总线连接，可以达到最高的IO响应速度，但缺点是单片机的计算能力比较弱，PAC则反转过来，使中央处理器具有高性能，但使用串行信号（一般是以太网）会使IO的响应速度受到限制。PAC可能只是我们的一种情怀，对于多数人，如果真有很强的编程能力，他们会选择去做IT。也就是说，PAC的高级程序员是很难找的。在低水平的程序员与不得不使用梯形图的电气工程师之间，显然后者对企业更有利。我认为自动化场景的响应速度主要受限于IO，其计算量并没有那么大。PAC的优势并不明显。有人可能觉得几万步的程序就可以算很大了。事实上对于一个软件工程，几万步的程序只能实现一个高级一点的记事本的水平。相对而言PLC的程序一般都很小。一般有关联的IO群共用的代码段很难达到三菱FX2N的上限。如果刻意把不相关的IO放到一起，只不过是自找麻烦。关于多轴控制，有现成的多轴控制器和各种好用的托管语言，对于一个懂软件的人来讲，Java怎么样也比结构化文本好用，而且不用担心被品牌绑架。我可不希望用结构化文本去写多线程的程序，结构化文本本身是一种不完整的编程语言，而且很多地方设计得不符合人类的思维，它的用途就是代替梯形图去做一些需要对寄存器频繁操作的程序。结构化文本看起来像Pascal，其操作方式与汇编比较接近，但其实它的理念更像VHDL。而Java可以实现非常精致的线程嵌套和多线程加速算法。PAC就相当于是想做一个类似Qt的架构来代替PLC，但它又无法达到Qt的程度。事实上现在很多新生代的创业公司都会选择用Qt、Java、C#、Python。这是因为它们都比PAC简单，又是全功能的编程语言。很多人图偷懒而选择购买别人的平台，最后的结果就是花在配置上的时间已经可以开发一个新的软件了。掌握了软件技术，就意味着不再被品牌绑架，还可以短时间内转行；掌握了PLC平台或组态软件，只能在被谁绑架的问题上进行权衡。对于个人和初创型企业，自主研发要比接受绑架更有前途。而有些大企业，由于政治、历史条件的因素，就不适合再去变更自己的形态了。当你不再担心钱的问题的时候，你可以接受技术绑架和技术撕票，就可以任性选择看起来轻松的方式，就是去买别人的产品。有些人可能就真的相信大企业有这么大度。其实大企业大度的后面是他们有一个律师团队，可以在技术撕票的时候讨回一部分的钱，损失并不会像没有律师团队的小企业那么严重。当前的PLC应用还是以梯形图为主，因为这方面的人才最好找。虽然现在的C++人人都学，Java遍地开花，但是你不可能轻易找到一个高水平的程序员去做工控。工控的算法太Low了，没有吸引力。你也不可能让一个菜鸟程序员去做工控。菜鸟用通用编程语言可能会把上帝创造的所有错误都给你展示好几遍。没错，他们可不会刚好只犯一次错。你只能接受梯形图，虽然梯形图高手的水平都不怎么高，反正我们也不需要多高的水平，我们看中的是菜鸟犯错的概率会明显小很多。

个人觉得要考虑二个方面：手动，自动。并尽量使用顺序控制，这样比较好看，好查。