1. 为什么要在树莓派上折腾CODESYS SoftMotion第一次跟身边做工控的朋友说我要拿树莓派跑CODESYS SoftMotion做多轴同步十个里有八个觉得我在开玩笑。在大多数人的印象里运动控制要么是专用控制器要么是工控机加运动控制卡树莓派这种几十块钱的小板子顶多跑跑Python脚本、点个灯、读个传感器。但实际用下来这套组合不仅能跑而且在两到四轴的同步场景里表现相当能打成本却只有传统方案的零头。先把话说清楚CODESYS SoftMotion是CODESYS平台上的软运动控制方案它把原本需要硬件运动控制卡完成的插补、凸轮、电子齿轮、多轴同步这些功能全部用软件在实时系统里实现。树莓派在这里扮演的角色是一台运行Linux的通用计算平台CODESYS Runtime以实时补丁的方式跑在上面SoftMotion作为其中的运动控制库提供轴管理和同步功能。两者结合就得到了一套低成本、可编程、支持IEC 61131-3标准的多轴运动控制平台。这套东西适合谁我总结下来是三类人。第一类是学生和爱好者做毕设或者个人项目预算有限但需要真正的多轴同步功能比如三轴直角坐标机器人、两轴涂胶平台、旋转刀库这类应用。第二类是做设备原型验证的工程师产品还没定型不想一上来就买几千块的专用控制器先用树莓派把控制逻辑和凸轮曲线跑通验证完再迁移到正式硬件。第三类是搞教学和培训的需要一套便宜、可复制、学生人手一套的运动控制实验平台。我这次做的项目是一个两轴同步的模拟应用主轴做旋转运动从轴通过凸轮表跟随主轴实现类似飞剪、追剪的同步动作。整个过程中我完整走了一遍从系统烧录、Runtime安装、轴配置、凸轮表建立到在线调试的流程中间踩了不少坑也积累了一些文档里不会写的经验。下面按实际操作的顺序把每个环节拆开讲。2. 系统选型与运行环境搭建2.1 树莓派型号与系统版本的选择逻辑树莓派型号这块我实测过3B、4B和5。结论很明确做SoftMotion多轴同步至少上4B推荐4B的4GB或8GB版本预算够直接上5。原因在于SoftMotion的插补运算和实时任务调度对CPU单核性能和内存都有要求3B的BCM2837在跑两轴以上同步时周期抖动明显偏大1ms的循环周期基本稳不住。4B的BCM2711单核性能提升明显跑两轴1ms周期比较稳四轴建议放宽到2ms。树莓派5的BCM2712又上了一个台阶四轴1ms周期也能扛住。系统版本我推荐Raspberry Pi OS Lite 64位基于Debian Bookworm也就是无桌面版本。原因有三点第一无桌面系统省掉了图形界面的CPU和内存开销实时性更好第二64位系统能用到更大的内存寻址空间CODESYS Runtime跑起来更从容第三Lite版本预装的软件少干扰实时任务的后台进程也少。如果你习惯用Ubuntu树莓派4B装Ubuntu 22.04 Server 64位也可以但要注意CODESYS官方对Debian系的适配更成熟Ubuntu上偶尔会遇到依赖库版本对不上的问题。烧录工具用官方的Raspberry Pi Imager就行烧录时在高级选项里提前配好WiFi、SSH和用户名密码省得第一次开机还要接显示器键盘。这里有个细节用户名不要用默认的piCODESYS Runtime安装时对某些保留用户名有要求用自定义用户名更省事。2.2 系统层面的实时性调优系统装好之后别急着装CODESYS先把实时性相关的系统配置做掉。这一步很多人会跳过结果后面调试时周期抖动大得没法用还以为是树莓派性能不行。第一件事是关闭CPU频率动态调节。树莓派默认会根据负载调频这对实时任务是致命的因为频率切换会带来不可预测的延迟。在/boot/firmware/config.txtBookworm版本路径老版本是/boot/config.txt里加上# 锁定CPU频率到最高 force_turbo1 # 或者用更温和的方式 # arm_freq1800 # arm_freq_min1800force_turbo1会把频率锁死在最高代价是功耗和发热上升需要配好散热。如果不想这么激进用arm_freq和arm_freq_min设成同一个值也能达到锁频效果。第二件事是隔离一个CPU核心给实时任务。树莓派4B和5都是四核可以把CPU 3隔离出来专门跑CODESYS的实时任务其他核心处理系统杂务。在/boot/firmware/cmdline.txt里追加isolcpus3 nohz_full3 rcu_nocbs3这三个参数的作用分别是把CPU 3从调度器里隔离出来、让CPU 3进入无滴答模式减少中断、把RCU回调从CPU 3上移走。改完重启生效。第三件事是关闭不必要的中断和后台服务。蓝牙、音频、串口控制台这些如果不用都在config.txt里关掉# 关闭蓝牙 dtoverlaydisable-bt # 关闭音频 dtparamaudiooff # 关闭串口控制台如果要用串口做别的 # enable_uart1系统服务方面systemctl disable掉bluetooth、avahi-daemon、cups这些用不到的。别小看这些我实测关掉之后1ms周期的抖动从±80微秒降到了±30微秒左右。2.3 CODESYS Runtime的安装与授权CODESYS Runtime for Raspberry Pi SLSoftMotion版本需要从CODESYS官网下载。注意要选SLSoftMotion Light或者完整SoftMotion版本普通版本不带运动控制功能。下载下来是一个.deb包通过SCP传到树莓派上用dpkg -i安装。安装过程中会提示设置Runtime的用户名和密码这个跟系统用户是分开的记好。安装完成后Runtime会作为系统服务自动启动默认监听端口是1217CODESYS网关端口。授权这块要说清楚CODESYS Runtime在树莓派上免费运行但有2小时的运行限制超过2小时会停止需要重启服务。对于学习和原型验证2小时够用了重启一下继续。如果要长时间运行需要购买授权License通过CODESYS的License Manager导入。我个人的做法是原型阶段用免费版验证通过后再考虑授权。安装完成后在开发电脑上打开CODESYS Development System V3.5 SP17以上版本通过“设备”菜单扫描网络应该能找到树莓派上的Runtime。第一次连接会提示下载Runtime的符号信息等它下载完就能开始配置了。3. SoftMotion多轴同步的核心配置3.1 设备树与轴对象的建立连上Runtime之后第一件事是在设备树里添加SoftMotion相关的设备。右键Device选择“添加设备”在运动控制分类下找到SoftMotion General Axis Pool添加进来。这个池子是用来管理所有软轴的容器后面建立的每个轴都挂在这下面。然后在Axis Pool下添加轴对象。每个轴对应一个SoftMotion Drive我这次做两轴同步就加两个。每个轴需要配置几个关键参数轴类型选“虚拟轴”还是“真实轴”。虚拟轴是纯软件模拟的不输出实际信号适合先验证逻辑真实轴需要绑定到具体的驱动接口。我建议先用虚拟轴把凸轮逻辑跑通再换成真实轴。单位换算这里要填“增量/单位”和“单位/增量”的换算关系。比如你的编码器是2500线四倍频后是10000个增量对应一圈那增量/单位就是10000。这个参数填错后面凸轮表的数值全乱。速度、加速度、减速度限制按实际机械能力填虚拟轴可以填大一点方便调试。软件限位建议开启防止调试时轴跑飞。这里有个容易踩的坑轴的编号和名称要规划好。CODESYS里轴是用实例名引用的比如Axis_Master和Axis_Slave后面写程序时全靠这个名字。命名混乱的话程序写到一半自己都分不清哪个是哪个。3.2 凸轮表的建立与参数计算凸轮表Cam Table是这次项目的核心。所谓凸轮就是描述主轴位置和从轴位置之间映射关系的一张表。主轴转一圈从轴按照表里的曲线走一个特定的位移规律这就是电子凸轮。CODESYS里建立凸轮表有两种方式在SoftMotion Cam编辑器里手动画点或者用程序动态生成。我这次用的是编辑器画点的方式因为曲线固定画一次就行。具体操作在设备树里右键添加“Cam”对象打开Cam编辑器。编辑器里横轴是主轴位置0到360度或者0到主轴一圈的增量数纵轴是从轴位置。我这次做的是一条“静止-加速-匀速-减速-静止”的追剪曲线主轴转一圈从轴走一个来回。画点的时候要注意几个原则。第一首尾点必须闭合也就是主轴0度和360度对应的从轴位置要相同否则每转一圈从轴会累积偏移。第二曲线的斜率要连续斜率突变意味着速度突变机械上会有冲击。编辑器里可以设置每个点的斜率或者用样条插值自动平滑。第三关键点要加密尤其是加减速段点太稀的话插补出来的曲线和预期差很多。凸轮表建好之后会生成一个.cam文件在程序里通过MC_CamIn功能块引用。这里要填的参数包括参数说明我的取值CamTable凸轮表引用Cam_Table_1Master主轴实例Axis_MasterSlave从轴实例Axis_SlaveMasterOffset主轴起始偏移0SlaveOffset从轴起始偏移0MasterScaling主轴缩放1.0SlaveScaling从轴缩放1.0StartMode启动模式absoluteCamInMode切入模式按主轴位置切入MasterScaling和SlaveScaling这两个参数很关键它们决定了凸轮表的实际映射比例。比如你的凸轮表是按主轴一圈360度画的但实际主轴一圈是10000个增量那MasterScaling就要设成10000/360让表里的度数对应到实际增量。这个换算我一开始没搞明白从轴走出来的位置差了十万八千里后来对着手册算了半天才对上。3.3 多轴同步的程序框架程序部分用ST语言写结构上分三层状态机层、运动控制层、监控层。状态机层负责管理整个同步流程的状态切换空闲、使能、回零、同步切入、同步运行、同步切出、停止。每个状态之间的切换条件要写清楚尤其是异常情况的处理比如同步过程中主轴停了怎么办、从轴跟丢了怎么办。运动控制层就是调用SoftMotion的功能块。核心的几个MC_Power(Axis : Axis_Master, Enable : TRUE, ...); MC_Power(Axis : Axis_Slave, Enable : TRUE, ...); MC_Home(Axis : Axis_Master, ...); MC_Home(Axis : Axis_Slave, ...); MC_CamIn(Master : Axis_Master, Slave : Axis_Slave, CamTable : Cam_Table_1, ...); MC_CamOut(Slave : Axis_Slave, ...);MC_CamIn是切入同步调用之后从轴会按照凸轮表跟随主轴。MC_CamOut是切出从轴脱离同步关系。这两个功能块的执行时机很讲究切入时主轴和从轴的位置关系必须和凸轮表对得上否则会有跳变。我的做法是切入前先把从轴手动走到凸轮表起始点对应的位置再调用MC_CamIn这样切入瞬间没有冲击。监控层就是读轴的状态、位置、速度显示在HMI或者记录到日志里。调试阶段我建议把主轴位置、从轴位置、跟随误差这三个量实时记录下来后面分析问题全靠它。4. 在线调试与凸轮曲线优化实录4.1 在线调试环境的搭建CODESYS的在线调试功能是这套方案的一大优势。开发电脑和树莓派在同一个网络里直接在IDE里就能看到所有变量的实时值、修改参数、强制IO不用额外的调试工具。调试前先确认几件事树莓派的Runtime服务在跑网络通畅防火墙没挡1217端口。然后在CODESYS里点“登录”会提示下载程序到Runtime。下载完成后点“运行”程序就跑起来了。在线调试时我常用的几个功能Watch窗口把关键变量拖进去实时看值。我一般看主轴位置、从轴位置、跟随误差、状态机当前状态。Trace功能这是SoftMotion调试的利器。可以配置采样周期我设的1ms把主轴位置、从轴位置、凸轮表理论位置、跟随误差这几个信号录下来跑一段时间后停止看波形。凸轮曲线对不对、同步精度够不够看Trace一目了然。在线修改调试时经常要改参数比如加速度、缩放系数。CODESYS支持在线修改改完立即生效不用重新下载。但要注意有些参数改了会触发轴重新初始化改之前先让轴停下来。Trace的配置有个细节采样周期要和任务周期匹配。我的运动任务周期是1msTrace采样也设1ms这样每个周期都能采到。如果Trace采样比任务周期慢会漏掉中间的数据分析时容易误判。4.2 凸轮同步精度的实测与调优第一次跑起来Trace一看跟随误差在加减速段有将近200个增量远超预期。分析下来有几个原因。第一个原因是凸轮表的点太稀。我一开始只画了7个关键点加减速段只有两三个点样条插值出来的曲线和理论曲线偏差大。后来把点加密到20多个加减速段每10度一个点误差降到了50个增量以内。第二个原因是主轴和从轴的动态响应不匹配。主轴是虚拟轴响应是理想的从轴如果绑定了真实驱动有惯量和延迟跟随就会滞后。解决办法是在凸轮表里给从轴加一点“超前”或者降低主轴的加速度让从轴跟得上。我这次用的是双虚拟轴所以这个问题不明显但换成真实轴一定要考虑。第三个原因是任务周期和插补周期的关系。SoftMotion的插补是在任务周期里算的任务周期1ms意味着每1ms算一次轴的位置。如果凸轮曲线的变化率很大比如高速段1ms的插补间隔会导致明显的台阶。把任务周期降到0.5ms误差又降了一截。但周期越短CPU负载越高要在精度和负载之间找平衡。调优之后最终实测的跟随误差在加减速段控制在30个增量以内匀速段在10个增量以内。对于我做的这个模拟应用这个精度完全够用。4.3 常见问题与排查速查表调试过程中遇到的问题不少我整理成一张表方便对照排查。现象可能原因排查方法解决措施从轴不动MC_Power没使能看Axis.Status的State位确认Enable信号为TRUE从轴位置乱跳单位换算错误检查增量/单位参数按编码器实际线数重算同步切入时有冲击切入位置和凸轮表不匹配Trace看切入瞬间的位置差切入前先走到表起始点跟随误差大凸轮表点太稀加密关键点加减速段每10度一个点周期抖动大系统实时性没调好看任务周期的实际抖动锁频、隔离核心、关服务Runtime跑2小时停了免费版限制看Runtime日志重启服务或购买授权在线修改参数后轴异常参数触发重新初始化看轴状态先停轴再改参数Trace波形和预期不符采样周期不匹配检查Trace配置采样周期设为任务周期这张表里的每一条都是我实际踩过的尤其是“单位换算错误”和“切入位置不匹配”这两个新手几乎必踩。单位换算那个我折腾了大半天最后发现是编码器线数记错了四倍频没算进去。5. 性能边界与扩展方向5.1 树莓派跑SoftMotion的性能天花板实测下来树莓派4B跑两轴1ms周期CPU占用在40%左右跑四轴1ms周期会到70%以上偶尔有超时。树莓派5跑四轴1ms周期在50%左右比较从容。如果轴数更多或者周期更短就要考虑降低周期要求或者换更强的硬件。影响性能的主要因素有三个轴数、任务周期、凸轮表复杂度。轴数越多每个周期的插补计算量越大周期越短单位时间内的计算次数越多凸轮表越复杂点越多、插值越密单次插补的计算量越大。这三个因素是乘性关系不是加性关系所以配置时要留足余量。我的建议是树莓派4B做两轴同步周期1ms做四轴同步周期2ms。树莓派5做四轴同步周期1ms做六轴以上周期2ms。这个配置下系统比较稳不会因为偶尔的负载峰值导致周期超时。5.2 从虚拟轴到真实轴的迁移要点虚拟轴验证通过后换成真实轴要注意几点。第一驱动接口的配置。CODESYS支持多种驱动接口树莓派上常用的是通过GPIO或者SPI输出脉冲方向信号或者通过EtherCAT接伺服驱动。脉冲方向方式简单但精度有限EtherCAT方式性能好但需要额外的从站硬件。第二编码器反馈的处理。真实轴需要编码器反馈位置树莓派上可以通过GPIO读增量编码器或者通过EtherCAT读伺服编码器。编码器的信号质量直接影响同步精度接线要注意屏蔽和滤波。第三安全逻辑的补充。虚拟轴跑飞了无所谓真实轴跑飞了可能撞机。限位开关、急停、软限位这些安全逻辑在真实轴上是必须的而且要在SoftMotion的功能块之外单独做一层确保即使运动控制层出问题安全层也能把轴停下来。5.3 这套方案的适用场景与局限这套方案最适合的场景是中小型设备的原型验证和教学实验。成本低、灵活、可编程验证控制逻辑和运动曲线非常方便。我认识几个做非标设备的工程师都是先用树莓派加CODESYS把方案跑通客户确认后再换成正式控制器省了不少前期投入。局限也很明显。第一实时性不如专用硬件。树莓派毕竟是通用计算平台实时性靠软件补丁实现抖动比专用运动控制器大。对同步精度要求极高的场景比如高速飞剪、精密加工这套方案可能不够。第二可靠性和工业防护不足。树莓派不是工业级硬件工作温度范围、抗干扰能力、长期稳定性都和工控机有差距。第三授权成本。免费版有2小时限制正式使用需要购买授权虽然比专用控制器便宜但也不是零成本。我的看法是这套方案的价值在于降低运动控制的学习门槛和原型验证成本。用它来学凸轮、学同步、学IEC 61131-3编程性价比极高。用它来做正式产品要看具体场景的精度和可靠性要求不能一概而论。最后分享一个我在调试凸轮曲线时的小技巧先用Excel或者Python把凸轮曲线的理论值算出来再和Trace录到的实际值对比。CODESYS的Cam编辑器画曲线是黑盒你不知道它插值出来到底是什么样。自己算一遍心里有底调起来也快。我这次就是用Python按同样的插值算法算了一遍理论曲线和Trace一对比立刻定位到是凸轮表点太稀的问题。这个习惯帮我省了很多瞎试的时间。
树莓派跑CODESYS SoftMotion：低成本多轴同步实战
1. 为什么要在树莓派上折腾CODESYS SoftMotion第一次跟身边做工控的朋友说我要拿树莓派跑CODESYS SoftMotion做多轴同步十个里有八个觉得我在开玩笑。在大多数人的印象里运动控制要么是专用控制器要么是工控机加运动控制卡树莓派这种几十块钱的小板子顶多跑跑Python脚本、点个灯、读个传感器。但实际用下来这套组合不仅能跑而且在两到四轴的同步场景里表现相当能打成本却只有传统方案的零头。先把话说清楚CODESYS SoftMotion是CODESYS平台上的软运动控制方案它把原本需要硬件运动控制卡完成的插补、凸轮、电子齿轮、多轴同步这些功能全部用软件在实时系统里实现。树莓派在这里扮演的角色是一台运行Linux的通用计算平台CODESYS Runtime以实时补丁的方式跑在上面SoftMotion作为其中的运动控制库提供轴管理和同步功能。两者结合就得到了一套低成本、可编程、支持IEC 61131-3标准的多轴运动控制平台。这套东西适合谁我总结下来是三类人。第一类是学生和爱好者做毕设或者个人项目预算有限但需要真正的多轴同步功能比如三轴直角坐标机器人、两轴涂胶平台、旋转刀库这类应用。第二类是做设备原型验证的工程师产品还没定型不想一上来就买几千块的专用控制器先用树莓派把控制逻辑和凸轮曲线跑通验证完再迁移到正式硬件。第三类是搞教学和培训的需要一套便宜、可复制、学生人手一套的运动控制实验平台。我这次做的项目是一个两轴同步的模拟应用主轴做旋转运动从轴通过凸轮表跟随主轴实现类似飞剪、追剪的同步动作。整个过程中我完整走了一遍从系统烧录、Runtime安装、轴配置、凸轮表建立到在线调试的流程中间踩了不少坑也积累了一些文档里不会写的经验。下面按实际操作的顺序把每个环节拆开讲。2. 系统选型与运行环境搭建2.1 树莓派型号与系统版本的选择逻辑树莓派型号这块我实测过3B、4B和5。结论很明确做SoftMotion多轴同步至少上4B推荐4B的4GB或8GB版本预算够直接上5。原因在于SoftMotion的插补运算和实时任务调度对CPU单核性能和内存都有要求3B的BCM2837在跑两轴以上同步时周期抖动明显偏大1ms的循环周期基本稳不住。4B的BCM2711单核性能提升明显跑两轴1ms周期比较稳四轴建议放宽到2ms。树莓派5的BCM2712又上了一个台阶四轴1ms周期也能扛住。系统版本我推荐Raspberry Pi OS Lite 64位基于Debian Bookworm也就是无桌面版本。原因有三点第一无桌面系统省掉了图形界面的CPU和内存开销实时性更好第二64位系统能用到更大的内存寻址空间CODESYS Runtime跑起来更从容第三Lite版本预装的软件少干扰实时任务的后台进程也少。如果你习惯用Ubuntu树莓派4B装Ubuntu 22.04 Server 64位也可以但要注意CODESYS官方对Debian系的适配更成熟Ubuntu上偶尔会遇到依赖库版本对不上的问题。烧录工具用官方的Raspberry Pi Imager就行烧录时在高级选项里提前配好WiFi、SSH和用户名密码省得第一次开机还要接显示器键盘。这里有个细节用户名不要用默认的piCODESYS Runtime安装时对某些保留用户名有要求用自定义用户名更省事。2.2 系统层面的实时性调优系统装好之后别急着装CODESYS先把实时性相关的系统配置做掉。这一步很多人会跳过结果后面调试时周期抖动大得没法用还以为是树莓派性能不行。第一件事是关闭CPU频率动态调节。树莓派默认会根据负载调频这对实时任务是致命的因为频率切换会带来不可预测的延迟。在/boot/firmware/config.txtBookworm版本路径老版本是/boot/config.txt里加上# 锁定CPU频率到最高 force_turbo1 # 或者用更温和的方式 # arm_freq1800 # arm_freq_min1800force_turbo1会把频率锁死在最高代价是功耗和发热上升需要配好散热。如果不想这么激进用arm_freq和arm_freq_min设成同一个值也能达到锁频效果。第二件事是隔离一个CPU核心给实时任务。树莓派4B和5都是四核可以把CPU 3隔离出来专门跑CODESYS的实时任务其他核心处理系统杂务。在/boot/firmware/cmdline.txt里追加isolcpus3 nohz_full3 rcu_nocbs3这三个参数的作用分别是把CPU 3从调度器里隔离出来、让CPU 3进入无滴答模式减少中断、把RCU回调从CPU 3上移走。改完重启生效。第三件事是关闭不必要的中断和后台服务。蓝牙、音频、串口控制台这些如果不用都在config.txt里关掉# 关闭蓝牙 dtoverlaydisable-bt # 关闭音频 dtparamaudiooff # 关闭串口控制台如果要用串口做别的 # enable_uart1系统服务方面systemctl disable掉bluetooth、avahi-daemon、cups这些用不到的。别小看这些我实测关掉之后1ms周期的抖动从±80微秒降到了±30微秒左右。2.3 CODESYS Runtime的安装与授权CODESYS Runtime for Raspberry Pi SLSoftMotion版本需要从CODESYS官网下载。注意要选SLSoftMotion Light或者完整SoftMotion版本普通版本不带运动控制功能。下载下来是一个.deb包通过SCP传到树莓派上用dpkg -i安装。安装过程中会提示设置Runtime的用户名和密码这个跟系统用户是分开的记好。安装完成后Runtime会作为系统服务自动启动默认监听端口是1217CODESYS网关端口。授权这块要说清楚CODESYS Runtime在树莓派上免费运行但有2小时的运行限制超过2小时会停止需要重启服务。对于学习和原型验证2小时够用了重启一下继续。如果要长时间运行需要购买授权License通过CODESYS的License Manager导入。我个人的做法是原型阶段用免费版验证通过后再考虑授权。安装完成后在开发电脑上打开CODESYS Development System V3.5 SP17以上版本通过“设备”菜单扫描网络应该能找到树莓派上的Runtime。第一次连接会提示下载Runtime的符号信息等它下载完就能开始配置了。3. SoftMotion多轴同步的核心配置3.1 设备树与轴对象的建立连上Runtime之后第一件事是在设备树里添加SoftMotion相关的设备。右键Device选择“添加设备”在运动控制分类下找到SoftMotion General Axis Pool添加进来。这个池子是用来管理所有软轴的容器后面建立的每个轴都挂在这下面。然后在Axis Pool下添加轴对象。每个轴对应一个SoftMotion Drive我这次做两轴同步就加两个。每个轴需要配置几个关键参数轴类型选“虚拟轴”还是“真实轴”。虚拟轴是纯软件模拟的不输出实际信号适合先验证逻辑真实轴需要绑定到具体的驱动接口。我建议先用虚拟轴把凸轮逻辑跑通再换成真实轴。单位换算这里要填“增量/单位”和“单位/增量”的换算关系。比如你的编码器是2500线四倍频后是10000个增量对应一圈那增量/单位就是10000。这个参数填错后面凸轮表的数值全乱。速度、加速度、减速度限制按实际机械能力填虚拟轴可以填大一点方便调试。软件限位建议开启防止调试时轴跑飞。这里有个容易踩的坑轴的编号和名称要规划好。CODESYS里轴是用实例名引用的比如Axis_Master和Axis_Slave后面写程序时全靠这个名字。命名混乱的话程序写到一半自己都分不清哪个是哪个。3.2 凸轮表的建立与参数计算凸轮表Cam Table是这次项目的核心。所谓凸轮就是描述主轴位置和从轴位置之间映射关系的一张表。主轴转一圈从轴按照表里的曲线走一个特定的位移规律这就是电子凸轮。CODESYS里建立凸轮表有两种方式在SoftMotion Cam编辑器里手动画点或者用程序动态生成。我这次用的是编辑器画点的方式因为曲线固定画一次就行。具体操作在设备树里右键添加“Cam”对象打开Cam编辑器。编辑器里横轴是主轴位置0到360度或者0到主轴一圈的增量数纵轴是从轴位置。我这次做的是一条“静止-加速-匀速-减速-静止”的追剪曲线主轴转一圈从轴走一个来回。画点的时候要注意几个原则。第一首尾点必须闭合也就是主轴0度和360度对应的从轴位置要相同否则每转一圈从轴会累积偏移。第二曲线的斜率要连续斜率突变意味着速度突变机械上会有冲击。编辑器里可以设置每个点的斜率或者用样条插值自动平滑。第三关键点要加密尤其是加减速段点太稀的话插补出来的曲线和预期差很多。凸轮表建好之后会生成一个.cam文件在程序里通过MC_CamIn功能块引用。这里要填的参数包括参数说明我的取值CamTable凸轮表引用Cam_Table_1Master主轴实例Axis_MasterSlave从轴实例Axis_SlaveMasterOffset主轴起始偏移0SlaveOffset从轴起始偏移0MasterScaling主轴缩放1.0SlaveScaling从轴缩放1.0StartMode启动模式absoluteCamInMode切入模式按主轴位置切入MasterScaling和SlaveScaling这两个参数很关键它们决定了凸轮表的实际映射比例。比如你的凸轮表是按主轴一圈360度画的但实际主轴一圈是10000个增量那MasterScaling就要设成10000/360让表里的度数对应到实际增量。这个换算我一开始没搞明白从轴走出来的位置差了十万八千里后来对着手册算了半天才对上。3.3 多轴同步的程序框架程序部分用ST语言写结构上分三层状态机层、运动控制层、监控层。状态机层负责管理整个同步流程的状态切换空闲、使能、回零、同步切入、同步运行、同步切出、停止。每个状态之间的切换条件要写清楚尤其是异常情况的处理比如同步过程中主轴停了怎么办、从轴跟丢了怎么办。运动控制层就是调用SoftMotion的功能块。核心的几个MC_Power(Axis : Axis_Master, Enable : TRUE, ...); MC_Power(Axis : Axis_Slave, Enable : TRUE, ...); MC_Home(Axis : Axis_Master, ...); MC_Home(Axis : Axis_Slave, ...); MC_CamIn(Master : Axis_Master, Slave : Axis_Slave, CamTable : Cam_Table_1, ...); MC_CamOut(Slave : Axis_Slave, ...);MC_CamIn是切入同步调用之后从轴会按照凸轮表跟随主轴。MC_CamOut是切出从轴脱离同步关系。这两个功能块的执行时机很讲究切入时主轴和从轴的位置关系必须和凸轮表对得上否则会有跳变。我的做法是切入前先把从轴手动走到凸轮表起始点对应的位置再调用MC_CamIn这样切入瞬间没有冲击。监控层就是读轴的状态、位置、速度显示在HMI或者记录到日志里。调试阶段我建议把主轴位置、从轴位置、跟随误差这三个量实时记录下来后面分析问题全靠它。4. 在线调试与凸轮曲线优化实录4.1 在线调试环境的搭建CODESYS的在线调试功能是这套方案的一大优势。开发电脑和树莓派在同一个网络里直接在IDE里就能看到所有变量的实时值、修改参数、强制IO不用额外的调试工具。调试前先确认几件事树莓派的Runtime服务在跑网络通畅防火墙没挡1217端口。然后在CODESYS里点“登录”会提示下载程序到Runtime。下载完成后点“运行”程序就跑起来了。在线调试时我常用的几个功能Watch窗口把关键变量拖进去实时看值。我一般看主轴位置、从轴位置、跟随误差、状态机当前状态。Trace功能这是SoftMotion调试的利器。可以配置采样周期我设的1ms把主轴位置、从轴位置、凸轮表理论位置、跟随误差这几个信号录下来跑一段时间后停止看波形。凸轮曲线对不对、同步精度够不够看Trace一目了然。在线修改调试时经常要改参数比如加速度、缩放系数。CODESYS支持在线修改改完立即生效不用重新下载。但要注意有些参数改了会触发轴重新初始化改之前先让轴停下来。Trace的配置有个细节采样周期要和任务周期匹配。我的运动任务周期是1msTrace采样也设1ms这样每个周期都能采到。如果Trace采样比任务周期慢会漏掉中间的数据分析时容易误判。4.2 凸轮同步精度的实测与调优第一次跑起来Trace一看跟随误差在加减速段有将近200个增量远超预期。分析下来有几个原因。第一个原因是凸轮表的点太稀。我一开始只画了7个关键点加减速段只有两三个点样条插值出来的曲线和理论曲线偏差大。后来把点加密到20多个加减速段每10度一个点误差降到了50个增量以内。第二个原因是主轴和从轴的动态响应不匹配。主轴是虚拟轴响应是理想的从轴如果绑定了真实驱动有惯量和延迟跟随就会滞后。解决办法是在凸轮表里给从轴加一点“超前”或者降低主轴的加速度让从轴跟得上。我这次用的是双虚拟轴所以这个问题不明显但换成真实轴一定要考虑。第三个原因是任务周期和插补周期的关系。SoftMotion的插补是在任务周期里算的任务周期1ms意味着每1ms算一次轴的位置。如果凸轮曲线的变化率很大比如高速段1ms的插补间隔会导致明显的台阶。把任务周期降到0.5ms误差又降了一截。但周期越短CPU负载越高要在精度和负载之间找平衡。调优之后最终实测的跟随误差在加减速段控制在30个增量以内匀速段在10个增量以内。对于我做的这个模拟应用这个精度完全够用。4.3 常见问题与排查速查表调试过程中遇到的问题不少我整理成一张表方便对照排查。现象可能原因排查方法解决措施从轴不动MC_Power没使能看Axis.Status的State位确认Enable信号为TRUE从轴位置乱跳单位换算错误检查增量/单位参数按编码器实际线数重算同步切入时有冲击切入位置和凸轮表不匹配Trace看切入瞬间的位置差切入前先走到表起始点跟随误差大凸轮表点太稀加密关键点加减速段每10度一个点周期抖动大系统实时性没调好看任务周期的实际抖动锁频、隔离核心、关服务Runtime跑2小时停了免费版限制看Runtime日志重启服务或购买授权在线修改参数后轴异常参数触发重新初始化看轴状态先停轴再改参数Trace波形和预期不符采样周期不匹配检查Trace配置采样周期设为任务周期这张表里的每一条都是我实际踩过的尤其是“单位换算错误”和“切入位置不匹配”这两个新手几乎必踩。单位换算那个我折腾了大半天最后发现是编码器线数记错了四倍频没算进去。5. 性能边界与扩展方向5.1 树莓派跑SoftMotion的性能天花板实测下来树莓派4B跑两轴1ms周期CPU占用在40%左右跑四轴1ms周期会到70%以上偶尔有超时。树莓派5跑四轴1ms周期在50%左右比较从容。如果轴数更多或者周期更短就要考虑降低周期要求或者换更强的硬件。影响性能的主要因素有三个轴数、任务周期、凸轮表复杂度。轴数越多每个周期的插补计算量越大周期越短单位时间内的计算次数越多凸轮表越复杂点越多、插值越密单次插补的计算量越大。这三个因素是乘性关系不是加性关系所以配置时要留足余量。我的建议是树莓派4B做两轴同步周期1ms做四轴同步周期2ms。树莓派5做四轴同步周期1ms做六轴以上周期2ms。这个配置下系统比较稳不会因为偶尔的负载峰值导致周期超时。5.2 从虚拟轴到真实轴的迁移要点虚拟轴验证通过后换成真实轴要注意几点。第一驱动接口的配置。CODESYS支持多种驱动接口树莓派上常用的是通过GPIO或者SPI输出脉冲方向信号或者通过EtherCAT接伺服驱动。脉冲方向方式简单但精度有限EtherCAT方式性能好但需要额外的从站硬件。第二编码器反馈的处理。真实轴需要编码器反馈位置树莓派上可以通过GPIO读增量编码器或者通过EtherCAT读伺服编码器。编码器的信号质量直接影响同步精度接线要注意屏蔽和滤波。第三安全逻辑的补充。虚拟轴跑飞了无所谓真实轴跑飞了可能撞机。限位开关、急停、软限位这些安全逻辑在真实轴上是必须的而且要在SoftMotion的功能块之外单独做一层确保即使运动控制层出问题安全层也能把轴停下来。5.3 这套方案的适用场景与局限这套方案最适合的场景是中小型设备的原型验证和教学实验。成本低、灵活、可编程验证控制逻辑和运动曲线非常方便。我认识几个做非标设备的工程师都是先用树莓派加CODESYS把方案跑通客户确认后再换成正式控制器省了不少前期投入。局限也很明显。第一实时性不如专用硬件。树莓派毕竟是通用计算平台实时性靠软件补丁实现抖动比专用运动控制器大。对同步精度要求极高的场景比如高速飞剪、精密加工这套方案可能不够。第二可靠性和工业防护不足。树莓派不是工业级硬件工作温度范围、抗干扰能力、长期稳定性都和工控机有差距。第三授权成本。免费版有2小时限制正式使用需要购买授权虽然比专用控制器便宜但也不是零成本。我的看法是这套方案的价值在于降低运动控制的学习门槛和原型验证成本。用它来学凸轮、学同步、学IEC 61131-3编程性价比极高。用它来做正式产品要看具体场景的精度和可靠性要求不能一概而论。最后分享一个我在调试凸轮曲线时的小技巧先用Excel或者Python把凸轮曲线的理论值算出来再和Trace录到的实际值对比。CODESYS的Cam编辑器画曲线是黑盒你不知道它插值出来到底是什么样。自己算一遍心里有底调起来也快。我这次就是用Python按同样的插值算法算了一遍理论曲线和Trace一对比立刻定位到是凸轮表点太稀的问题。这个习惯帮我省了很多瞎试的时间。
