企业官网建设流程全解析

简介：GX仿真软件是一款面向PLC初学者的三菱仿真工具，专为缺少实体设备的学习者设计，可在虚拟环境中完成梯形图、功能块图等程序的编写与调试，并支持GOT触摸屏及FX系列PLC的仿真操作。压缩包约22.42MB，共51个文件，其中exe与cab为安装主程序，dll为运行库，dat/ini保存配置，htm/txt则提供安装与使用说明，整体结构便于快速部署。目前已有431人学习/下载，适合作为PLC入门阶段的辅助练习材料。借助这款仿真软件，用户可系统练习PLC编程基础、逻辑控制、输入/输出管理、定时器与计数器应用，并通过人为设置错误条件来训练故障排查与项目调试能力。附带的安装说明和自述文档能为初学者解决安装与使用中的常见问题，帮助在无硬件条件下顺利完成PLC编程实践。

1. GX仿真软件是什么：不上真机就能把PLC程序跑起来的离线调试工具链

一台设备，程序在GX仿真软件里跑到全绿，信号该亮的亮、该灭的灭，顺序一点不差。下载到真机上，第一个气缸伸出就撞了限位、报了错。这不是逻辑错了，而是仿真器默认给了一个“理想世界”：传感器信号被强制成有的状态，输出扫描也在固定周期内完成。GX仿真软件的本职，是把可编程逻辑控制器的运行环境搬进电脑，逻辑层全真跑，但设备层、电气层、通信层它替不了你。这篇笔记就围绕“能替什么、不能替什么、怎么替才不出事故”展开，适合电气调试工程师、设备维护人员以及刚转工控开发的工程师。先把边界摸清楚，再做仿真验证，产线上才少挨几次骂。

2. 仿真器替你做了什么：能覆盖的逻辑层与不能覆盖的设备层

2.1 运行环境是怎么虚拟出来的：程序块装载、软元件存储区与扫描循环

GX仿真软件的核心不是“画几个动画给你看”，而是把PLC的运行时环境在PC上重建出来。程序本体、数据块、定时器、计数器、辅助继电器、数据寄存器，这些都会被装载到仿真器内置的虚拟存储区里，然后按扫描循环的方式一遍一遍执行。你在真机上能看到的程序状态、当前值、监控窗口，仿真器里基本也都有，这也是它能用来做程序验证的根本原因。

常见做法是新建一个虚拟工作区，把编译好的程序块投进去。投进去之后，程序不是静态的，而是从一个初始状态开始反复扫描。某个输出条件满足、某个定时器计时到点、某个计数器累加溢出，这些行为在仿真器里都会真实发生。你可以用监控窗口观察某个数据寄存器的当前值，也能看定时器的剩余时间，这和真机在线监控的体感非常接近。

但注意，扫描循环这件事有个细节。仿真器的扫描节拍和真实CPU的扫描周期不是一回事。真实CPU的扫描周期在几十微秒到几十毫秒之间，而仿真器通常把一次扫描压缩成一个系统调度，单位可能是操作系统线程的几毫秒到十几毫秒。所以程序里如果依赖高精度的绝对时间判断，在仿真里验证只能看相对顺序，不能拿绝对毫秒数当验收标准。

2.2 仿真结果会骗人的三个位置：扫描周期、保持区与IO刷新

第一处是扫描周期。前面提到仿真器的扫描调度和真机不一致，这在定时器多的程序里尤其明显。比如程序里有个T38，设计要求2秒后置位一个输出，仿真里看可能是1.98秒，到了现场变成2.05秒，这不是程序写错，是两者对时间片的管理精度不同。遇到这种情况，不要改定时器预设值去迁就仿真结果，要看逻辑顺序是否正确。

第二处是掉电保持区。仿真器重启、程序复位时，保持区软元件的初值恢复方式与真实PLC的存储卡、电池后备单元配置不一样。仿真里断电再上电，所有软元件可能直接回到初始值，但现场如果存储卡没插好或电池没电，保持区数据可能变乱。这个差异会在重启类故障排查时坑你一整晚。

第三处是IO刷新方式。真实PLC在扫描循环的特定阶段采集输入映像区、刷新输出映像区，而仿真器往往简化成“立即读立即写”。也就是说，外部开关从接通到程序里看到信号变化，在真机里要等一个扫描周期，在仿真器里可能你看不出延迟。涉及安全联锁、急停回路、气缸节拍的验证，这个差异要考虑进去。

2.3 什么时候该上仿真、什么时候该上真机：选型判断表

仿真能覆盖的范围是“纯逻辑层”：一个气缸伸出到位后，下一段流程是否被触发；一个故障字里某一位翻转时，联锁回路是否动作；一套分拣流程在不同配方参数下选择哪条分支。这些不依赖外部物理量、不依赖通信总线时序的判断，仿真可以替你验到八成以上。

仿真不能覆盖的范围是：电气接线是否正确、传感器信号是否真实存在、驱动器通信是否掉站、总线报文往返时间是否满足工艺节拍、以及掉电保持的现场配置。这些只能在真机点检里暴露出来。用一个判断表来帮自己决策，比凭感觉省事得多。

3. 搭最小仿真环境：虚拟工作区、软元件映射和三种必调的仿真参数

3.1 把目标型号投进仿真器：新建工作区与设备型号映射

第一步是把你的目标设备型号加进去。常见做法是在仿真入口处新建一个项目工作区，把整个设备组态文件导入，再把目标PLC型号选成“仿真型号”。这里有个很容易踩的坑：如果你在真实项目里选了某个不支持仿真的CPU型号，仿真器会直接提示目标无法装载，而不是自动降级。

遇到这个提示，先别急着怀疑软件坏了。检查设备组态里的CPU型号是否在仿真支持列表里，不在就换成一个支持的目标型号再编译一次。注意程序里用了特殊功能模块、运动控制模块的话，这些模块在仿真工作区里通常只有一个占位，不参与实际运算，所以相关逻辑验证时要把这些模块的输入输出映射到普通软元件上。

型号映射好之后，工作区里会多出一个“运行任务组态”树。这里可以看到程序里每个任务块的激活顺序。我一般会先在这个界面看一眼任务是否被错误地建成了多个并行任务，因为仿真器里任务调度顺序不同，可能导致同一个变量在不同块里读出不同值。确认只有一个主任务循环后，再进入下一步。

3.2 用脚本批量生成软元件注释表：从IO清单到仿真监控的一步到位

仿真器里监控的时候，如果软元件注释是空的，屏幕上全是X0、Q0.7、DB12.DBW0这种地址编号，查起来会疯掉。图纸上的IO表通常有明确的中文注释，比如“X0 启动按钮”“Q0.5 三色灯绿色输出”。把这些信息批量导入仿真工作区，是搭建环境里最该先做的事。

我一般会把图纸IO清单整理成一个固定格式的文本文件，然后用脚本生成仿真工具能认的CSV注释表。脚本只需要处理地址、注释、数据类型三列，工作量不大，胜在重复项目里能复用。

# 从图纸导出的IO清单生成软元件注释CSV # 输入文件格式：X0|启动按钮|常开触点 # 输出内容：地址,注释,数据类型（按你工具导出的样例调整表头） import csv def export_comment_table(src, dst): rows = [] with open(src, "r", encoding="utf-8") as f: for line in f: parts = line.strip().split("|") if len(parts) != 3: continue addr, comment, _ = parts # 数据类型按地址首字母粗分，X/Q/M为BOOL，D/W为INT data_type = "BOOL" if addr[0].upper() in ("X", "Q", "M") else "INT" rows.append([addr, comment, data_type]) with open(dst, "w", encoding="utf-8-sig", newline="") as f: writer = csv.writer(f, delimiter=",") writer.writerow(["Address", "Comment", "Type"]) # 表头按样例文件为准 writer.writerows(rows) if __name__ == "__main__": export_comment_table("io_list.txt", "symbol_comments.csv")

逻辑说明：脚本把每行按竖线切分成三段，取前两段作为地址和注释，再根据地址首字母粗判数据类型。X、Q、M这类位软元件归为BOOL，D、W这类字软元件归为INT。导出时用utf-8-sig编码，是因为UTF-8无BOM的情况下，Excel打开中文CSV会乱码，仿真工具导入时也容易认错字段。

参数说明：输入文件的分隔符按你实际导出的格式调整，不一定是竖线；表头那行“Address,Comment,Type”要根据仿真工具的导入模板改，有些工具还要求带触点数据类型GBool/GInt，导入前先用一个最小CSV试一次，确认列顺序再全量导入。注释表导入成功后，监控窗口的观感会完全不一样，查故障快很多。

3.3 初始化值、掉电保持与扫描方式：仿真前必须填的三张参数表

仿真环境跑起来之前，有三个参数位不要去动默认值，但心里要有数。第一个是初始化值表，决定程序冷启动时软元件的初始状态。比如某个配方数据寄存器在冷启动时要恢复成预设值，就用初始化表写入；如果初始化表和程序里的启动赋值逻辑同时存在，程序扫描后会覆盖初始化值，这个先后顺序要清楚。

第二个是掉电保持区设置。仿真器里通常有一组保持区范围，比如M500以后、D1000以后默认保持。真实PLC保持区的范围取决于存储卡配置和你选用的保持参数，两边不一定一致。调试重启不掉数据的功能前，先用这个表确认哪些软元件被标记为保持，哪些一断电就清零。

第三个是扫描方式设置。仿真器一般提供连续扫描和单次扫描两种模式。跑自动流程用连续扫描；排查一个条件分支的某一瞬间状态，用单次扫描配合强制置位，能精准停在你要的那个扫描周期上，比连续跑然后回头找时序图高效得多。

4. 用影子模型点检一段设备回路：强制置位、状态字与节拍验证

4.1 仿真器里没有传感器：先学会强制置位和解除强制

仿真器的输入信号不是接出来的，是“给”出来的。一个启动按钮、一个接近开关、一个限位开关，在仿真里都靠强制置位把对应的软元件置成TRUE。这里最容易翻车的操作是强制完之后忘记解除，导致后面验证别的逻辑时，这个信号一直保持接通。

我一般习惯把强制操作分成两类。一类是暂时强制，用来模拟一个瞬时按钮的按下，置位后跑一个扫描周期，立刻解除强制，模拟“按下又松开”的完整动作。另一类是持续强制，用来模拟一个常开触点在有料、无料状态下的电平，保持置位或复位不动，直到该场景验证完。

强制置位后，要留意程序里是否有其他逻辑会改写同一个软元件。最常见的情况是你强制了M100等于TRUE，程序里恰好有一个置位指令在每个循环里也会把M100写成TRUE，两边看起来一致，但当你解除强制时，程序里的最后一次赋值还在，状态并不会回到你期望的初值。所以在强制之前，先查一遍这个软元件的交叉引用，看看它被多少条指令写过。

4.2 搭一个气缸影子模型：用结构化文本模拟设备到位时序

仿真器里没有物理气缸，程序里也没有“气缸伸出20mm后触发到位信号”这个概念。程序只知道输出指令给了电磁阀，输入信号里有没有到位反馈才是它判断下一步的依据。因此在验证设备回路时，要自己搭一个影子模型，把“机械动作”翻译成“延时后置位”。

影子模型不复杂，本质就是一个延时反馈通道：程序给伸出指令，影子模型开始计时，计时到点后，把到位信号反馈给程序。我用结构化文本写一个气缸影子模型，投到仿真工作区里和主程序一起跑。

FUNCTION_BLOCK FB_CylinderShadow VAR_INPUT cmdExtend : BOOL; // 来自程序Q输出的伸出指令 cmdRetract : BOOL; // 退回指令 extTime : TIME := T#500MS; // 伸出到位耗时 retTime : TIME := T#400MS; // 退回到位耗时 END_VAR VAR_OUTPUT posExtend : BOOL; // 仿真给回程序的伸出到位信号 posRetract : BOOL; // 退回到位信号 END_VAR VAR runTimer : TON; // 用TON统计动作耗时 busyState : INT; // 0待机 1伸出中 2退回中 END_VAR

逻辑说明：这个功能块把一个物理气缸模拟成三段状态——待机、伸出中、退回中。程序给cmdExtend时，busyState切到伸出中，runTimer开始计时，计时到点就把posExtend输出置TRUE。主程序里的到位输入点不需要直接看到气缸，只要看到这个输出信号就能继续走流程。

参数说明：extTime和retTime要从气缸样本的行程时间推算，不能随便填。常见做法是先看气缸缸径和行程，再按厂家的速度参数估算一个大概时间，比如行程200mm、速度250mm/s，理论上0.8秒到位，就设到900MS。如果程序里有超时报警逻辑，影子模型的延时参数要设得比程序超时时间短，否则每次验证都会误报超时。

4.3 节拍监控与导出：把运行结果变成能比对的报表

影子模型搭好后，程序跑起来就可以观察整个节拍。仿真器的监控窗口里可以同时选中多个软元件，记录它们随时间变化的状态。这里要说一个关键习惯：不要只盯当前值，要把关键信号的变化顺序记录下来，和设计图里的时序表做比对。

比如一个分拣工位要“收到放行信号0.5秒后推料气缸伸出，伸出到位后再等0.2秒缩回”。你把放行信号、推料输出、伸出到位、缩回输出四个信号加进监控窗口，让它连续跑一轮，然后看时序图上信号的先后顺序是否符合设计。顺序错，说明状态机跳转有问题；顺序对但时间间隔不对，多半是影子模型的延迟参数填得不准，不一定是主程序的问题。

仿真器一般支持把监控到的数据导出成CSV报表。我通常会把每一轮节拍的数据导出一份存档，标注好是哪一版程序、哪一轮验证，方便回头找问题时候翻。这个习惯在多人协作调试时尤其有用，两个人各改一段逻辑，有了节拍报表，谁的改动影响了时序一眼就能看出来。

5. 仿真调试避坑：五个最常翻车的现象与排查顺序

5.1 仿真全绿、真机红灯：强制信号没清干净

现象：仿真里跑完了整个流程，状态全对，下载到真机后第一个动作就不动。原因大概率不是逻辑问题，而是仿真时把某个输入信号一直强制为TRUE，真机上该信号实际没有接通。解决：仿真验证结束后，先全清强制再跑一遍，看去掉强制后程序在哪一步停下，把那一步的输入清单拉出来对照现场接线检查。

5.2 强制输出又被程序扫过来改写：交叉引用里查源头

现象：在监控窗口强制一个输出位为TRUE，但画面显示马上又变回FALSE，反复强制都稳不住。这不是仿真器坏了，是程序里有其他逻辑在同一扫描周期内写这个位。解决：查这个软元件的交叉引用，看它被哪些指令写过。常见的来源是某条赋值指令在循环靠后的位置又执行了一遍，把强制覆盖掉了。定位到源头，改成正确的使能条件，方案是在仿真里验证这个使能条件是否按预期成立。

5.3 定时器数值在仿真和真机里对不上：节拍差异不是玄学

现象：程序里有个0.5秒的定时器，仿真里计时动作很准，真机上明显偏慢或偏快。原因：仿真器的时钟调度与真实CPU的扫描周期、系统心跳不一样，定时器分辨率在两端存在固有差异。解决：先确认程序用的定时器是毫秒级还是百毫秒级，然后做一次相对顺序验证，只判断定时器到达时后续分支是否被触发，不要拿绝对时间当验收标准。如果工艺上对时间精度有硬指标，只能放到真机上去标定。

5.4 断电重启后保持区数据全乱：冷启动初始化没验证

现象：仿真里改配方、存参数，把程序复位重启，数据还在；真机上断电再上电，配方数据变成了乱值。原因：仿真器的保持区默认把所有保持型软元件都保留了，真机上保持区范围取决于存储卡配置和冷启动初始化程序。解决：在仿真器里把保持区范围改得和现场存储卡配置一致，再单独测一轮断电重启流程，确认冷启动初始化程序能把关键数据恢复到正确值，而不是空等保持区数据。

5.5 监控窗口找不到块：任务组态层级和你记得的不一样

现象：程序块明明编译通过了，仿真监控窗口里却找不到某段逻辑，或者找出来的内容和你改的不一样。原因：仿真工作区里加载的是最后一次编译的完整运行任务，如果项目里有多个任务块被拆散，监控窗口默认显示的是激活的某个任务，不是全部。解决：在运行任务组态树里看当前激活任务列表，找到对应块名称再打开监控。以后每次改完程序块，重新编译一次整个项目再进仿真，避免加载了旧的中间编译产物。

6. 进阶：半实物在环验证，把仿真工作区变成闭环测试台

6.1 用OPC UA把软元件区暴露给外部模型

前面搭的影子模型在仿真器内部跑，能验证逻辑顺序，但验证不了闭环调节。你没法在仿真里给PID控制器一个真实的温度曲线、速度曲线。半实物在环就是让程序的真实代码和外部设备模型连起来，程序像操作真机一样操作一个软件模型，模型再实时回写数据。

常见做法是通过OPC UA把仿真器里的数据块发布出去，然后用Python写一个被控对象模型，每50到100毫秒读一次程序下发的控制字，模拟被控对象物理过程，再把测量值写回仿真器的反馈区。这样就能在没有真机的情况下，把PID、伺服定位、温度控制这类闭环逻辑调出大致的调谐参数。

这个验证方法的两个坑要特别记下来。第一个坑是回环周期不能小于仿真扫描周期的5倍，否则外部模型反馈太快，程序还没扫描到这个反馈就已经进入下一步了，整个闭环节奏全乱掉。第二个坑是地址映射要确保只有一端写同一个区，仿真器内部程序写控制字、外部模型写反馈字，两边写同一个区会导致互相覆盖，跑两分钟就能把整个工作区锁死。写完闭环模型后，先跑一个只有单个反馈回路的慢速场景，确认数据方向正确，再放大到完整流程。

以前有位同事调一套温度控制逻辑，在仿真里怎么调都稳定，上了现场就开始抖，最后查出来是仿真的反馈周期太理想，现场温度传感器采样延迟根本没体现在模型里。从那以后我凡是带闭环的程序，都会先挂一个影子模型跑通再做真机验证，这个习惯帮我在现场少加了好几次班。希望帮到你。

本文还有配套的精品资源，点击获取