接到这个项目需求的时候，我第一反应并不是"选哪个型号的CPU"，而是先搞清楚这套系统要承担什么样的实时性责任。一条产线的控制柜集中放置，但执行机构分散在二三十米外；旁边新上一台六轴机器人负责上下料；操作侧要求触摸屏能管几十种配方，并且两个工位都要能操作同一套设备。三菱R系列PLC在这个场景下几乎是顺理成章的选择，但真正落地时涉及的通信组网、数据映射、配方结构和多屏变量规划，才是这套"高端应用"里最花功夫的部分。
这篇文章就把这个项目从架构设计到联调交付的全过程拆开讲，重点放在三个模块：远程IO的CC-Link IE TSN组网、机器人的Ethernet/IP通信、GOT触摸屏的配方与多屏操作。内容适合做系统集成、设备调试或者现场维护的工程师参考，尤其是第一次把三菱R系列和机器人、多台触摸屏放在一起做的朋友，应该能少走不少弯路。
1. 第一轮架构设计：先把三件事拆清楚再谈选型
1.1 这台R系列CPU到底承担了什么调度职责
项目现场设备不算复杂，但控制对象很杂：输送线上的十几个传感器、气缸、变频器、模拟量信号，加上机器人抓手、安全门、光栅，还有两台GOT触摸屏的显示与控制需求。最初考虑过用中小型PLC做主站，再用扩展机架解决点位问题，但算了一笔账：现场点位分布在一条长约30米的轨道沿线，如果全部拉硬线到中央控制柜，不仅电缆成本高，而且接线端子数量大，后期查线会让人崩溃。
最后定下来用R系列CPU做主站。理由很直接：R系列本身支持多网络并行处理，可以同时承担CC-Link IE TSN网络主站、Ethernet/IP通信和GOT连接，不需要额外再挂一台通信处理器。CPU型号选的是带以太网功能的基本型，程序容量和软元件数量对这套系统来说余量充足，IO点数大概规划在三百点左右，加上机器人通信的数据映射，占用率不到一半。这个选型思路其实很重要——先统计实际点位和通信需求，再决定CPU大小，而不是先定CPU再去凑点位。
1.2 为什么远程IO不用扩展机架而走网络
设备分布距离较远时，摆在我们面前的有两条路：一是从PLC扩展机架拉远程IO模块，二是走工业以太网做分布式IO。扩展机架的方式在三菱老平台上也常见，但距离通常限制在几十米到一百米以内，而且每个扩展机架需要单独的电源和通信线，现场还得专门留安装位置。这条产线沿线是高速运动机构，机架式远程IO的布线路径和抗干扰都会成为隐患。
相比之下，网络型远程IO站的优势非常明显：一根网线就能把点位送到设备旁边，IO模块直接装在执行机构附近的电气箱里，接线路径大幅缩短，排查故障时也能快速定位到局部。更重要的是，网络型IO站可以就近安装，传感器信号不用绕一大圈回到主柜，信号衰减和干扰问题都更好控制。我们最后选择了CC-Link IE TSN网络，带宽1Gbps，刷新周期远快于普通现场总线，而且支持标准以太网设备混用，为后续扩展预留了空间。
多年调试经验告诉我一句话：通信方案的选择，拉开的差距不是现在的几分钟，而是设备投产后每一次故障排查要花多少时间。网络型IO站的诊断能力远强于传统扩展机架，这也是高端应用里值得多花点预算的地方。
2. 远程IO组网：CC-Link IE TSN下的扫站节奏与拓扑细节
2.1 网络拓扑选型：环形还是星形
CC-Link IE TSN支持星形、环形和线形拓扑，选型时我特意对比了环形和星形的利弊。环形拓扑最大的优点是链路冗余——一根光纤断了数据还能从另一侧绕回来，这在产线不允许停机的情况下是硬需求。但这个项目属于常规改造，允许短时停机维护，所以在成本和控制难度之间取了平衡，最终采用星形拓扑：主站模块出来接一台支持TSN的工业交换机，再从交换机分别拉线到两个远程IO站和后续的扩展节点。
这样做的原因很实际：星形拓扑布线简单、故障定位直观，某一路断开只会影响对应的IO站，不会祸及整条网络。而环形拓扑虽然可靠性高，但需要每台设备都支持双口环网，配置工作量和成本都会上升。在需求允许的前提下，不要让系统复杂化——这是我做架构设计的一条铁律。
R系列CPU这边需要加装对应的网络模块，或者使用带有内置以太网口的CPU型号。远程IO站的配置在GX Works3里完成，需要设置站号、占用点数和传输速度。站号规划要预留一定空档，万一后期要在两个站之间插入新站，不用重新调整所有站号。
2.2 扫站时间如何估算：刷新时间不是越快越好
远程IO的响应速度取决于网络刷新周期，也就是主站把所有从站的数据刷新一遍所需的时间。很多人以为刷新时间设得越小越好，实际上过度追求极速会带来不必要的负荷，甚至影响CPU扫描周期与网络刷新的配合。CC-Link IE TSN的刷新周期跟从站数量、每站占用点数、通信数据量都有关系，参数设定后可以在软件里看到预期刷新时间。
这个项目里两个远程IO站，每站大约占用了输入输出各几十个点，设定下来的刷新周期大概在毫秒级，完全满足输送线的逻辑控制需求。真正需要注意的是CPU的扫描周期和网络刷新周期的配合：如果程序里用输入信号触发输出信号，最快也要等到下一个扫描周期才会反映出来，所以不要单看网络刷新快，还要把PLC扫描时间算进去。
我在调试时习惯先用GX Works3的参数设置功能观察"理论刷新时间"，再实测一遍IO从触发到响应的总延迟。方法很简单：把一个输入点的信号直接映射到输出点，然后在触摸屏上用示波器功能或者外部工具测时间。这个实测值才是设备动作时序的基准。
2.3 远程IO配置里的常见坑：站号、传输速度与掉站诊断
整个远程IO配置过程中，最坑的往往是细节。站号重复是最常见的问题——设备供货后发现厂里有两台IO站被拨到了同一个站号，结果两台都报错，数据还互相干扰。我后来要求所有IO站在出货前统一贴好站号标签，并且通电前必须用GX Works3做一次"在线站列表核对"，这一分钟能省掉后面一小时的痛苦。
另一个易踩的坑是传输速度设置不一致。CC-Link IE TSN虽然支持不同速率的设备挂在同一网络，但如果你在从站参数里手动指定了较老的通信模式，主站的参数又设置成另一个版本，就会出现"时通时断"的怪毛病。这种情况最迷惑人，因为线缆没问题、站号没问题、诊断也偶发正常，最后翻参数才发现是速度配置不匹配。
掉站诊断也必须提前规划好。网络型IO站一旦断线，IO数据的处理策略直接关系到设备安全。R系列里可以配置输出保持或输出清零，我的习惯是：涉及安全联锁的信号，断线时必须清零，宁可停机也不能让输出"定住"在上一个状态；而一些普通的指示类信号可以保持原值，方便判断故障前状态。这个策略最好在写程序之前就和现场维护人员对齐，不然后期改动会很被动。
3. 机器人通信：Ethernet/IP的数据通道搭建与联调记录
3.1 为什么选Ethernet/IP而不是硬接线点对点
机器人通信这一块，最初方案讨论过硬接线I/O和Ethernet/IP两种方式。硬接线看起来最直接：PLC的输出点接到机器人的输入点，一来一回几十根线，逻辑上非常简单。但实际算下来，机器人需要交换的信号包括启动、停止、复位、报警、程序号、完成状态、抓手开闭、工件计数等等，接近二十个点，再加上手自动模式切换和安全信号，电缆和端子数量就很可观了。而且硬接线只能传开关量，程序号、计数这些数据如果要传，得多加不少模拟量或通信模块。
Ethernet/IP的优势在这里就很突出了：一根网线替代几十根信号线，开关量和数据可以打包传，PLC侧用配置工具建立通信连接，机器人控制器那端也支持标准的Ethernet/IP扫描器功能。我们最终把通信数据控制在每个周期32字节左右，分别划分输入和输出区域，数据量不大但灵活性远高于硬接线。
选型时还要注意一点：机器人的Ethernet/IP"从站"角色不是所有型号都标配，有些需要额外选项或授权。采购前一定要和技术支持确认清楚，别等设备到了现场才发现通信功能没开通，那就要等很麻烦的追加流程。
3.2 寄存器映射表：状态字、指令字、握手信号的设计
Ethernet/IP通信建立之后，PLC和机器人之间交换的是一块连续的寄存器区域。设计这块映射表是联调的基础，也是整个项目里最需要提前想清楚的部分。我习惯把映射区域拆成几个功能块：状态字区、指令字区、数据字区和握手区。
状态字由机器人侧写入，PLC读取，内容包括"机器人远程模式""机器人就绪""机器人运行中""机器人报警""程序执行完毕"等等，每一个位都有明确含义。指令字由PLC写入，机器人读取，包括"启动程序""暂停程序""复位报警""请求工件"等。数据字用于交换程序号、工件数量、节拍时间这些整型数据。握手区则是一对互相配合的触发与应答位，防止指令发出后没有回应就接着发下一条。
以启动程序为例，流程是这样的：PLC确认机器人处于远程模式且无报警后，把"启动程序"位置ON，同时把目标程序号写入数据字区；机器人收到后执行程序，并返回"运行中"状态；程序跑完后机器人把"程序执行完毕"位置ON，同时把"运行中"位清零；PLC看到完成位置ON后，才把"启动程序"位复位。这样每一个步骤都有明确的时序约束，任何一步卡住都能快速定位是PLC没发指令、还是机器人没响应、还是通信断了。
3.3 联调阶段的坑：时序、心跳和急停链路
联调阶段遇到最多的问题是时序匹配。PLC扫描周期和机器人程序扫描周期不一样，如果PLC把"启动程序"指令发出后，机器人还没准备好就丢了指令，整条线就停在原地不走。我们在握手逻辑里加了一重保护：PLC发出的触发信号至少要持续两个通信周期，确保机器人侧的扫描一定能采到；机器人应答后PLC再清零。同理，程序完成信号机器人侧也要保持足够时间，否则PLC一个扫描周期太快，可能直接漏掉完成脉冲。
心跳检测是必须做的。我们在通信数据区里定义了一个递增计数，机器人每个周期加一，PLC判断这个计数值是否持续增长。超过一定时间没变化，PLC直接判定通信异常，输出报警并触发安全停机条件。这个心跳机制看起来简单，但如果没有它，通信线松了或机器人死机时PLC还在傻等状态字，整个系统的状态显示全是假的，非常危险。
还有一个容易被忽略的点：急停链路不能依赖通信。通信再快也有延迟，而且通信故障时双方都不知道对方状态。急停信号必须用硬接线直接把安全回路串起来，PLC侧和机器人侧的安全继电器都接入同一个急停回路。这是底线，不要有任何商量余地。我们项目里通信可以做得很漂亮，但最后安全接线还是按照传统方式单独走了一套硬线回路，这也是我在任何自动化项目里都不会妥协的地方。
4. 触摸屏配方：GOT配方表的结构设计、上下装与防误操作
4.1 配方放在GOT还是放在PLC：两个层次的取舍
配方这块，GOT本身自带配方功能，可以直接在画面里编辑配方数据，然后通过部件操作写入PLC软元件。这个方式上手快，适合配方数量不多、修改频率不高的场景。但在这个项目里，我最终选择了把配方数据块放在PLC内，GOT画面只做显示和输入界面。
原因很实际：配方不只是"一堆参数"，它需要和运行逻辑联动——配方切换时PLC要校验参数范围、要判断当前是否允许切换、要记录是谁在什么时候切换的。这些逻辑放在PLC里更可靠，不依赖触摸屏是否开机。而且现场有两台触摸屏，如果配方各自存在屏里，两台屏的数据可能不一致，放PLC里就能天然避免这个问题。
PLC内存里规划一块配方数据区，用配方号做索引，每个配方固定占用一段连续寄存器。GOT画面用"配方选择"和"配方参数编辑"两种界面，选择配方号时从PLC对应区域读取参数并显示，修改参数后通过"写入PLC"按钮把整段数据写回去。这样GOT只负责交互，真正的数据管理全在PLC侧掌控。
4.2 如何搭建配方数据块：索引表、配方号、参数校验
配方的数据结构设计直接影响后期维护。我在PLC里定义了一个区域：首字存放配方总数量，接下来是每个配方号的索引表，再往后是配方明细区。每个配方占用的寄存器数量一致，比如温度设定、速度设定、压力设定、保持时间、计数上限等，每个参数固定寄存器位置。这样一个配方条目20个寄存器，几桶配方只需要在索引表里增加一行。
GOT端需要针对这个结构做画面。配方选择界面用列表控件或数值输入直接对应配方号，选择后GOT读取该配方的参数。这里有一个容易出错的地方：GOT读取的数据是瞬时值还是持续同步？如果配方区域在PLC里不断更新，GOT上的显示可能会"跳来跳去"。我的做法是：画面打开时一次性读取，显示在缓冲寄存器里；操作人员编辑时修改的是缓冲数据；点击"保存"才把缓冲写回PLC。写回动作由PLC侧做条件判断，校验通过才接受。
参数校验非常关键。配方里的温度、速度、压力值都有上限和下限，直接写入可能导致设备超限动作。PLC里写了一段校验逻辑：写入请求触发时，逐项检查每个参数是否在允许范围内，越界则拒绝整体写入并返回错误代码，GOT上显示相应报警信息。这套校验机制虽然代码不多，但能挡住绝大多数误操作。
4.3 配方切换的防呆设计：哪类操作必须二次确认
配方切换从来都不只是"换一组数字"那么简单，它意味着设备的工艺参数整体变化，可能影响正在运行的产品质量甚至设备安全。所以在GOT画面上，配方切换必须做二次确认：操作人员选中配方号后点"应用"，画面上弹出确认窗口，显示当前配方和目标配方的基本信息，要求操作人员再次确认。确认后才允许PLC执行切换逻辑。
运行状态下禁止切换配方是另一条铁律。PLC内部把设备运行状态作为一个互锁条件，运行中收到切换配方请求直接拒绝，并在GOT上提示"设备运行中禁止切换配方"。理由很简单：一套参数在运行途中整体变化，谁也无法保证设备动作是否连贯，一旦出问题就是设备损坏或产品报废的事故。
最后是配方修改记录。GOT支持操作日志功能，配合用户权限可以记录谁在什么时间修改了哪个配方。几块钱的成本，换来的是事后追溯的能力。现场最怕的不是操作失误，而是不知道谁动了参数，下次再调的时候无从下手。有了操作日志，这类问题基本就杜绝了。
5. 多屏操作：两台GOT协同工作的变量规划与一致性保障
5.1 多屏场景形态分析：主从操作站、异地监控站
项目里装了两台GOT，一台在主操作面板上，另一台在产线尾端的辅助工位。这两台屏的使用场景并不完全相同：主操作屏承载全部操作功能，包括配方管理、手动操作、参数监控；辅助工位屏主要用于状态查看和部分操作，比如呼叫、急停、产量查询，不需要也不应该具备和主屏完全一样的控制权限。
多屏协作的第一个问题就是"变量打架"。如果两台屏各自都往同一个PLC软元件写数据，比如都写"启动"按钮对应的位，那么主屏启动后，辅助屏可能也会触发启动，或者两台屏同时操作时互踩。解决思路是把软元件划分成公共区、私有区和互锁区三类，用不同的地址段承载，各司其职。
5.2 变量区分公共区、私有区与互锁区是核心
我在PLC软元件规划时专门划出了三个区域：公共区是两台屏都要读取的状态量，比如设备模式、当前运行状态、报警汇总；私有区是只有指定屏可以写入的操作指令，主屏有主屏的启动按钮地址，辅助屏有辅助屏的呼叫按钮地址，两者物理上分开；互锁区则是需要联动判断的信号，比如操作权标志、自动模式下禁止操作标志。
以启动按钮为例：主屏上"启动"写入的地址是M100，辅助屏上"呼叫PLC复位请求"写入的地址是M200，两台屏的画面里各自的按钮地址完全不一样。PLC程序里再根据当前操作权落在哪一侧，来决定哪一组的按钮地址有效。这样即使操作人员同时按了两台屏的按钮，也不会出现两边抢控制权的情况，PLC侧的逻辑天然屏蔽了无效输入。
变量规划表在项目实施前就必须做成文档，让电气工程师和现场调试人员共用一张表。地址写死在程序里之后最怕布局混乱，后期加一个按钮都不知道该放哪个区。我习惯在每个区的首地址留一定空余量，避免后续小改动引发全局地址重排。
5.3 多屏操作权切换与画面同步细节
两台屏都具备操作功能时，需要一个"操作权"概念。我们设计的默认状态是主屏拥有操作权，辅助屏只能看、不能操作；如果操作人员需要转移到辅助屏操作，必须先在主屏上切换操作权并确认，或者通过一个实体钥匙开关来切换。实体钥匙切换更硬、更安全，我们最终用了这种方式，钥匙转到"辅助屏"位置后，PLC才开放辅助屏的私有操作区，同时主屏的操作按钮变灰禁用。
画面同步方面，GOT支持画面跳转指令，PLC可以通过软元件触发让所有屏都跳到同一个画面。我们在报警画面做了一个联动：任何一台屏查看报警列表时，PLC会触发所有屏切换到报警画面，保证现场人员看到的信息一致。这个功能在设备故障时特别好用——省去了操作人员跑来跑去确认各台屏显示内容的麻烦。
多屏通信的性能也要实测。两台GOT同时访问PLC时，GOT的通信周期会影响画面刷新速度。如果发现某台屏画面切换卡顿，可以在GOT设置里调整通信优先级，或者把高刷新的画面变量分散到不同的通信周期中。这个属于细节调校，项目交付前一两天专门花时间做了一遍各画面的操作流畅度测试，把明显的卡顿点都修掉了。
最后再分享一个我在多屏项目里的心得体会：地址映射表一定不要只存在于某一个人的脑子里，做成一张表格放在项目文件夹里，以后任何一位工程师接手都能快速搞懂这套系统的通信布局。这个做法在我们后续维护时帮了大忙——一年后产线改造加了一台设备，新同事拿着地址表半天就完成了接入，几乎没有问任何一个"这个地址是干什么的"之类的历史遗留问题。技术本身不难，难的是把边界划清楚。远程IO、机器人通信、配方管理和多屏操作，说到底都是在回答同一个问题：数据从哪来、到哪去、谁说了算。把这三件事理顺了，高端应用也就没那么玄乎了。
