0228 【万泉河】工控行业话开源

开源的概念来自IT行业。

工控行业作为一个小众的行业，背靠IT行业这么一棵大树，从这棵大树身上汲取的营养可真是太多了。

我自己， 以前曾经写过多篇文章， 探讨了工控行业中的程序移植、面向对象， 中间件， CODEREVIEW、架构师等等。也都是对标IT行业来的。

甚至对于开源本身，我也曾经在MODBUS 通信库，微信小程序等的文章里提及过一些开源的计划。

然而，我猜，咱们工控行业的大部分同行，对开源二字的认知，恐怕是有些偏颇的。

谈一下我对程序员代码开源的理解。

开源的思想，来自于程序员社区众多程序开发者和爱好者云集的情况下，对一些底层的简单功能逻辑在设计方法设计接口达成共识的情况下的一种代码分享，通过互相分享，达到利己利他，我为人人，人人为我的目的。 当然，其中也不乏许多优秀的程序员通过将自己设计的软件产品开源之后获得业界大量认可后，从其他的方面获得认同，比如收到投资，被高薪聘用等等。

但主体的根源还是底层代码模块互换共享 ，节省人力的目的。比如大量的软件APP中，都要有用户登录或者付费支付的 环节，这些功能都是可以模块化实现的，而与要实现的应用场景无关。 那么假设A只开发用户登录，而B只开发支付模块，然后简单复制后交换，就各自在自己的软件中都实现了需要的功能。

但如果说是互相竞争对手的A和B，开发的是同一款软件产品，将来都是要在市场上竞争接受用户考验，甚至有可能二选一，非此即彼，你死我活的，要他们把整个软件的代码全部开放，方便对方借用（其实是照抄），那是绝无可能的。

比如， 阿里把源代码开源给JD, 或者抖音把代码开源给美团？这都是天方夜谭的嘛！相反，这些公司之间会有严格的保密协议以及竞业禁止的规定。

所以，结论是：所谓的代码开源，指的是程序员们把无伤大雅的，不危及自身技术优越地位的部分模块拿出来交换共享。 而共享方与使用方对设计理念的认知是一样的，即架构体系是相同的，所以才方便拿来对方的模块直接使用。由此共享才有意义。

而这些，在工控行业，目前还差的很远呢！

相反， 在工控行业，有一个众所周知的共识，即：所有人，都不愿意读别人写的PLC程序。 没错，我说的是所有人，几乎没有漏网者。

那么当身份互换之后，就是，所有人都讨厌读所有人的PLC程序。 互相讨厌。

甚至，有人把读别人的PLC程序比方成互相喂对方吃自己拉的屎。虽然有些恶心，有些过分，但基本符合事实。

所以，读别人程序的，通常只是在学习入门阶段，阅读程序的目的不是为了工作，更不是为了维护和解决问题，而只是为了学习基本技能。 而每个工程师，一旦入门，就会建立起自己的审美观和价值观，即拥有自己的一套设计架构方法，对自己入门学习的对象也有一些改进和否定。

其实方法本身的差异没多大，主要还是每个人的习惯，变量资源的分配，实现方法的技巧等等。

所以导致了因为不熟悉别人的习惯，上手就比较困难，因而比较抵制。其实假以时日， 时间过得稍微久远一些的话，如果没认出阅读的这套程序原本就是自己写的，也忘记了自己原本的思想方法，也照样会心中暗骂程序写的杂乱无章。

所以， 在这种行业文化之下， 你说要程序开源？要把写好的程序给别人看？那对方捂鼻子都还嫌臭，躲都躲不及呢！谁要你开源？我开源给谁看？

所以，当我完成烟台方法的技术突破之后， 为了把这项技术推广给更多同行学习使用，尤其是售价价格在大几千以上，可谓是石破天惊，绝对是开行业之先河，众多同行惊掉了下巴。要我看你的程序还要给钱？你怎么能保证这程序不是屎？我们可都是**长大的，都有丰富经验的呢！

而这里面还有个愿打愿挨的事在里面呢！ 我这边把真实的项目应用案例拿出来，也是顶了一些安全风险的。 设备厂的设计工艺，人家也是有保密要求的。 不希望被竞争对手学去。 所以我在分享打包时，一方面做了些处理。 但同时，也尽量避免被他们的同行业给买了去增加是非。所以我平常绝不讨论分享示范项目的行业工艺。 一些文章举例的时候，会拿一些工艺简单的环保，水处理等的工艺举例探讨。

而我其实也有真正做过纯水制备的项目，也有参加烟台方法学习的学员从事的恰恰是纯水行业。然而我却并不会直接把纯水制备的项目源程序给他，给他的也仍然是原始的样板项目。 而至于你方的纯水工艺的实现，还是要自己去做。我这边为客户做的工艺库，是不方便开源共享的。

所以，以往在各大工控网站上，经常有人把整个项目的设计资料完整打包发出来共享， 那其实不是开源。而有兴趣去学习了解的，也绝不是冲着使用开源去的。而只是新入门这个行业， 入门学习而已。 真正到自己搞设计工作的时候，绝少有人会拿来当初网上下载的资料直接套用。主要是，写程序的方法，那些程序中的模块FB/FC，都不是充分模块化，都做不到直接拿来使用的。 都还要每个人根据自己项目的实际点位实际需求以及设计架构完全重新编写以及调试通过，何来的开源和利用开源呢？简直和开源毫无关系嘛！

即，如果同行之间根本没有建立起通用的程序架构的共识，那开源压根就无从谈起。 甚至付费交易市场也无从谈起。

曾经有烟台方法的学员，接受网友的委托要帮忙写一套恒压供水的多泵启停控制模块，双方并不熟悉，所以就委托我帮忙做中间人。 委托方先把钱款付给了我，承接方写好程序后交对方验收满意，得到确认后我再帮把钱付给承接方。

不过这位承接方因为是参加了烟台方法的培训，就在交工之前先把程序块发给我看。 我看了之后反问他，你这样用烟台方法的架构写的工艺功能块，交给对方，他会用吗？你是不是还需要把上下游的完整的程序功能都给做好，做个完整的例子，交给他，他才有可能会使用？

那这样的话，你岂不是教给他一套完整的烟台方法的编程方法了，那岂是区区几百元的价值可以涵盖的？

学员想了想说， 那算了，我还是重新写吧，完全按照老的传统方法写一个完整的例子给他了事。

而相反的是，烟台方法的学员之间，这种功能块的开源分享就很容易了。 我曾经有写文章探讨过中央声光报警功能块的问题，也给他们开源分享过HA2源代码， 有需要的学员就拿来直接用到了项目上。 而前段时间，有一个学员要研究搞懂其中的原理方法，要自己写功能块，而调不通，所以来咨询我。我恰好自己又有做过一个新版本的HA3，没有实践过，就分享给他了。 他拿到测试好用后，然而却并没有使用。而是从中找到了自己认知的盲点，继续把他自己的程序功能块改进成功了， 然后两套程序块的代码一同分享到了群中！两套都可以用，也都开源，然而同时又可以完全互换。

这才是开源。

同行中，总有声音呼吁我把烟台方法开源。 我说，我没得开啊！我们做的架构和方法，其中的思想原则我大都在专栏文章中和书中介绍过了。 好多程序块的实现方法也都开源讲解过了，比如GETSID和HA2等。然而很多人看不懂的同时，却还在那儿坚持叫嚷开源、开源！

其实，这些持开源建议的， 目的不是开源， 而只是想白白获取。不劳而获，只想收获，而自己不想付出。甚至有可能以开源的名义自己搞到手后，拿回家压箱子底了，成为自己的看家本领了。 

所以，记住了，开源的本质是有获得，有付出；每个人有输入的同时自己也要有输出。 然后更多同行共同努力，才能开辟建设出一片开源的空间。

最后，我也确实有一个PLC程序开源的建议设想。即最近我多次提到的LBP库函数。 这是西门子官方所开发的一套完整的库函数。每个人都可以去学习了解应用到自己的行业和工程项目中。

然而这套库函数是基于S7-1500的，而且结构非常庞大，库函数之间关系错综复杂，有一些难度。 最近一两个月我有做讲座带领大家了解移植到S7-1200的应用方法。

然而，我所传授的还只是方法，具体要完全实现，需要的工作量比较大。就不是我一个人能完成的了。而且，在没有工程项目应用的前提下，我也不太愿意白投入太多精力在上面，开发到完整后，被一些人道德绑架要开源开源。

所以，我在想我们可以成立一个开源社区，针对一个特定的平台，比如SMART 200，把LBP这套标准移植到SMART 200中，我自己经过验证是完全可行的。 所以现在需要的是足够的人手， 愿意付出并自己同时从中得到回报的同行。

当然，这个社区在暂时当下情况下，只能是封闭的，开源也是如烟台方法的学员之间一样，内部开源。 即，参加者大家共同努力，共同付出，完成一套完整的开源项目应用。 这其中取决于每个人自己的能力， 你可以自己去学习掌握LBP，并掌握移植的方法来实现，也可以在能力不足的情况下学习我做过的讲座，了解其中的技能。

不管怎样，要加入开源是要有门槛的，而不是空口来跟我说你支持开源，然后从我这里白撸一套方法资料回去后，就再没了消息。 这样的开源是永远不能成功的。

当然，这其中的难度仍然很大，我估计很难成功。 那样的话，再有人跟我提开源的时候，我就会提醒他去撸LBP去吧！

有志跟我一起建设开创LBP开源社区的同行，可以跟我报名，亮明自己的特长和喜好，比如

LBP SMART 200；

LBP 汇川；

LBP CODESYS；

LBP 三菱

LBP MCGS

LBP 威纶通

LBP AB

LBP C#

LBP FUXA

等等

而具体的付出与回报的方法，我们私下沟通讨论。