简介这份资源面向工业自动化工程师、PLC编程学习者及需要打通控制系统与数据库的开发者聚焦西门子S7-1200与SQL Server之间的数据集成问题。内容围绕PLC编程、以太网通信配置、数据库表结构设计、通信方式选型以及自定义应用程序编写等环节展开帮助读者理解如何将现场采集的数据稳定写入关系型数据库并实现查询与指令回传。资源包共19个文件约8.73MB以9个png截图、5个xml配置文件为主另含xsl、plf、pma、idx及ap13等工程与索引文件可用于还原TIA项目结构、查看配置示例与运行日志。目前已有4839人学习下载适合希望掌握S7-1200与SQL Server通信思路、对照工程文件排查连接与数据映射问题的读者参考。1. 把 S7-1200 的产线数据写进 SQL Server一条被低估的落地路径很多做产线自动化的工程师都遇到过这个场景S7-1200 跑得好好的工艺参数、节拍、报警记录全在 PLC 里但管理层要看报表、质量部要做追溯、工艺要跑趋势分析数据就是出不来。常见的做法是加一台工控机跑组态软件再靠脚本往数据库里倒中间多一层就多一个故障点。其实 S7-1200 本身带以太网口支持标准 TCP 通信完全可以让它直接和 SQL Server 对话——PLC 侧用 TCON、TSEND、TRCV 这几个指令建连接、发数据上位机侧写一个轻量服务接收并入库。这条路我走过几个项目稳定运行两年以上的有翻车重来的也有。它适合谁适合手上有 S7-1200、需要把产线数据落到关系型数据库、又不想被组态软件绑死的现场工程师。下面把选型、组态、代码、参数和坑一次讲透。2. 为什么不让 PLC 直连数据库三种架构的取舍2.1 直连、中间件、OPC UA 三条路对比先把架构选清楚后面写代码才不会反复推翻。S7-1200 连接 SQL Server业内常见三种做法架构数据路径优点缺点适用场景PLC 直连PLC → TCP → 上位机服务 → SQL Server链路短、延迟低、无额外授权PLC 侧要写通信逻辑上位机要常驻服务数据点少、实时性要求高中间件/组态PLC → 组态软件 → 数据库组态自带驱动配置简单授权成本、中间层故障点多点数多、已有组态平台OPC UAPLC → OPC UA Server → 客户端 → 数据库标准化、跨厂商S7-1200 需授权且配置复杂多品牌设备统一采集我一般推荐直连方案原因很直接S7-1200 的开放式通信指令足够用不需要额外授权链路里少一个软件就少一个半夜打电话的理由。代价是 PLC 侧要自己管连接状态和数据缓冲这部分后面会重点讲。2.2 S7-1200 侧需要哪些指令和组态直连方案在 PLC 侧依赖四个指令TCON 建立连接、TDISCON 断开、TSEND 发数据、TRCV 收数据。它们都在「开放式用户通信」指令库里走的是标准 TCP不依赖任何专用协议。组态步骤在 TIA Portal 里打开 S7-1200 的设备视图确认以太网口已分配 IP且和上位机在同一网段。在「保护与安全」里勾选「允许来自远程对象的 PUT/GET 通信访问」——注意这条主要影响 S7 通信但现场经常因为安全设置把开放式通信一起挡了排查时先看这里。不需要在硬件组态里额外添加连接TCON 是在程序里动态建连的。确认 PLC 固件支持开放式通信指令S7-1200 各主流固件版本都支持具体以手头硬件为准。提示PLC 和上位机必须在同一网段跨网段要走路由且防火墙要放行你选定的端口。这一步没做后面所有代码都是白写。2.3 上位机侧为什么用常驻服务而不是脚本上位机侧要干两件事监听端口收 PLC 发来的数据解析后写入 SQL Server。很多人第一反应是写个 Python 脚本定时读但 PLC 是主动推送的脚本轮询对不上节奏。正确做法是写一个常驻的 TCP 服务收到数据就入库。用 Python 的 socket pyodbc 就够了不需要重型框架。服务要处理三件事并发连接可能有多台 PLC、粘包拆包TCP 是字节流没有消息边界、断线重连PLC 重启后要能重新连上。这三点在后面的代码里都会体现。3. 从 TIA Portal 组态到 Python 服务最小可跑通链路3.1 PLC 侧 TCON 建连的参数怎么填先看 PLC 侧的建连代码。下面是一段典型的 TCON 调用用 SCL 写// 建立到上位机的 TCP 连接 // 上位机 IP: 192.168.0.100监听端口: 2000 TCON_DB( REQ : StartConnect, // 上升沿触发建连 ID : 1, // 连接 ID后续 TSEND/TRCV 复用 CONNECT : TCP_Config, // 连接参数结构体 DONE ConnectDone, BUSY ConnectBusy, ERROR ConnectError, STATUS ConnectStatus );连接参数结构体TCP_Config需要填这些字段参数含义典型值InterfaceId本地接口硬件标识由 TIA 自动带出不要手改ID连接编号1和 TCON 的 ID 一致ConnectionType连接类型16#0B 表示 TCPActiveEstablished主动/被动TRUE 表示 PLC 主动连上位机RemoteAddress上位机 IP192.168.0.100RemotePort上位机端口2000LocalPort本地端口0 表示自动分配逻辑说明REQ必须用上升沿触发不能一直给 TRUE否则 TCON 会反复尝试。ActiveEstablished : TRUE意味着 PLC 是客户端上位机是服务端这符合「上位机常驻监听」的架构。ID是这条连接的身份证后面 TSEND 和 TRCV 都用同一个 ID填错了就连不上或者发错通道。参数说明RemotePort要和上位机服务监听的端口完全一致差一位都不行。LocalPort填 0 让系统自动分配除非现场有端口白名单要求否则不要固定。3.2 TSEND 发数据缓冲区、长度和触发方式连接建好后用 TSEND 把数据发出去// 发送数据到上位机 TSEND_DB( REQ : SendTrigger, // 上升沿触发发送 ID : 1, // 与 TCON 的 ID 一致 DATA : SendBuffer, // 发送数据区 LEN : 64, // 发送字节数 DONE SendDone, BUSY SendBusy, ERROR SendError, STATUS SendStatus );逻辑说明DATA指向一个数据块里面按约定格式排好要发的数据。LEN是实际发送的字节数必须和上位机解析的格式严格对应。REQ同样用上升沿如果一直给 TRUETSEND 会在 BUSY 结束后立刻重发造成数据洪水。参数说明LEN的单位是字节。如果你发的是 8 个 REAL每个 4 字节LEN 就是 32。上位机侧要按同样的字节序解析S7-1200 默认是大端序Python 解析时要用f而不是f这是新手最容易翻车的地方。3.3 上位机 Python 服务收包、拆包、入库上位机侧的服务代码import socket import struct import pyodbc import threading # SQL Server 连接串按现场实际改 CONN_STR ( DRIVER{ODBC Driver 17 for SQL Server}; SERVER192.168.0.200; DATABASELineData; UIDsa;PWDYourPassword ) def parse_and_save(raw: bytes): 解析 PLC 发来的 64 字节数据并入库 # S7-1200 默认大端序用 开头 # 假设格式4 个 REAL 1 个 DINT 剩余填充 values struct.unpack(fff fi, raw[:20]) temp, pressure, speed, count values[0], values[1], values[2], values[3] conn pyodbc.connect(CONN_STR) cursor conn.cursor() cursor.execute( INSERT INTO dbo.ProductionData (Temp, Pressure, Speed, Count, RecvTime) VALUES (?, ?, ?, ?, GETDATE()), temp, pressure, speed, count ) conn.commit() cursor.close() conn.close() def handle_client(conn: socket.socket, addr): 处理单个 PLC 连接解决粘包问题 buffer b EXPECTED 64 # 每条消息固定 64 字节 while True: try: chunk conn.recv(1024) if not chunk: break buffer chunk # 按固定长度拆包不足则等待下一批 while len(buffer) EXPECTED: frame buffer[:EXPECTED] buffer buffer[EXPECTED:] parse_and_save(frame) except Exception as e: print(f连接异常 {addr}: {e}) break conn.close() def start_server(host0.0.0.0, port2000): server socket.socket(socket.AF_INET, socket.SOCK_STREAM) server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) server.bind((host, port)) server.listen(5) print(f监听 {host}:{port}) while True: conn, addr server.accept() threading.Thread( targethandle_client, args(conn, addr), daemonTrue ).start() if __name__ __main__: start_server()逻辑说明handle_client里的buffer是解决粘包的关键。TCP 不保证一次 recv 就是一条完整消息可能两条粘在一起也可能一条被拆成两次。用固定长度 64 字节做边界攒够就拆一帧这是最简单可靠的方案。struct.unpack的格式串fff fi里表示大端序f是 4 字节浮点i是 4 字节整数空格只是可读性分隔不影响解析。参数说明CONN_STR里的驱动名要和上位机实际安装的 ODBC 驱动一致装的是 17 就写 17。EXPECTED必须和 PLC 侧 TSEND 的LEN完全相等改一个就要改另一个。SO_REUSEADDR让服务重启时端口能立刻复用不然会报「地址已占用」。3.4 建表语句和字段类型对应SQL Server 侧的建表语句CREATE TABLE dbo.ProductionData ( Id BIGINT IDENTITY(1,1) PRIMARY KEY, Temp REAL, -- 对应 PLC 的 REAL Pressure REAL, Speed REAL, Count INT, -- 对应 PLC 的 DINT RecvTime DATETIME DEFAULT GETDATE() ); CREATE INDEX IX_RecvTime ON dbo.ProductionData(RecvTime);逻辑说明PLC 的 REAL 对应 SQL Server 的 REAL都是 4 字节浮点DINT 对应 INT。不要用 FLOATFLOAT 是 8 字节虽然能存但浪费空间且类型不匹配容易引起困惑。RecvTime用GETDATE()默认值入库时不用手动传。参数说明IX_RecvTime索引是给追溯查询用的按时间范围查数据时没有索引会全表扫描。数据量大之后这个索引很关键。4. 避坑指南连接、字节序、断线重连的五个血泪教训4.1 现象TCON 一直报错 8090 或连接不上原因最常见的是上位机防火墙没放行端口其次是 PLC 和上位机不在同一网段再其次是 TCON 的REQ一直给 TRUE 导致反复建连把资源耗尽。解决先在 PLC 侧用在线诊断看 TCON 的 STATUS 值8090 一般是连接资源问题。然后在上位机用telnet 192.168.0.100 2000测端口通不通。最后检查REQ是不是用了上升沿。这三步能解决八成建连失败。4.2 现象数据能收到但全是乱码或数值离谱原因字节序搞反了。S7-1200 是大端序Python 默认按本机字节序解析x86 是小端序不解就是天文数字。解决struct.unpack的格式串必须以开头。如果收到的是1.0却解析成4.6e-41这种百分之百是字节序问题。另外确认 PLC 侧发的是 REAL 还是 DINT类型对不上也会乱。4.3 现象运行几小时后服务卡死或数据断流原因PLC 重启或网络抖动后旧连接没释放新连接又建不上服务端 socket 句柄泄漏。解决在handle_client里加超时conn.settimeout(30)超时就断开重来。PLC 侧 TDISCON 要在连接异常时主动调用清理旧连接。上位机服务用daemonTrue的线程主进程退出时能一起收掉。4.4 现象数据偶尔丢一条或重复入库原因TSEND 的 DONE 和上位机的 recv 不同步或者拆包逻辑在边界情况下出错。解决在数据里加一个递增的序列号字段上位机入库前比对序列号跳号说明丢了重复说明粘包没拆干净。序列号放在发送缓冲区的前 4 字节解析时先取出来。4.5 现象SQL Server 连接偶尔超时导致数据积压原因每次入库都新建连接高频写入时连接池耗尽或网络延迟累积。解决用连接池或者把入库改成批量提交——攒 100 条或每 5 秒提交一次。pyodbc 本身不带连接池可以用pyodbc.pooling True开启或者自己维护一个长连接加锁复用。5. 让这条链路真正扛住产线批量入库与心跳保活的实战技巧前面跑通的是最小链路放到真实产线上还要解决两个问题写入吞吐和连接可靠性。先说批量入库。产线节拍快的时候每秒可能来几十条数据逐条 INSERT 会把 SQL Server 的连接开销放大。我的做法是在服务里加一个队列收包线程只管往队列里塞另起一个入库线程每 200 毫秒或攒够 50 条批量提交一次import queue import time data_queue queue.Queue(maxsize10000) def batch_writer(): 批量入库线程攒够或超时即提交 conn pyodbc.connect(CONN_STR) cursor conn.cursor() batch [] last_flush time.time() while True: try: item data_queue.get(timeout0.2) batch.append(item) except queue.Empty: pass # 攒够 50 条或超过 0.5 秒就提交 if len(batch) 50 or (time.time() - last_flush 0.5 and batch): cursor.executemany( INSERT INTO dbo.ProductionData (Temp, Pressure, Speed, Count) VALUES (?, ?, ?, ?), batch ) conn.commit() batch.clear() last_flush time.time()逻辑说明executemany比循环单条 INSERT 快一个数量级因为它把多条语句合并成一次网络往返。maxsize10000是防止上位机入库慢时内存无限增长队列满了就丢最老的或者阻塞按现场策略选。参数说明攒批的阈值 50 条和 0.5 秒要按实际数据量调。数据稀疏时靠超时提交保证实时性数据密集时靠条数提交保证吞吐。再说心跳保活。PLC 和上位机之间的 TCP 连接如果长时间没数据中间的网络设备可能悄悄断开。解决办法是 PLC 侧定时发一个心跳包上位机收到就更新最后活跃时间超时没收到就主动断开等重连。心跳包可以就用一个固定的短帧比如 4 字节的魔数上位机识别到就不入库只刷新时间。最后说验证方法。链路跑起来后别只看「有数据」要做三件事一是拔掉网线等 30 秒再插上看能不能自动恢复二是把 PLC 断电重启看上位机服务是否还活着并能接受新连接三是在 SQL Server 里按时间范围查数据确认没有大段空洞。这三关过了这条链路才算真正能上产线。我自己踩过最深的坑是字节序当年对着满屏乱码查了一下午最后发现就是格式串少写了一个。后来养成的习惯是任何跨平台通信先把字节序和数据类型对齐写进文档再动手写代码。希望帮到你。本文还有配套的精品资源点击获取