做自动化项目这几年我越来越体会到一件事不是所有地方都需要上位机。早期接产线项目客户提“能不能把每台设备的报警记录自动汇总到办公室电脑上”我们第一反应就是上上位机——C#也好LabVIEW也好反正写界面、开通信、读PLC整套下来没有一个月拿不下来。后来我试了另一条路现场那台MCGS触摸屏本身就是个带网口的小型计算设备能跑脚本也内置了FTP客户端能力只要在工控机上把FTP服务器搭好让触摸屏按设定周期把文件传过去文件自动同步这件事就闭环了。期间踩过不少坑但理顺之后最快一次从搭FTP服务器到触摸屏脚本跑通确实就5分钟左右一行上位机代码都没写。这篇就把这套方案完整复盘一遍覆盖服务器搭建、触摸屏脚本、工控机侧归集和现场故障排查适合正在为“简单文件同步需求要不要做上位机”发愁的自动化工程师。1. 想明白为什么能告别上位机才好决定要不要照做1.1 上位机真正的价值在哪里先把话说清楚我不是否定上位机而是反对把上位机当默认方案。上位机的核心价值在复杂人机交互、大数据量展示、数据库对接和MES集成。比如一个配方管理系统要跟SQL Server对接有几十个界面、多层权限、审批流这种活触摸屏干不了也不应该用本文的土办法。但很多时候客户说“给我做台上位机”细问需求其实就一句话每天把设备报警或者产量表导出来。剩下的大量工作都消耗在通信协议调试、界面布局、打包发布、后期维护上。尤其项目交付之后现场操作员根本不用上位机的花哨界面他们只想知道今天的报表在哪。与其维护一套独立的PC程序不如让本来就长在设备上的触摸屏把文件送出来。1.2 适合这套方案的需求特征我根据自己的项目经历梳理出几个适合用“触摸屏FTP”替代上位机的特征设备端能产生文件。比如报警记录、历史曲线、产量累计、配方参数触摸屏已经把这些数据存成了CSV或自定义格式文件。目标很单纯把文件固定搬运到一台集中电脑上不要求实时刷新分钟级延迟完全能接受。现场网络结构简单。触摸屏和服务器在同一网段或者能通过网关路由互通不需要跨公网做复杂转发。后续处理不复杂通常是在工控机侧合并报表、做Excel统计或者作为MES系统的数据源。只要有一条不满足比如要求毫秒级实时同步或者需要直接写数据库就别硬套这套方案。技术选型永远先看需求边界而不是看哪个方案新潮。1.3 一个更具体的落地案例前年我做的一个项目很有代表性车间里6台压铸机每台前面一块MCGS TPC7062触摸屏报警和班产量都存在触摸屏本地每天班组长要汇总六台设备的数据。按老套路得在办公室配一台工控机装一套上位机软件通过Modbus TCP去挨个轮询PLC再拼报表。当时光协议联调就耗了两周后面客户改表头还要重新发版。那次我换了个思路不碰PLC直接让每块触摸屏把自己的CSV文件定时推到工控机FTP目录工控机上一个简单脚本把6份CSV合并成一份日报。结果半天跑通客户拿到Excel自己就能做透视表。后来客户提需求也只找现场电工根本不用找我们改软件。这个案例让我彻底认识到很多“上位机需求”本质上只是文件搬运需求。2. 组网和准备先把三台设备的身份定清楚2.1 两种拓扑选型我见过两类常见做法区别是文件最终存在谁那里。第一种触摸屏→FTP服务器FTP服务就建在工控机上。触摸屏主动连接并将文件上传工控机磁盘目录直接变成汇聚盘。适合现场只有一台工控机、文件最终供办公室使用的情况也是最省资源的做法。第二种触摸屏和工控机都作为FTP客户端共同指向一台中央FTP服务器。适合工控机本身也需要移动、或者多个车间共用服务器的情况。此时工控机侧再配置一个计划任务从中央服务器拉数据或者反过来把本地文件推上去。两种方案的核心逻辑一致触摸屏永远是FTP客户端主动发起连接把变化的文件传上去。这样设计是因为触摸屏作为嵌入式设备很难在主动模式下被服务器反向连接而客户端主动连接对防火墙和NAT最友好。2.2 网络参数规划设计强烈建议所有设备都用固定IP别依赖DHCP否则服务器换IP后触摸屏全部失联。我常用的一套规划是这样的角色设备IP规划FTP服务端工控机/办公室PC192.168.1.10触摸屏1MCGS TPC7062192.168.1.21触摸屏2MCGS TPC1061Ti192.168.1.22网络交换机企业级8口以上与PLC网络隔离或VLAN如果现场PLC也是以太网通信建议把触摸屏、工控机的网段与PLC网段做隔离或规划好子网避免IP冲突。跨网段时触摸屏侧必须正确配置网关否则数据包只能在本地子网转悠根本到不了FTP服务器。2.3 MCGS触摸屏的硬件与软件条件不是所有MCGS触摸屏都能这么用。得带网口且系统里提供了FTP相关脚本函数。TPC系列大多数嵌入式版本都可以老式串口屏不行。在MCGS组态环境里建工程时最好选择支持网络功能的版本编译后通过网口下载工程这样触摸屏本身才能作为一个网络节点工作。触摸屏的IP地址、子网掩码、网关一般在启动画面或者系统设置里配置。有些型号支持在组态环境中预置下载工程时一并写入。我个人的经验是优先在触摸屏系统设置里手动配置避免组态工程被覆盖后网络参数被重置。3. FTP服务器搭建细节我为什么一直用FileZilla Server3.1 选型对比FileZilla Server vs IIS FTP vs Serv-U工控机上搭FTP服务器我试过几种方案简单对比一下方案安装复杂度被动端口配置维护体验适合场景FileZilla Server低绿色轻量图形界面直观轻量稳定工业现场绝大多数场景IIS FTP需开启系统功能配置绕藏在FTP防火墙支持里依赖IIS组件企业强制只允许微软方案Serv-U中等商业授权功能全更适合大用户量多租户复杂权限企业场景我推荐FileZilla Server核心原因是它和MCGS触摸屏的兼容性最好。触摸屏作为FTP客户端几乎必然走被动模式FileZilla在设置界面里点几下就能指定被动端口范围而IIS的被动端口配置位置不在常规意识里很多人容易漏。3.2 FileZilla Server安装与用户权限配置安装步骤本身没什么技术含量重点在配置从官方渠道下载Windows版安装时保持默认的监听端口和服务器端口21管理界面端口默认14147。启动管理界面第一次连接本机管理服务用安装时设置的密码登录。进入Users区域点击Add添加一个专用账号比如dev01密码不要跟Windows账户混用。设置Home directory为D:\FTPData并且在下面按设备建子目录比如D:\FTPData\device01。权限部分触摸屏要上传文件必须勾选Files的Write权限如果后续还要下载配方需要Read权限如果上传成功后想在触摸屏侧删除本地文件那是触摸屏本地操作不依赖服务器权限。在Server设置 - Passive mode settings里勾选Use custom port range填50000-50100。把FileZilla服务设为Windows服务并自动启动避免工控机重启后FTP服务不跑。这里有个很容易忽视的细节如果在同一个FTP账号下触摸屏既上传又下载权限最小化原则下不要勾选Delete权限防止脚本误删服务器文件。但有个别场景比如触摸屏想在上传后删除远端旧文件那就要给Delete权限权衡好风险再开。3.3 Windows防火墙与被动端口配置这是现场报错率最高的一环尤其“FTP无法与服务器建立连接”。标准配置分两步第一步放行FTP控制端口TCP 21。在Windows防火墙新建入站规则选择端口填入21允许连接。第二步放行被动数据传输端口。如果FileZilla里设置了50000-50100就再建一条入站规则放行这个端口段。没有第二步触摸屏往往能打开FTP连接但文件传输时会卡住或直接失败。如果现场有硬件防火墙或者路由ACL还要在设备上同步放行。工业项目中建议限制来源IP例如只允许192.168.1.0/24网段访问FTP端口拒绝其他网段能明显降低无谓暴露风险。测试顺序很重要先在服务器本机命令行执行ftp 127.0.0.1验证服务本身再用一台普通PC去连服务器测试上传下载最后才让触摸屏去连。按这个顺序排查能把问题快速缩小到防火墙还是触摸屏侧配置。3.4 IIS FTP的备选配置如果厂里有硬性规定不允许安装第三方服务器软件Windows自带IIS也能实现。简要步骤控制面板 - 程序和功能 - 启用或关闭Windows功能勾选“Internet Information Services”下的“FTP服务器”包括FTP服务和FTP扩展性以及Web管理工具。以管理员身份打开IIS管理器右键“网站”选择“添加FTP站点”。填写站点名称物理路径指向D:\FTPData绑定服务器IP端口用21SSL选项内网可以选无。身份验证选基本授权规则中选择指定用户并勾选“读取”和“写入”。被动端口的设置在IIS里比较隐蔽站点级别有一个“FTP防火墙支持”配置页在这里填数据通道端口范围同时防火墙放行这些端口。IIS方案不是不能用但配置分布较为分散排查时需要多翻几个页面。内网项目图省心的话FileZilla会合适得多。4. MCGS触摸屏侧实现自动上传脚本怎么写函数怎么调4.1 触摸屏FTP脚本的运行逻辑MCGS触摸屏实现定时上传通常走“运行策略”里的“循环策略”。它的执行机制是系统按设定周期反复执行一段脚本脚本检查本地数据目录里是否有新文件如果有就调用FTP相关函数把文件传到服务器。这个“检查文件”的动作不同版本实现方式有差异有的通过枚举目录下的文件名有的通过比对文件修改时间。但脚本主体逻辑是固定不变的连接FTP - 定位远程目录 - 上传文件 - 断开连接 - 记录状态。4.2 一个可参考的循环脚本骨架考虑到MCGS不同版本脚本函数名有差异我不打算把某一条命令当成标准但核心逻辑可以分享。下面这段是参考示例参数顺序基本围绕“服务器IP、用户名、密码、本地路径、远程路径”来组织 循环策略示例设定周期300秒 Dim ret As Integer Dim localFile As String Dim remoteDir As String localFile /avtdata/alarm_20240924.csv remoteDir /device01/20240924/ ret FtpUpload(192.168.1.10, dev01, pass123, localFile, remoteDir) If ret 0 Then 上传成功删除本地文件释放存储 Kill localFile Else 上传失败计数并产生画面报警 FailCount FailCount 1 End If这里有几个细节要提醒。第一函数名必须以你所用MCGS软件自带的命令手册为准不同版本可能叫FtpUpload也可能叫FTPFileUpload甚至参数顺序都有差异。我习惯先把函数手册打印出来放桌上现场调试时对照着写。第二上传成功后是否删除本地文件取决于需求。我建议保留一份本地副本至少一天发现同步异常时还能补救存储吃紧再清理。第三失败计数变量可以绑定到画面上连续几次失败后弹出报警提示这样现场人员不用打开工程就知道同步断了。4.3 周期设多少合适循环周期建议和文件生成频率匹配。如果是每班结束才生成一份产量表那每小时检查一次都够如果是报警记录希望尽快汇总可以设1到5分钟。我一般取5分钟既能及时发现新文件又不会给FTP服务器和网络造成无谓压力。设得太短FileZilla的连接日志每几分钟刷一屏出问题时反而不好定位。设得太长现场急要数据时又显得迟钝。4.4 文件命名与时间戳处理文件名强烈建议用纯ASCII比如20240924_0730_shift1.csv。原因很现实FTP服务端字符编码不统一时中文文件名容易变成乱码甚至直接上传失败。我在IIS和FileZilla上都碰到过中文路径问题后来统一改成英文数字命名再没出过这种问题。MCGS脚本中拼接文件名时注意系统时间字符串可能是定长字符串比如月份是09而不是9直接拼接没问题。但如果用了某些字符串函数结果可能带着尾部空格生成的文件名就是20240924_0730_shift1 .csv后端脚本在处理时会很痛苦。稳妥做法是拼接后对字符串做一次去除首尾空格的处理。4.5 反向同步从FTP服务器下发配方文件同步不止是上传还能反向做配方下发。比如班组长在办公室把当天的配方文件放到FTP服务器的/device01/recipe/目录触摸屏在循环脚本里定期检查该目录发现新文件就下载覆盖本地配方然后提示操作员确认重启。实现逻辑和上传相反把FtpUpload换成下载函数即可。关键是要解决“重复下载”问题最简单的办法是下载成功后删除远端文件或者把文件名改掉作为已处理标记。这个思路对需要快速换产的小型生产场景很实用省去了现场人拿U盘一个个插触摸屏拷贝的麻烦。5. 工控机侧的文件归集不装上位机也能同步5.1 方案一工控机作为FTP服务器直接收这是最贴近标题的方案。工控机安装并运行FileZilla Server触摸屏把文件传到D:\FTPData。工控机上不需要任何上位机界面只需要一个后台脚本监控目录变化有新增文件就移动到汇总目录或者直接抛给后端系统处理。示例PowerShell脚本可以这样写$watcherPath D:\FTPData $processedPath D:\FTPData\Processed while ($true) { $files Get-ChildItem -Path $watcherPath -Filter *.csv | Where-Object { $_.LastWriteTime -gt (Get-Date).AddMinutes(-5) } foreach ($f in $files) { Copy-Item $f.FullName -Destination D:\ReportMerge Move-Item $f.FullName -Destination $processedPath } Start-Sleep -Seconds 60 }把这段存成monitor.ps1再做一个计划任务开机运行即可。它的逻辑很直白每分钟扫描一次目录把最近5分钟内出现的新CSV复制到合并目录避免同一条数据被重复处理。这样做的好处是即便触摸屏连续传了多个文件工控机侧也能按时间窗口准确捕捉。5.2 方案二WinSCP命令行同步如果工控机不是FTP服务器而是从另一台中央FTP服务器拉文件推荐WinSCP的命令行模式。WinSCP本身是图形工具但有个winscp.com命令行程序非常适合做无人值守同步。下面是一个批处理示例echo off set YY%date:~0,4% set MM%date:~5,2% set DD%date:~8,2% E:\tools\WinSCP\WinSCP.com /command ^ open ftp://dev01:pass123192.168.1.10/ ^ synchronize local D:\Data /device01/%YY%%MM%%DD% ^ exitsynchronize local会把远端目录里比本地新的文件拉下来并按日期子目录归位。把这个bat在任务计划程序里每5分钟跑一次即可实现工控机侧的自动同步同样不需要上位机。有一点要注意WinSCP首次连接会提示保存主机密钥无人值守模式下建议用参数或配置文件提前固定否则计划任务运行到一半会卡在确认提示上。5.3 方案三纯PowerShell 系统自带FtpWebRequest有些现场装了软件白名单不能安装FileZilla Server也不能装WinSCP。这种情况下PowerShell自带的FtpWebRequest能顶上去不需要额外装任何东西。下载单个文件的示例$remoteFile ftp://192.168.1.10/device01/20240924/data.csv $ftpReq [System.Net.FtpWebRequest]::Create($remoteFile) $ftpReq.Credentials New-Object System.Net.NetworkCredential(dev01,pass123) $ftpReq.Method [System.Net.WebRequestMethodsFtp]::DownloadFile $ftpReq.UsePassive $true $ftpReq.UseBinary $true $resp $ftpReq.GetResponse() $stream $resp.GetResponseStream() $local [System.IO.File]::Create(D:\Data\data.csv) $stream.CopyTo($local) $local.Close() $stream.Close() $resp.Close()注意UsePassive $true这行它和FileZilla被动模式正好对应。如果设成主动模式工控机在NAT后很可能连不通。实际的目录列表循环下载会复杂一些但核心用法就是这一套。这个方案的缺点是脚本要自己维护不如WinSCP的synchronize智能胜在零依赖。5.4 计划任务与开机自启不管是PowerShell脚本还是WinSCP批处理都需要定时触发。我推荐用Windows任务计划程序而不是简单塞进启动文件夹。任务计划程序支持设周期、补跑、失败重试日志也更清晰。创建命令示例schtasks /create /tn FTPSync /tr powershell -ExecutionPolicy Bypass -File D:\scripts\sync.ps1 /sc minute /mo 5 /ru SYSTEM如果希望开机后马上执行一次可以把触发器改为“计算机启动时”。这里有个坑任务计划程序用SYSTEM账户运行时PowerShell脚本访问映射网络驱动器有时不可见。解决办法是脚本里直接用UNC路径或者物理路径不要依赖盘符映射。我在调试时遇到过脚本放在D盘没问题、一旦计划任务用SYSTEM跑就找不到路径的怪事后来改成绝对路径才解决。6. 实测中的故障清单与排查顺序6.1 触摸屏报“无法与服务器建立连接”这个报错我见得最多但问题往往不在FTP服务本身。按照下面的顺序排查效率最高在办公室电脑上用命令行ftp 192.168.1.10连接服务器账号密码验证是否能登录。如果本机也连不上问题在FileZilla服务或端口监听。从触摸屏所接的交换机端口ping服务器IP。不要从办公室PC ping因为你ping的是另一条链路现场可能已经断开。临时关闭服务器Windows防火墙再测试能连上就确定是防火墙拦截然后补规则。检查FileZilla被动端口范围与防火墙放行端口是否一致一个数字对不上都会失败。检查触摸屏网关。服务器和触摸屏跨网段时触摸屏没配置网关一定连不通。需要特别提醒防火墙临时关闭只用于测试测完立刻恢复不要图省事一直开着。6.2 能登录但上传总失败或中途卡死这类问题十有八九出在数据连接上。FTP有两个连接控制连接走21端口数据连接在主动模式下走20端口被动模式下走一段高位端口。FileZilla配置了50000到50100那就必须在防火墙里放行这段端口否则控制连接建立成功数据连接建不起来。如果中间还有企业防火墙或路由器ACL也要同步放行。用FileZilla日志能看得很清楚如果日志停在LIST或者STOR命令基本就是数据端口被拦。上传大文件时卡住通常也是数据连接超时。6.3 文件上传了但文件名乱码或带空格中文文件名建议直接放弃这是我在两个FTP服务器上都验证过的教训。服务器默认字符集和MCGS组态环境不一定是同一种编码中文在传输过程中很可能变成乱码后端程序按名字匹配时会彻底失效。如果你用MCGS脚本拼文件名还要留意定长字符串问题。组态软件里字符串变量往往是固定长度比如10个字符实际内容20240924只占了8个后面跟着空格。截取后直接当文件名文件就变成20240924 .csv。写脚本时最好调用字符串去空格函数或者用带参数格式化的方式生成。6.4 防火墙规则看起来没错但还是连不上出现这种情况先看Windows网络配置文件的类型。工控机网卡可能被识别为“公用网络”而防火墙规则只启用了“域”或“专用”两边对不上规则等于没写。创建入站规则时最好把域、专用、公用三个配置文件都勾上或者把作用域限制为指定的IP网段这样更可控。我整理过一个快速故障对照表方便现场排查故障现象最可能原因检查点无法连接21端口防火墙未放行/服务未启动本机ftp 127.0.0.1能登录但LIST卡住被动端口未放行FileZilla日志大文件传一半失败被动端口范围太小50000-50100完整放行上传乱码文件名中文改ASCII命名计划任务不执行触发器或账户权限查看任务计划历史记录跨网段不通触摸屏网关错误ping服务器网关到了现场我一般直接打开FileZilla的日志窗口把一次失败过程的完整截图拿下来基本能定位80%的问题。日志里每个命令都有返回码稍微会看就能推断出是认证失败、权限不足还是数据连接失败。7. 从能用到好用产品化之前要补的几个点7.1 断线重试与失败可见性现场网络不可能一直稳触摸屏脚本里要做失败计数。我的习惯是连续失败3次就在触摸屏画面上弹一个报警变量同时把失败次数写入本地日志。否则某个夜班网络断了第二天白班才发现同步已经断了一整夜数据补起来很麻烦。工控机侧脚本也要输出运行日志。PowerShell脚本里可以加一行写文本的语句把每次同步的起始时间、文件数、结果追加到D:\Logs\sync.log。这个文件在项目验收时也是很好的凭证。7.2 上传后的清理与磁盘规划触摸屏如果只上传不清理本地存储迟早写满。建议上传成功后删除本地文件或者保留固定天数。服务器端同理按设备/日期建目录后安排一个计划任务定期删除超过比如90天的旧文件或者迁移到冷备份目录。工业现场最常见的中期故障就是磁盘满。FTP服务器磁盘满了之后触摸屏会收到写入失败但表面看连接正常最迷惑人。所以服务器磁盘空间监控比功能本身还重要建议直接把磁盘剩余容量报警做到脚本里。7.3 内网数据安全FTP本身是明文协议在完全隔离的车间内网运行问题不大。如果工控机所在网络能连办公网甚至外网就要认真对待。我建议至少做三件事FTP账号单独建不要用Administrator这类Windows账号权限严格限制到对应设备的子目录。密码定期更换触摸屏脚本端的密码也要同步更新可以提前在画面上做一个修改密码入口。如果MCGS版本支持FTPS就启用TLS如果不支持在交换机上把HMI和工控机单独划分VLAN并且禁止该VLAN访问外网。最后说点个人感受。这套东西最难的不是技术而是打破“文件同步必须写上位机”的惯性。我第一次完整搭完设好FileZilla被动端口在MCGS里写了十几行脚本5分钟真就全通了。后来这个思路被我用到好几个项目里客户从最初质疑“触摸屏还能干这个”到后面催着让我教他们员工改报表。如果你手上正好有一个“看着只需要上位机、但细想只是传文件”的需求我建议你先打开MCGS的函数手册翻一翻FTP相关功能再决定要不要写那套C#界面。省下来的时间通常足够你提前一周把项目交付掉。