简介这份《Codesys程序开发指导》是一份面向PLC工程师、自动化技术人员及工业控制初学者的PDF技术文档系统讲解基于IEC 61131-3标准的Codesys软PLC开发方法。内容覆盖五种标准编程语言梯形图、功能块图、结构文本、顺序功能图、指令列表的特点与选型并深入介绍软PLC控制方案、Codesys实时核、软件安装流程、通信协议编程及实际控制系统实例适合希望快速掌握Codesys项目开发与调试技能的读者。资源为单个PDF文件压缩包大小12.6MB便于下载后离线阅读或按章节查阅。目前已有160人学习内容结构清晰从标准概览到工程实现层层递进兼具理论说明与实例引导可作为入门自学和日常开发的参考资料。1. 从硬PLC迁到CoDeSys一个能写五种编程语言的软PLC环境如果你和我一样被某输送线设备的一套老旧PLC程序困住过——原厂软件绑定特定硬件、换一个品牌就得重学一套IDE、出差调试还得扛着加密狗——那看到CoDeSys一般写作Codesys时会有种“这账终于能算了”的感觉。它不是一个具体的PLC型号而是一套符合IEC 61131-3标准的软PLC开发环境一个工程里能混用梯形图、功能块图、结构化文本、顺序功能图、指令表五种编程语言代码在硬件层之上抽象出来后续换控制器平台时应用层程序可以整体搬走。网络上关于它通信组态的资料多而散这本开发指导最值钱的部分是把“编程语言选择、任务周期配置、网络变量与协议通信”揉进同一套流程里讲适合刚转软PLC的电气工程师也适合需要把控制系统做成产品化项目的一线开发者。2. 先理解IEC 61131-3的软件模型设备、应用、任务、库之间怎么协作CoDeSys的编程入口不是“写代码”而是“搭软件模型”。目录里从标准概述直接跳到软件结构说明这层模型决定了你后面所有程序组织方式。新手最常见的误解是拿它当普通IDE用丢一堆POU进去就编译结果在线监视变量时发现任务根本没执行。2.1 五种编程语言怎么选不是哪个好用而是哪个场景该用哪个IEC 61131-3把梯形图LD、功能块图FBD、结构化文本ST、顺序功能图SFC、指令表IL定为标准语言后来又加入CFC连续功能图。这本书把这五种语言的特性和适用场景分开写核心逻辑是这样LD适合讲继电器回路的本质电气出身的人一眼能懂FBD适合做信号处理和闭环逻辑把功能块拖出来、连线比写IF语句直观得多ST是高级语言适合复杂数学运算、数组处理、协议解析这类“写句子”的场景SFC天生是流程控制语言适合按步骤走的工序比如分拣、包装、加热炉段控IL接近汇编日常做项目基本不碰它只有在需要极底层操作时才有意义。我在实际项目里的分法是设备启停、互锁、急停链路用LD因为这个逻辑要从电气图纸对应过来维护的人看着放心模拟量处理、PID输出、数据计算用ST写成函数方便单元测试整条产线的工序动作用SFC编排每一步的进入条件和退出条件一目了然。选语言不是看个人喜好而是看你希望后续谁来维护这段逻辑以及故障时现场人员能不能快速定位。资料里还有一个细节同一段逻辑可以混合着写LD里调用ST写的函数块ST里也能实例化LD做的功能块这个我在后面实战章里展开。2.2 设备与应用区分“硬件描述”和“逻辑描述”两个层面CoDeSys工程左侧有两个容易混淆的节点设备Device和应用Application。设备节点描述的是物理控制器、总线接口、远程IO站它对应硬件配置应用节点才是你真正写逻辑的地方对应IEC 61131-3里的“程序组织单元任务全局变量”组合。先加设备还是先建应用直接影响导入导出时的内容边界。我碰到过有人把Modbus TCP从站配置错加到PLC应用下面结果网关变量全部失效一查才发现设备树和应用树彻底乱了。设备树里的每个子节点是一个“驱动”或“协议栈”比如某个现场总线主站、某个串口模块。应用节点下面才是任务、全局变量、POU、配方、采样跟踪这些对象。这套结构的价值在于硬件变动时比如换了一个品牌的远程IO站设备树重新映射应用层的逻辑地址通过绑定变量自动找新通道不需要改写业务代码。你要养成一个习惯凡是涉及地址映射的配置全部停留在设备树层面应用层只认变量名不认物理地址。一旦违反了程序移植性就废了一半。2.3 任务调度周期、优先级和看门狗决定了程序会不会“飞”任务Task是CoDeSys里最容易被忽略却最要命的对象。一个应用可以创建多个任务每个任务有自己的周期和优先级POU是被分配到任务里执行的不是编译器自动调用的。资料里把任务单独列出来讲对应到实际调试中就是“为什么有的程序块只在某个周期执行有的却卡死”。常见的配置方式有两种一个轮询任务跑全部逻辑周期10ms或者拆成多个任务——高速模拟量处理1ms、主逻辑5ms、人机交互界面刷新100ms。多任务模式下相同变量在不同任务里读写时要格外小心数据一致性这个我在避坑章再细说。任务配置时有三个参数必须理解周期Interval优先级Priority看门狗Watchdog。周期决定执行频率优先级决定冲突时谁先跑看门狗决定任务是否被判定超时。第一次建工程时直接默认参数跑还好但一旦你加了协议通信或大量字符串处理任务周期不满足执行时间需求控制器会直接进Stop状态现象就是程序跑着跑着突然停住在线看状态才知道是看门狗超时。建议的排查姿势是先开采样跟踪看任务的执行时间曲线确认最长耗时点在哪个POU再决定是优化代码还是放宽周期而不是无脑把周期调大。提示同一应用下多个任务对同一个变量做读写时应保证只有一个任务写、其他任务只读否则要加临界区保护。3. 从安装到第一个工程跑通软PLC的建工程流程和三大关键配置软PLC方案的优势是把运行时Runtime装在通用硬件上开发环境和目标系统分离。这本指导从安装要求开始讲说明它对“第一次接触软PLC的人”是有引导设计的。这里梳理一遍我每次建工程都会走的流程以及中间那些容易卡住的配置点。3.1 安装时就要想清楚的三个决定第一开发环境装在物理机还是虚拟机。装虚拟机能隔离复杂驱动环境但USB加密锁的透传、现场总线板卡驱动映射会在虚拟机里折腾你半天我一般建议主力开发机直接物理安装第二是否需要实时核授权如果只是做离线的逻辑仿真、熟悉语言语法用仿真模式跑就行但真机上线必须单独处理运行时授权这部分的激活路径在安装文档里写得很细照着做即可第三安装路径和版本不要混装多个大版本不同版本生成的工程文件格式有差异打开旧工程时如果提示工程版本过旧升版本前先备份。3.2 建工程的固定步骤设备、应用、任务、POU的顺序别乱很多人打开软件后习惯先去写ST代码写完了发现没有目标设备编译无误却无法登录。我的固定顺序是这样的先新建工程并添加标准设备然后添加应用再在应用下建任务最后才写POU。设备可以先选仿真器后面再切换真实控制器但任务一定要在建POU前配置好因为POU需要指定归属哪个任务。下面是用ST写第一个启停程序的完整过程假设你已经建好一个空白应用// 在应用 - POUs 下新建POU语言选ST // 变量声明区 VAR bStart : BOOL; // 启动按钮接到物理输入 bStop : BOOL; // 停止按钮 bRunning : BOOL; // 运行状态输出 nCount : INT; // 运行计数用来验证扫描周期 END_VAR // 逻辑主体 bRunning : (bStart OR bRunning) AND NOT bStop; IF bRunning THEN nCount : nCount 1; // 每次任务扫描加1 ELSE nCount : 0; // 停止时清零 END_IF这段代码的逻辑含义是用置位优先思想模拟传统启保停回路。bRunning的赋值表达式等价于“启动信号或保持状态且停止信号要断开”这是把梯形图回路翻译成ST的典型写法。nCount用来在线监视时验证任务确实在周期执行——如果你在程序里看不到它增长说明任务没跑起来。参数上BOOL是布尔开关INT是16位有符号整数计数到32767会溢出实际项目中计数多的话要用DINT。写完这段后编译通过就可以在线登录。登录成功后先看任务状态再看变量监视窗口手动置位bStart观察bRunning是否会自保持。这个简单的闭环验证能帮你确认为什么任务配置没问题、程序能跑。3.3 下载与启动分清“登录”“下载”“运行”三步在线操作里最容易翻车的是把“登录”和“下载”当成一回事。登录只是让你连上控制器的运行时下载才是把新编译的代码写到控制器里。如果控制器里已有运行程序下载会提示是否停止当前程序这时选择在线下载Online Change可以实现在不停机的情况下更新代码——这个功能是CoDeSys的强项但只支持变量增减和实现体修改不支持数据类型删除这类破坏性变更。如果改了结构体定义就不允许在线下载必须先停止再下载。现场维护时能把这一点用明白基本能省掉一半的停机时间。3.4 采样跟踪和配方管理器调试时别只盯着变量表变量监视窗口看的是瞬态值而采样跟踪Sampling Trace能记录一段时间内变量的变化曲线。这本书把采样跟踪列在应用对象里是因为它和示波器的作用类似尤其适合排查周期性波动问题比如PID输出是否振荡、编码器位置跳变发生在哪个时刻、任务切换时共享变量是否被异常改写。配方管理器Recipe Manager则是批量生产场景的利器。同一台设备要切换不同产品参数传统做法是一堆参数变量轮着写而配方管理器把一组变量快照绑定为一个配方切换时自动下载。我第一次用它是在某灌装设备的项目上三种规格的产品各对应一套灌装量、间隔时间、报警阈值原来要改几十个变量用配方后切换产品只需调一个索引。资料目录里这些内容都是连贯的顺着看完就能决定哪些功能能在你的场景里直接用。4. 五种语言与指令系统的配合ST写算法、LD画逻辑、SFC排流程这一章把五种语言放到一个模拟项目里实际跑一遍。模拟项目X是一个简单的三个工位分拣Demo传送带启动、气缸推料、计数到位、循环。这个小系统能覆盖位逻辑、定时器、计数器、互锁、顺序控制这几类最常见的PLC编程要素。4.1 ST写算法逻辑IF、CASE、FOR循环在控制系统里的用法ST和高级语言很接近控制算法、数据转换、数组运算这类活都适合它。看一个典型片段左侧是变址寻址右侧是条件分支// 采集8通道模拟量取其中最大的值 VAR arrAI : ARRAY[1..8] OF INT; // 8路模拟量采集值 nMaxVal : INT; // 最大值结果 i : INT; // 循环计数器 END_VAR nMaxVal : arrAI[1]; // 先把首通道赋给最大值 FOR i : 2 TO 8 DO IF arrAI[i] nMaxVal THEN nMaxVal : arrAI[i]; // 发现更大的就更新 END_IF END_FOR这里ARRAY[1..8] OF INT声明了8个16位整数下标从1开始——这一点和C语言从0开始不同刚从高级语言转过来的人经常在数组越界上栽跟头。FOR循环里每次把当前通道值和已存的最大值比较逻辑上没有难点重点在于这类算法代码必须放在一个确定周期的任务里如果在事件触发的任务里跑循环执行时长就无法预估看门狗容易超时。这也是ST和LD本质差异LD天然是周期扫描模型ST允许你写耗时逻辑但耗时不均匀也一样会拖垮实时性。4.2 LD和FBD画回路把电气逻辑翻译成图形语言梯形图最基本的单元是常开触点和线圈下面这一段等价于前面ST写的启保停| bStart bStop bRunning | |--| |------|/|-----------( )------| | bRunning | | |--| |--------------------| |第一行里bStart并联bRunning是自保持bStop用常闭触点实现停止断开bRunning线圈输出。之所以在ST和LD之间切换着用是因为电气背景的人看图能直接对应继电器控制图而写ST的人看这段可能需要换算一下。功能块图则把TON、CTU这类标准功能块拖出来连线重点理解“使能端”和“输出端”的数据流不需要研究电流方向。这本书讲了两种视角的转换关系用途是帮你统一团队里的维护习惯——有人习惯看图有人习惯看代码。我的习惯是安全联锁、急停回路一定用LD画成看得见的逻辑PID运算、通信解析则用ST封装成黑匣子调试时只关心输入输出不用钻进内部。4.3 SFC编排流程工序步进用状态机而不是一堆线圈SFC顺序功能图解决多步骤流程比LD或ST更优雅。看一个分拣Demo的SFC骨架初始化 - 待料(等待光电触发) - 推料(气缸伸出并计时) - 计数判断(是否达到批量) ^ | | v 未达批量回到待料步骤 达批量回初始化清空计数SFC每一步Step都有进入动作和退出动作步与步之间是转移条件Transition。用ST写转移条件时布尔表达式为真则自动跳转。相当于ST里的CASE step OF状态机写法但SFC是图形化的动作写在步里条件写在转移线上。实际项目中SFC最典型的问题是什么是漏写“初始化步的跳出条件”或者“并行分支的汇合条件”结果程序卡在某个步永远不往下走现场的现象就是设备动作到一半停住急停还没触发但程序也不报错。这种问题看变量监视是看不出来的必须切到SFC编辑器看当前活跃步的颜色标记一步一步追转移条件。4.4 定时器、计数器、边沿检测三条最少用的“元指令”所以执行时间的信息需要结合第七章的目标一个高水平的工程实施方案。定时器最常用的TON延时导通输入IN从False变True后PT指定的时间到了ET才累加到设定值Q才输出True。和它对称的是TOF延时断开。计数器的CTU是递增计数器CU引脚每个上升沿加1Q在CV大于等于PV时置位。边沿检测这两年的常见坑是R_TRIG的Q只保持一个扫描周期用它来计数或触发动作时如果目标POU的任务周期不一致边沿就会被漏掉。所以跨任务传信号时我建议直接传电平量而不是传边沿脉冲需要在接收端重建边沿。这些指令在职场的项目里天天都在用真正高频的反而是一个普通逻辑块。指导书用了整章的指令表来打底做新项目时不用到处翻手册相当于提供了一个离线的指令速查表。5. 常见问题排查变量、任务周期、通信配置的实际数据参考这一章汇集了我在CoDeSys项目里反复踩过的坑。每个都对应真实调试现场按“现象 → 原因 → 解决”的格式整理。这些点比较琐碎但值得放进工程笔记。5.1 在线修改变量时程序突然重启现象在线模式下用强制功能Force修改某个布尔量操作后控制器直接Stop程序重新启动生产流程中断。原因强制变量如果作用于一个正在被多个任务读写的全局变量可能导致一致性检查失败更常见的是你强制的变量被声明成了常量或输入映射CoDeSys不允许在线强制于是触发运行时保护。解决强制前先确认变量是普通VAR还是VAR_INPUTVAR_CONSTANT不能强制强制后不要跨任务持续刷新操作完尽快解除强制再观察变量值是否恢复正常。5.2 更新代码时提示“在线下载不支持”现象修改了某个结构体定义或删除了一个全局变量执行在线下载时直接弹窗报错。原因在线下载Online Change只支持兼容性变更新增变量、修改实现体这些可以做但数据类型定义被修改后应用的结构映像变了必须冷启动。解决在工程树里点开“应用”看变更类型如果是破坏性变更就不要硬点在线下载直接停止控制器后完整下载。如果停产窗口非常短你可以先把新逻辑放到新增POU里做成“增量变更”把破坏性变更留到下次检修窗口。从那以后我每次上线前都会检查一遍本次变更的类型清单提前分配好下载窗口。5.3 程序能编译但CPU负载异常高现象空跑时CPU负载正常一旦设备动作频繁任务执行时间曲线明显抬高控制周期不稳。原因某个POU里做了耗时操作比如在高速任务里处理字符串拼接、浮点开方运算或是大量的数组复制。ST写起来顺手但浮点数运算在某些平台上比整数运算慢几倍字符串处理更是吃内存。解决用采样跟踪功能打开任务执行时间曲线逐个POU加入耗时统计找出最耗时的部分把非实时数据加工搬到低速任务高速任务里只做必须实时的事。另一个办法是给耗时算法加缓存计算结果只有在输入变化时才重新计算。5.4 Modbus TCP通信偶尔断线重连现象设备长时间运行后某个从站的数据不再更新重新下载程序又恢复正常。原因TCP连接在异常断开后处于TIME_WAIT状态CoDeSys的Modbus TCP客户端功能块如果没做周期性的重连逻辑连接状态就卡在“建立中”或“断开”永远不会自动恢复。解决在通信管理功能块里加一个心跳变量每隔500ms读一次从站寄存器连续多次读不到就把通信功能块复位重连。另外检查网关设备的TCP保活时间比PLC的任务周期短一些确保链路层能及时发现断线。通信协议这类配置官方文档里有标准参数但“重连逻辑”必须自己写在应用层这是工业现场的基本素养。5.5 程序移植到另一个品牌控制器后模拟量地址错乱现象同一套应用代码换了一台控制器后模拟量通道读出来的数据对不上。原因设备树里的IO映射没有重新绑定应用层的变量绑定了旧的硬件地址新硬件的输入通道顺序不同自然数据错乱。解决移植时分两步走——第一步把应用剥离开来单独导入第二步在设备树里重新建立IO映射让应用层变量通过映射表指向新设备的通道。这正好体现了CoDeSys软件模型的价值变量名和物理地址解耦每次换硬件只动设备树那一层应用层不需要改逻辑。注意本节内容均基于通用CoDeSys开发环境不同硬件平台的内核实现存在差异遇到问题先以官方手册为准。6. 进阶把PLC程序做成产品6.1 第一步建立自己的功能块库项目做完不是终点把反复用的逻辑沉淀成库才是兑现CoDeSys价值的方式。我在每个项目里都把“气缸控制”“电机启停联锁”“Modbus读取块”写成通用功能块输入是按钮和传感器信号输出是执行器和状态字内部封装时序逻辑。新建库工程时勾选“库”类型做完后导出为.lib文件新项目引用它时自动带出版本管理。对功能块编码有一条规定要养成输入参数不带默认值或只在开发期带默认值运行时所有输入必须由调用者显式赋值输出不能依赖全局变量。坚持这个约定你的功能块在任何任务里都能实例化不担心数据串扰。6.2 第二步可视化界面和配方管理的配合CoDeSys自带可视化编辑器能画按钮、指示灯、数值显示、报警表格适合设备厂商做单机HMI。我习惯把可视化绑定到同一个应用这样变量名直接复用不需要像传统HMI那样另建通信变量表。配合配方管理器切换产品型号时可视化界面自动更新参数显示与报警上下限现场工人不需要碰代码。// 配方切换时报警上限跟随配方参数更新 CASE rcpCurrent.byProductCode OF 1: rRealAlarmHi : rcpProductA.rMaxTemp; 2: rRealAlarmHi : rcpProductB.rMaxTemp; END_CASE这段代码说明配方和报警参数的关系产品A和产品B各自有独立的上限值切换配方后上限制自动更新不会出现换产品忘改报警值的低级失误。rcpCurrent.byProductCode是当前配方的产品编号rRealAlarmHi是实际用于比较的报警上限。参数上配方数据结构里的rMaxTemp是REAL类型温度值带小数点用REAL存产品编码用BYTE够用且省内存。6.3 第三步远程监控与全局网络变量几乎所有设备都要求“能远程看状态”。CoDeSys里最简单的方案是用全局网络变量在应用里把需要监控的变量发布成网络变量另一台设备或上位机通过以太网订阅。这个机制不需要写TCP/IP原始报文配置好发布方和订阅方节点就自动同步。它的局限性在于实时性受网络延迟影响不适合做运动控制级同步但做设备状态采集、产量统计、报警上传完全够用。实际项目的经验是网络变量传递的数据要精简尽量传状态字和统计数据不要传每个扫描周期的实时模拟量订阅端不要直接拿网络变量做控制逻辑要经过本地缓存和心跳校验再用。把网络变量当“数据镜像”而不是“控制信号”通信故障时设备才能安全停机而不是误动作。6.4 一套适合复用的项目组织习惯每次做新设备我搭建的工程骨架基本是固定的设备树下保留总线配置和IO映射应用下分四个任务——安全逻辑任务周期5ms、主流程任务周期10ms、通信处理任务周期50ms、界面刷新任务周期100msPOU按功能分组命名每个设备单元一个文件夹。这个结构经历过多次现场验证是除了指令级细节外最能节约交接时间的地方。以前有个项目我图省事把所有逻辑塞进一个周期5ms的任务里连续多少个POU不加文件夹到了现场维护阶段查一个报警要从几十个POU里翻半天后悔药都来不及吃。从那以后我每次新建项目都强制走一遍“设备树映射—多任务分配—POU分组”的顺序新功能属于哪个周期、哪个文件夹在一开始就定死。这套习惯比任何指令技巧都能减少故障排查时间。希望这份对CoDeSys开发指导的拆解能帮到你至少少走几次弯路。本文还有配套的精品资源点击获取