工控前辈经验之谈 | 编写PLC程序从做Excel表开始

工控参考

关注工控自动化大事小事

编者

作为在工控自动化行业侵淫已久的工程技术人员，无论在程序编写，抑或现场处理都会总结出自己的一套，本文作者周舟，2001年开始接触PC控制和运动控制，先后就职于海天集团、施耐德电气、倍福自动化，宁波致迪自动化，以技术人员和市场人员的身份经历了浙江机械制造的重要发展阶段，也总结出自己的一套PLC编程经验，与大家分享。

//////////

上次看了邓李老师的文章《邓李：如何编写优质的PLC/PAC程序？》 颇有些感受。工作快20年，多少写了些程序，大多是和机器相关的，记得本科的毕业设计是用VB+数据采集卡写了一个拖拉机发动机喷油嘴的弹簧测试，硕士课题用C在Linux下做了一些代码，而毕业后在海天，和师傅一起，继续在Linux下用C和QT堆了一台注塑机的控制器出来。

01

第一次接触PLC，是在海天公司给一台双色注塑机增加一个转轴功能，这个功能注塑机电脑上没有，所以外加了一个PLC，记得当时用的是三菱FX，这是我接触的第一个PLC，当时因为供应商提供了PLC、伺服电机、减速机等一套产品，所以程序也就让供应商写了。

到了倍福之后，由于整个办事处就我一个人，处于什么都干的状态，所以除了销售工作，也做技术支持。记得第一个项目是上海的同事写的代码，同事来现场一次，后面的维护我接过来。所幸TwinCAT2这软件比较简单，一来二去自己就上手了。

后来慢慢地也给客户写一点DEMO，用来给客户解释为啥IEC61131-3是一个简单的东西，不像想象的那么难，不要一想到ST语言就想到高级语言，等等诸如此类的问题。写着写着，也有了一些心得。

在聊聊这些心得之前，先说点题外话。我做过两件和工作不太相关的学习，一次是读研究生时，一个培训班来学校推销ISO内审员的培训，当时因为好奇去报了名，花了几百块钱听了一堆ISO的知识，记得讲课的是一位老干部。另一次是刚上班时，去报了一个计算机高级程序员的考试，看了几个月书，离及格线差了那么一大点（不是一小点）。但这两个事情，对我的影响比较大，ISO的学习，让我理解了凡事要有流程，流程要有标准，标准要有数据，数据要可追溯，这为后来理解工业4.0打下了基础，而高级程序员的考试，让我学到不少IT的知识，尤其是软件工程方面的知识，对于构建一个大的程序，还是有帮助的。

下面的心得，和这两件事情，有比较大的关系，说穿了，就是多做纸面工作。

02
  

在写代码之前，我会先建个EXCEL表格，大约有这么几项（这里我虚拟了一个立体车库的项目，因为每天到办公室都会和立体车库打交道）：

1、IO表，输入输出的模块型号，模块的位置，每个模块上每个点的定义，以及外面接的是什么元器件。对于一些电气CAD软件，会自动生成这个表，但我们还是建议用EXCEL做一份，以便存档。

2、变量表，一部分变量是有地址的，比如需要和上面提到的IO表进行对应，比如Modbus通讯。Modbus通讯需要定义变量地址，而IO对应的不需要在程序中指定，只要在系统配置中和硬件进行连接。另一部分变量是没有地址的，但也不能随便定义，要有一定的规则，以便阅读。

3、结构体（Structure），结构体的设计，可以放在变量表之前，为了提高效率，我们会设计一些结构体来做数据类型，比如一个气缸，就可以设计一个结构体来表述，这个结构体会包含气缸的方向，磁性开关状态，以及两个方向的超时报警时间。在使用到气缸时，就可以用这个结构体类型来直接定义气缸，而无需去定义每个气缸设计的变量。

必要的话，可以设计枚举变量，用来表述机器的状态。

4、POU名称（Program Organization Unit程序组织单元）。POU有三种类型：程序（Program）、功能块（Function Block）、函数（Function）。在规划阶段，程序和功能块的构建是很重要的，功能块会降低很多重复工作，从而避免一些普遍性的错误（当然，错了也就都错了），程序的调用、状态的切换是否清晰可控，则决定了整个项目是否足够强壮，并可持久改进及维护。

5、工艺说明，包括各个工作步骤、步骤的衔接、条件的转换等。这个步骤，可以在EXCEL中做，也可以用word、PPT，但相比之下，EXCEL可能是个更好的选择，因为EXCEL的纸面是没有限制大小的，而word和PPT很容易遇到编辑范围太小的问题。

当然，也可以在纸张上来画。我个人建议每个项目备一个A4的本子，和EXCEL配合使用。

做完这个表格之后，我习惯将变量表直接复制到TwinCAT中，因为在EXCEL中，很多重复工作可以直接选中表格单元进行拖拉复制，比如注释的“（* ”和“*）”，以及末尾的“；”，都是直接复制单元格的，而对于一些带序号的变量，如X0-X7，顺序复制即可，这会在大幅度减少工作量的同时，降低变量编写出错机率。

在程序编写过程中，除了用于for循环的累加数，以及用来调试时的一些标志之外，如果要增加有实际意义的变量名，必须先在EXCEL里增加，再复制到程序中。这有点强迫症，但事实证明，这个有用。

接下去就是建立各个POU，对于功能块，要写好输入变量和输出变量，而函数只需要有参数即可。写完了每个POU，记得在每个POU的主体敲个"；"，这样，即使我们一句代码也不写，也是可以编译通过的。如果这时候编译不通过，可以看看是不是哪里有手误了，因为这时候能错的地方都是系统保留字，或者是忘记敲"；"，注释的括号少了之类。

接下来是不是写代码？不是的，是先写注释，而且是全面注释，即在各个功能块中，先写好注释。在TwinCAT中，一个程序块只需要一个“；”，即可编译通过，我们上面已经敲好了"；"，所以不用担心没有代码会造成程序不能编译。

我们回到前面第4点，如果流程图已经画好，那我们就把流程图搬到编程环境中，还是按照从大到小的原则，我们先把步骤编好，具体每一步里面做什么，可能远不如步骤之间怎么切换衔接来得重要。所以，在这个过程中，我们还可以用注释来替代代码，但别忘了在各种for、case中加上“；”。

最后一步，让我们在所有注释的地方，把代码写上。然后，编译一下。

如果有人可以把PackML的文档看一遍，会发现里面就有关于状态切换的图表，如果有兴趣，可以去找下PackML的文档。

如果你用的是TwinCAT或者Codesys的环境，我建议在写EXCEL表格和画流程图的时候，顺带把人机界面的草图也画了，我觉得集成人机界面的开发环境就是自动化工程师的大救星。人机界面和PLC在同一个环境内，意味着可以随时看到工程师想看到的内容，比如在调试时，需要看多个变量，那建在人机界面上会方便很多，不需要在程序中在线观察。

人机界面和PLC的集成，除了大大提高自动化工程师的幸福感之外，也会极大激发自动化工程师的创作欲望。比如有些DEMO，我会将逻辑动作的条件和输出状态都放在画面中，这样可以很清楚看到一个逻辑动作没有执行的原因，比如某几个动作有先后，那做个定时器或者多个定时器，将这些定时器的输出放在同一个画面，就可以明察秋毫了。

写完了程序，机器也动了，我们再来做一张表，就是修改记录，在这张表里，我们写下，某年某月某日，为了什么原因，我们改了哪个程序，怎么改的，修改后我们怎么测试的，测试的效果如何。

而修改的程序，不建议直接在原程序上改，可以建一个新的POU，也可以在POU里写一个新的action，在对应的调用处改掉调用名字即可。这样，即使新的程序出了问题，也很容易改回（RollBack）到原来的程序。而新的代码中，记得在头部写好注释。

03

至此，我们回过头来看看，我们获得了哪些好处：

1、我们有了一个清晰的名字列表，包括变量的、IO的、程序的

2、我们有了一个清晰的结构

3、所有的问题会有据可查。

上面这几点是针对程序本身的益处，而对于项目和企业而言，则有更大的意义：

1、通过分解，将代码部分的工作量比例降低了，这种逐步聚焦的方式，可以让工程师把精力放在最关键的地方。

2、便于沟通，在代码之前的这些工作，都可以和其他人共享，比如IO表部分可以和电气工程师以及电工沟通，程序流程部分可以用来和工艺工程师沟通。

3、便于维护，在移交给其他工程师，或者多人开发同一项目时会方便很多。如果没有注释，基本上工程师自己都会忘记原来写的什么。

4、便于更换平台，当需要更换一个控制器平台时，会发现，大部分工作是相通共用的，这会在切换平台时节约大量的时间。

本文用了一些IEC61131-3的概念，关于IEC61131-3的书很少，推荐彭瑜老师和何衍庆老师的那本《IEC61131-3编程语言及应用基础》，机械工业出版社出版，这本书我买了应该不下三十本，用来送人。记得在倍福10周年庆典那天，公司邀请了彭瑜老师，恰好庆典在人民广场附近举办，席间跑步前进到福州路的上海书城，居然买到了那本《IEC61131-3编程语言及应用基础》，请彭瑜老师签了个名，留作纪念。

另外推荐林锐博士写的《高质量程序设计指南 C++/C语言》，这本书有人不喜欢，觉得这本书水份太多，干货太少，但读起来还是比较轻松的，这本书出到了第三版，目前在网上有很多二手的在销售，也有一些电子版的，建议找来读一读。

后记

写这篇文章的原因，一方面是看了邓李老师的文章，也想谈谈自己的心得，另一方面，也是看到随着工业4.0的普及，以及我国OEM制造业正在向高端发展，PLC程序方面，也慢慢向IT方向发展。

相比于PC或者网络软件，自动化程序有几个特点：

1、使用对象比较窄，这造成了对程序的质量要求、功能要求都不是太高，机器能开就行。

2、代码量小，因为1的原因，以及机器本身的特性，PLC的代码量是很小的。

3、协作性很低，很多公司只有一个自动化工程师负责PLC程序，而且对程序质量要求很低，只要求机器能跑。

这些特点，造成了自动化行业，尤其是离散自动化行业，对于代码的质量基本是没有要求的。我记得大学时候买过一本《软件工程》的书，开头有个例子，是一个科幻电影里的飞船计算机艾尔出了软件故障的故事，随着现在机械设备制造业的发展，机器的销售越来越多，客户的需求也变得越来越定制化，这种软件的故障，在将来会慢慢出现，如何应对这个事情，唯一的道路，只能是从计算机行业去借一些经验来。

我作为一个销售来写这个文章，会有很多漏洞，但还是期望我的文字可以引起自动化工程师的共鸣，起到抛砖引玉的作用，大家一起为未来做些事情。

❒ 来源：“工控百家谈”公众号
❒ 作者：周舟

往期推荐