
1. 为什么凸轮同步绕不开MC_CamIn做自动化设备这些年只要涉及到飞剪、追剪、横切、贴标、模切、印刷套准这一类工艺基本都会碰到一个问题从动轴怎么跟着主轴走而且还要求位置关系严格不丢步。早期用普通PLC做通常是靠中断高速计数器硬凑程序写得又长又绕换一个产品规格就要重新调一大堆参数调试起来相当折磨人。Omron NJ/NX系列出来之后运动控制这块确实省心了不少。它把电子凸轮同步直接做成了标准指令——MC_CamIn配合Sysmac Studio的凸轮编辑器不用再用梯形图手算凸轮曲线。而且它底层的同步控制是由NJ的内置运动控制内核直接跑的不占用用户程序的扫描周期响应一致性比用中断去拼的方案高好几个量级。我最早接触NJ的时候也走过弯路光一个MC_CamIn的启动条件就折腾了两天。后来把凸轮表的数据格式、主轴从轴的配置关系、指令的时序要求全捋清楚之后才发现这东西只要理解了对用起来其实非常顺手。这篇就把我从凸轮表配置到同步控制落地全流程的实操经验写出来尤其是那些说明书上没写透、容易踩的坑能帮一个是一个。2. 动手前必须先想清楚的整体方案2.1 先搞清楚你的工艺到底需要哪种同步很多人上来就打开Sysmac Studio找凸轮表但第一步其实不该是配表而是先想清楚工艺模型。同样是“同步”实际场景差别很大定比例同步比如两根辊子靠齿轮比保持固定速比主轴转多少圈从轴跟着转对应圈数。这种用电子齿轮MC_GearIn就够了上凸轮反而浪费。变速比同步比如飞剪主轴匀速转从轴要在剪切点追上物料速度切完再快速返回一个周期内速比是变化的这种必须用凸轮。补偿式同步比如套准修正主轴和从轴基准速比固定但需要周期性地叠加一个修正量。这种可以凸轮打底再叠MC_MoveSuperimposed补偿也可以直接用凸轮表做相位偏置。确认清楚需求之后再决定用MC_CamIn还是混合方案。这里我个人的经验是能用凸轮表表达的运动关系别去用逻辑硬凑。因为凸轮表一旦建好改动一个表的数值就能全局生效比在程序里改几十个加减速参数可靠多了。2.2 轴配置阶段就要定下的关键参数NJ/NX的凸轮同步主轴和从轴都必须先在Sysmac Studio的轴设置里配好。注意几个直接影响后期调试的参数单位换算主从轴的运动单位要统一。比如主轴是编码器反馈的虚拟主轴单位是脉冲从轴是伺服轴单位是mm那凸轮表的主轴位置单位就必须和主轴设置一致从轴位置单位和从轴设置一致。混了单位MC_CamIn一启动就是位置跳变。旋转轴还是直线轴凸轮表中如果是连续循环工况主轴建议配成旋转轴周期就是360度或一圈对应的用户单位。从轴如果也是连续旋转同样配成旋转轴避免累积误差。加减速能力从轴伺服的最大扭矩、加减速时间常数决定了凸轮表曲线能不能实际跑出来。凸轮表最陡的斜率对应从轴最高速度最陡的斜率变化对应最大加速度配表之前先用运动控制器的凸轮编辑器看下速度、加速度曲线确认没超限再下载到PLC。2.3 虚拟主轴还是实际主轴这个选择影响很大。如果现场本身有实际机械主轴比如印刷机的主传动轴那主轴直接用编码器输入到NJ/NX的高速计数器或EtherCAT从站MC_CamIn挂成实轴即可。但很多设备主轴并不存在实体比如飞剪里主轴的“相位”是从测速轮或者前段输送算出来的这时候就用虚拟主轴。虚拟主轴的好处是启停、加减速完全由PLC程序控制不会受外部干扰调试时可以任意设定速度甚至在测试模式下手动点动主轴来观察从轴跟随效果非常方便。我自己的项目里超过一半的凸轮应用最终都落到了虚拟主轴方案上。原因很简单实轴编码器反馈多少会带一点噪声和机械振动凸轮同步对相位敏感编码器抖动会造成从轴小幅震荡虚拟主轴则干净得多。3. 凸轮表配置的核心逻辑与实操方法3.1 凸轮表数据模型的理解凸轮表本质上是一个位置映射表主轴的某一位置对应从轴的一个确定位置。NJ里一张凸轮表包含若干行数据每行是(主轴位置, 从轴位置)系统会自动在数据点之间做插值。理解这个模型的时候很多人会被“凸轮”两个字误导以为像机械凸轮一样是从轴位置随着主轴角度做一个固定形状。其实在NJ里还可以选择插值方式直线插值、二次插值、三次样条插值。三次样条能让曲线平滑速度加速度连续但也不代表越平滑越好——如果数据点不合理样条会在两个点之间跑出不该有的过冲反而比直线插值更危险。3.2 用Sysmac Studio创建凸轮表的具体步骤打开Sysmac Studio在运动控制设置里找到“凸轮表设置”新建一张表然后按下面步骤操作指定单位主轴和从轴都选用户单位确认和轴配置一致。选择主轴类型是旋转轴还是直线轴。旋转轴要设定周期通常设360度或者直接设成主轴一圈对应的用户单位。编辑数据点手动添加数据点或者用自动生成功能通过指定关键位置和曲线类型生成。自动生成一般支持“等速返回”“停止返回”等常用运动模板先用模板生成数据再手动微调效率高很多。确认曲线切换界面查看位置、速度、加速度曲线。这里务必看一眼加速度曲线有没有突然跳变。突变的加速度意味着机构会受到冲击实际伺服会报过载或跟随误差过大。保存并下载凸轮表保存在PLC的凸轮数据区程序里通过MC_CamIn指令来调用。3.3 数据点设计的经验法则凸轮数据点的数量不是越多越好。点数太多数据表占用内存不说插值计算量也大而且相邻点之间如果数值变化不规律插值出来的曲线反而会有抖动。我常用的数据点设计原则是在速度变化剧烈的位置加密数据点比如从等速段过渡到返回段的转折处。在速度基本恒定的区段数据点可以很稀疏两三个点就能撑住一大段直线。整张表的首尾数据点必须处理好。如果是连续循环的凸轮首尾的位置和速度要做好衔接否则每个循环都会在衔接点产生一次冲击。举个例子一个典型的飞剪凸轮主轴0度对应从轴起始位主轴90~270度是从轴的同步剪切段从轴速度和主轴一致位置跟着主轴线性变化270度之后从轴快速返回起始位。那我的数据点大概会这样设计0度一个点90度一个点等速跟随开始90~270之间每隔30度放一个点确保线性精度270度一个点再在300、340度各放一个点让返回曲线可控360度回到0度的点。这样大概15~20个点就能把一张表建好。3.4 从轴起始位置的确定逻辑这张表里最容易被忽略的就是MC_CamIn启动那一刻从轴在哪儿凸轮表的数据点里第0行是多少从轴的起点位置就是多少。我遇到过这种情况凸轮表建好了主轴运行正常但MC_CamIn一执行从轴直接猛冲一下再开始同步。查到最后是启动时从轴的实际位置和凸轮表第一个点的位置对不上。MC_CamIn的机制是把从轴的当前位置强制对应到凸轮表的起始位置如果两者差得远就会产生一个巨大的位置阶跃。解决方法是执行MC_CamIn之前先把从轴回零或者移动到凸轮表起始位置附近再激活凸轮同步。这样指令执行时不会有位置跳变。4. MC_CamIn指令实操与同步控制落地4.1 指令时序的控制流程MC_CamIn不是一条指令能单独工作的它前面必须有一整套状态铺垫。我在项目里的标准启动时序是这样上电后先给伺服使能MC_Power。主轴和从轴分别执行回零MC_Home。如果从轴不需要精确原点也可以用MC_MoveAbsolute移动到已知位置。虚拟主轴执行MC_MoveVelocity开始运行。从轴执行MC_CamIn把主轴和凸轮表绑定起来。需要脱离同步时执行MC_CamOut从轴切回普通轴控模式。注意第3和第4步的顺序问题可以主轴先转起来再挂凸轮也可以先挂凸轮再让主轴动。两种方式各有适用场景。如果凸轮表的主轴位置范围从0开始从轴启动位置已经对准了凸轮表起始位置那我习惯先挂凸轮再启动主轴这样从轴启动瞬间就是静止的没有任何冲击。如果工艺上要求主轴已经在匀速运行才允许从轴切入那就按先主轴后凸轮的顺序。4.2 指令关键参数逐项拆解MC_CamIn的参数在Sysmac Studio的帮助文件里都写了但有几个参数的实际含义容易被忽略我逐一说明Master和Slave主轴和从轴的轴引用这里直接填轴变量就行。CamTable新建凸轮表后在程序里声明一个凸轮表类型的变量然后在这里关联。有的项目会用多个凸轮表切换比如不同产品规格对应不同表这里就通过换变量来实现。MasterStartPos这是主轴开始参与同步的位置。不管主轴当前在哪个位置MC_CamIn执行后会把这个值当成凸轮表当前的主轴输入。这个参数很关键。举个例子主轴正在0~360循环运行你在主轴位于120度时执行MC_CamIn如果把MasterStartPos设为90度那系统就会把120度映射为凸轮表的90度从轴会直接跳到凸轮表90度对应的位置。如果这个位置和从轴当前实际位置不一致就会出现位置阶跃。MasterSyncPos从轴开始同步时对应的从轴位置。配合MasterStartPos使用可以让系统知道“我现在主轴在这个位置、从轴在那个位置你们从这组对应关系开始同步”。ExecutionMode缓冲模式一般用mcBuffered即按顺序执行。如果需要立即打断当前运动也可以用mcAborting但我不推荐在同步控制里轻易用Aborting容易造成位置突变。4.3 一个标准的启动程序片段// 凸轮表实例声明 CamTable_飞剪 : MC_CAM_REF; // 执行凸轮同步 MC_CamIn_Instance( Execute : CamIn_Enable, Master : Axis_主轴, Slave : Axis_从轴, CamTable : CamTable_飞剪, MasterStartPos : 0, MasterSyncPos : 0, ExecutionMode : mcBuffered, MasterScaling : 1.0, SlaveScaling : 1.0, StartMode : mcCamTableStart, CamInID CamInID_A, Busy CamIn_Busy, Active CamIn_Active, CommandAborted CamIn_Aborted, Error CamIn_Error, ErrorID CamIn_ErrorID );这段代码里有两个参数值得说MasterScaling和SlaveScaling是缩放系数。比如主轴编码器是1000线经过4倍频后是4000脉冲每圈的从轴实际往凸轮表里填的用户单位可能是360度这时主轴侧Scaling填1从轴侧Scaling填1然后保证凸轮表数据的单位本身和轴设置一致就行。一般不需要用Scaling来做换算换算的事在轴配置的单位设置里解决Scaling留在特殊场合用。另外StartMode这里用的是mcCamTableStart代表从凸轮表起始位置开始同步。如果换成mcCamTableCurrent则会从凸轮表中当前跟主轴位置的对应点开始适合中途切入同步但前提是主从轴已经保持在某个对应关系上。4.4 退出凸轮同步的正确姿势退出同步用MC_CamOut。指令本身很简单但什么时候退、退完之后从轴干嘛这个要提前规划好。如果退出后从轴要做停止动作那么CamOut之后立刻给从轴发MC_Halt或MC_MoveAbsolute让从轴在伺服控制下平稳停下。如果退出后从轴直接失去控制伺服会保持在没有使能的位置环锁定状态不一定得看PLC的轴状态。NJ的轴执行CamOut后轴会回到Standstill状态伺服仍然是使能状态位置由伺服驱动器的位置环保持但不会再跟随主轴。这个特性在急停、故障排查的时候很好用凸轮关系断了但从轴不会溜车。4.5 多轴同步的应用扩展一条MC_CamIn只能绑定一对主从轴。如果设备有多个从轴要同步比如一台印刷机有3个色组滚筒那就得建3个MC_CamIn实例但CamTable可以共用同一张表。多个从轴同步的时候还有一个机制很重要主轴同步位置可以从第一个从轴的凸轮同步结果中串联获取。用MC_ReadMasterAxisPosition可以读取已经建立的凸轮同步关系中的主轴位置。这样两个从轴之间可以形成主从级联一个跟一个相位精确。5. 同步控制实测中的高频问题和避坑心得5.1 MC_CamIn状态位都对了但轴不动这是我被问过最多的问题指令的Active变为TRUE了Error也没有但从轴就是不动主轴明明在跑。这种情况十有八九是凸轮表数据全是0或者主轴位置根本没有变化。凸轮表全0的话从轴位置一直是0当然不动。另外如果虚拟主轴已经跑到同步区域外比如凸轮表主轴范围是0~360但主轴的当前值已经跑到720那就已经超出了表的定义范围NJ在超出数据范围时会在表尾停留。解决办法是让主轴的循环范围覆盖整张表的末尾数据。还有一种隐蔽的原因主从轴的Invert方向设置反了。主轴正转凸轮表数据规定从轴应该正方向移动但轴配置里从轴方向是反的结果从轴往反方向跑或者被机构的限位挡住了看起来就像“不动”。5.2 相位对不上同步位置偏差固定凸轮同步建立后从轴和主轴的相位关系和凸轮表设定存在一个固定的角度差。比如我设定主轴90度时从轴应该到某位置实际从轴总是差一点。排查思路是这样的先确认凸轮表数据里的主轴位置单位和主轴轴配置的运动单位一致这点前面说过但很多人就在这翻车。再确认MasterStartPos的设置。如果主轴本身有一个原点偏置或者主轴的回零方式导致主轴角度和凸轮表0点不对应那每圈下来都会有固定偏差。解决方法是调整轴的原点偏置参数或者在凸轮表数据上整体加一个偏置。我实操时习惯用MC_WriteAxisPosition在主轴回零后把主轴位置设成一个指定的整数值比如0或180这样主轴角度和凸轮表角度天然对齐省去很多换算。5.3 凸轮同步时从轴过载或跟随误差报警从轴伺服报警过载大多数时候不是伺服选小了而是凸轮曲线的加速度过猛。这里教大家一个判断方法打开Sysmac Studio的凸轮编辑器观察凸轮表的加速度曲线。如果加速度曲线在某个点出现尖峰数值远超伺服电机额定加速度那基本就是它了。处理方式有三种把凸轮表里速度变化最陡的那段数据点拉平一些用更多数据点做过渡。降低主轴的运行速度因为凸轮表是从轴位置随主轴位置的关系主轴速度降低会等比例降低从轴实际速度加速度也会等比例降低。改插值方式把直线插值改成三次样条插值让速度过渡更平滑。有朋友会问能不能通过在伺服驱动器里调大扭矩限制来硬扛我强烈不建议。设备调试期也许没问题跑量产时电机会持续发热寿命会明显缩短。凸轮曲线的问题就该在曲线层面解决。5.4 主轴速度波动导致从轴震荡如果主轴是实轴编码器信号存在噪声或者主轴本身速度有波动那么凸轮同步会把这种波动按照凸轮表的斜率放大或缩小后传到从轴。特别是同步段的速比为11的场合主轴波动会一比一复制到从轴。遇到这种情况第一选择是给主轴的编码器信号加滤波。NJ/NX的EtherCAT从站和高速计数输入都有数字滤波参数把滤波时间从默认值调大比如从50us加到500us主轴位置反馈就平滑很多。第二选择是检查机械连轴、皮带张紧等这个就是设备问题了程序帮不上忙。还有一招如果工艺允许从轴的响应增益可以适当调低。把从轴伺服的位置环增益调低10%~20%可以吸收一部分高频抖动代价是同步的刚性会下降适合对精度要求不太苛刻、但对稳定性要求高的场合。5.5 多圈累积误差怎么处理主轴是旋转轴从轴也是旋转轴的场合理论上每个循环从轴应该回到同一位置但实际跑几十圈后从轴的位置会和理论值有偏差。原因通常是凸轮表的最后一个数据点主从轴位置和第一个点没有严格对应。比如凸轮表第一个点是(0,0)最后一个点是(360,360)那没问题正好首尾相接。如果最后一个点是(360,359.8)每圈就差了0.2个用户单位几十圈后差得就明显了。处理办法是让凸轮表的最后一个数据点的主轴位置等于周期值从轴位置等于第一个点的值加周期的整倍数。NJ里有个凸轮表自动修正功能可以把未闭合的曲线自动闭合建议建表时直接用这个功能检查并修正首尾衔接。5.6 CamIn执行中从轴被MC_Stop或急停打断后的恢复急停场景下主从轴同步会被打断CamIn的Active会变为FALSE轴状态变成ErrorStop或Disabled。恢复操作很多人会直接重新使能再挂凸轮但这时从轴位置和主轴位置可能已经错位强行挂凸轮会跳变。我的建议是恢复流程固定为故障复位清掉轴错误状态。从轴先回一次原点或者用MC_MoveAbsolute回到凸轮表起始位置。重新执行CamIn。主轴再投入运行。这套流程虽然多花一两秒钟但每次都能保证凸轮同步以正确的相位建立不会出现恢复后位置对不上、设备撞机的情况。6. 几个还没提到但很关键的细节6.1 程序和凸轮表的配对管理项目里凸轮表数量一多最容易出的事故就是产品切换时调用了错误的凸轮表。我目前的习惯是给每张凸轮表编号并且把对应的产品规格参数比如产品长度、剪切长度写到凸轮表名的备注里。程序里用产品编码去索引凸轮表禁止手动切换。另外还要注意凸轮表的数据是可以被程序在线修改的MC_CamTableSelect、MC_CamTableWrite等指令可以在运行中改表数据。利用这个特性可以做参数化凸轮把凸轮的几个关键点作为配方参数由HMI输入程序实时计算并写入凸轮表。这样做的好处是换产品规格不用重新下载程序适合多品种设备。6.2 扫描周期对凸轮同步的影响很多人担心NJ的扫描周期会影响凸轮同步精度。实际上MJ的运动控制内核是独立于用户程序扫描的MC_CamIn的同步计算在运动控制周期里完成。NJ的默认运动控制周期是1ms或500us一般应用1ms足够高精度同步可以设500us但要注意伺服总线的负载和CPU占用率随之上升。如果程序里还有别的重负载运算比如视觉、机器人联动要留意运动控制任务是否出现了超时警告。一旦出现优先把用户程序的非实时任务拆到低优先级任务里把运动控制任务保持在高优先级且固定周期。6.3 MC_CamIn之外还要知道的辅助指令MC_CamIn启动和停止之外调试阶段最常用的是MC_ReadActualPosition和MC_ReadActualVelocity分别读主从轴的实时位置和速度。我调试时会用Sysmac Studio的Data Trace功能同时监控主轴位置、从轴位置、从轴速度三条曲线观察同步段内从轴速度是否和主轴速度一致以及转入返回段的瞬间有没有速度冲击。这套监控方法帮我找到了好几个数据点不合理的凸轮表比光盯着轴状态硬猜省时间多了。7. 写在最后的几点实操心法做凸轮同步这几年最大的感受是凸轮控制其实没有多神秘它就是把“从轴在主轴每个位置应该在哪”这件事拆成了数据表和一条指令剩下的难点全在数据设计和对轴状态的理解上。给我自己总结几条硬经验也分享给看到这篇文章的朋友凸轮表建表之前先把主轴从轴的轴配置、单位、方向确认好这部分返工最浪费时间。启动凸轮同步之前坚决执行“先回位再挂凸轮”的步骤哪怕多花点时间也好过位置跳变把机械打了。出问题优先看凸轮速度曲线和加速度曲线别一上来就怀疑伺服或PLC。多轴同步时尽量用虚拟主轴稳定性好了不是一点半点。凡是涉及产品切换的设备凸轮表一定要做参数化动态生成别用死表。最后再坦白讲一句网上关于欧姆龙MC凸轮的中文资料确实不多英文手册又厚又绕我们搞设备的就是这样一步步试出来的。这篇如果能让你的调试少走几次弯路那这功夫没白下。后面我再抽时间写一篇关于NJ如何和伺服总线做分布式时钟同步的实操记录那个是运动控制精度的地基配合凸轮一起看会更完整。