简介这份资源是面向工业自动化与上位机开发者的扫码枪网口TCP通讯示例重点解决基恩士扫码枪与计算机之间稳定数据交互的问题。项目以计算机作为服务端、扫码枪作为客户端涵盖连接建立、指令下发触发扫码、条码数据回传等完整流程并封装了可复用的网口通讯基类便于按业务需求扩展数据解析与逻辑处理。包内共51个文件以13个cs源码文件为核心辅以pdb调试符号、exe可执行程序、dll类库、config配置、resx资源及sln解决方案等压缩包约291KB结构紧凑、开箱即用。其中异步重连机制通过定时器检测连接状态在网络中断后自动恢复通讯降低工业现场数据丢失风险。目前已有3993人学习下载适合需要快速实现扫码数据实时采集、参考TCP客户端服务端编程与断线重连思路的开发者。1. 扫码枪网口TCP通讯demo及源码从“插上就能用”到“稳定收得到”很多做产线采集、仓储出入库、门店收银的开发者第一次接触工业扫码枪时都会有一个朴素的想法网口扫码枪不就是插上网线、配个 IP然后像串口一样读数据吗真上手才发现扫码枪的 TCP 通讯和普通 Socket 编程之间隔着一层“设备语义”——它可能是服务端也可能是客户端它可能只在触发时吐一串字节也可能持续广播它可能用回车换行结尾也可能用 STX/ETX 包起来。扫码枪网口TCP通讯demo及源码这个标题讲的正是把这层语义用最小可运行代码固定下来让扫码枪和上位机通过 TCP 建立连接把条码内容稳定、可解析地拿到业务层。它适合做 MES、WMS、分拣线、门店 POS 的工程师也适合刚接触工业设备通讯、想先跑通再优化的新手。下面我按“先跑通、再讲清、最后避坑”的顺序把一套可复现的方案拆开。2. 先分清扫码枪是服务端还是客户端TCP 角色选型与最小连通2.1 网口扫码枪的两种工作模式选错方向连不上工业扫码枪的网口通讯常见做法是把它配置成两种角色之一TCP Server扫码枪监听端口上位机主动连它或 TCP Client扫码枪主动连上位机指定的 IP 和端口。这两种模式没有绝对优劣但决定了你代码里谁先 bind、谁先 connect。如果扫码枪是 Server 模式上位机就是 Client。你需要在扫码枪的配置菜单或配置码里设置一个监听端口比如 9004然后上位机用connect去连它。这种模式的好处是扫码枪不依赖上位机是否在线上电就监听适合固定工位、单枪单机的场景。缺点是如果上位机程序重启需要重新连接而且扫码枪的 IP 必须固定否则上位机不知道连谁。如果扫码枪是 Client 模式上位机就是 Server。扫码枪上电后会主动向上位机发起连接你需要在扫码枪里填上位机的 IP 和端口。这种模式适合多枪汇聚到一台工控机的场景上位机只需要监听一个端口哪把枪连上来就处理哪把枪的数据。缺点是扫码枪会不断重连如果上位机没启动它可能一直重试有些型号还会在重试间隔上做文章导致你调试时误以为枪坏了。我一般会先确认扫码枪当前固件支持哪种模式再看现场网络拓扑如果扫码枪和上位机在同一个交换机下且上位机是固定工控机优先用扫码枪做 Client、上位机做 Server这样上位机代码最简单一个accept循环就能接多把枪。如果扫码枪要跨网段或者经过网关那扫码枪做 Server、上位机做 Client 更稳因为上位机主动连可以控制重连节奏。2.2 用 Python 写一个最小 TCP Server先接住扫码枪的第一串字节下面这段代码是我在验证阶段最常用的最小 Server。它不依赖任何第三方库只做三件事监听端口、接受连接、把收到的原始字节打印出来。先别急着解析条码先确认“能收到东西”。import socket import threading HOST 0.0.0.0 # 监听所有网卡方便扫码枪从任意网段连入 PORT 9004 # 与扫码枪 Client 模式里配置的目标端口保持一致 def handle_client(conn, addr): print(f[新连接] {addr} 已接入) try: while True: data conn.recv(1024) # 一次最多收 1024 字节条码通常远小于这个值 if not data: print(f[断开] {addr} 主动关闭) break # 先不做任何解码直接打印十六进制和原始字节方便看结尾符 print(f[原始字节] {data!r}) print(f[十六进制] {data.hex()}) except ConnectionResetError: print(f[异常] {addr} 连接被重置) finally: conn.close() def main(): 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[监听] 0.0.0.0:{PORT} 等待扫码枪接入...) while True: conn, addr server.accept() # 每把枪一个线程避免一把枪阻塞影响其他枪 t threading.Thread(targethandle_client, args(conn, addr), daemonTrue) t.start() if __name__ __main__: main()这段代码的关键参数只有三个HOST用0.0.0.0是为了让工控机多网卡都能被扫码枪连上PORT必须和扫码枪 Client 配置里的目标端口完全一致常见的是 9004、9100、5000 这类recv(1024)的缓冲区大小对条码来说足够但如果你后面要收图片或大批量数据需要改成 4096 或更大。SO_REUSEADDR是血泪经验调试时频繁重启程序不加这个选项会报“Address already in use”等一分钟才能再启动。运行后用扫码枪扫一个条码你应该能看到类似b1234567890\r\n的输出。如果什么都没看到先检查扫码枪是不是 Client 模式、目标 IP 是不是这台工控机的 IP、端口是不是被防火墙拦了。Windows 上临时关掉防火墙测试是最快的排查手段但生产环境要加例外规则不要直接关。2.3 扫码枪做 Server 时上位机 Client 怎么写才不容易断如果扫码枪是 Server 模式上位机就要主动连它。下面这段 Client 代码加了自动重连和超时避免扫码枪重启后上位机傻等。import socket import time GUN_IP 192.168.1.100 # 扫码枪的固定 IP按现场实际改 GUN_PORT 9004 # 扫码枪监听的端口 RECONNECT_DELAY 3 # 断线后 3 秒重连一次 def connect_and_read(): while True: try: s socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.settimeout(5) # 连接超时 5 秒避免卡死 s.connect((GUN_IP, GUN_PORT)) print(f[已连接] {GUN_IP}:{GUN_PORT}) s.settimeout(None) # 连接成功后切回阻塞模式正常收数据 while True: data s.recv(1024) if not data: print([断开] 扫码枪关闭了连接) break print(f[收到] {data!r}) except (ConnectionRefusedError, socket.timeout, OSError) as e: print(f[重连] 连接失败: {e}{RECONNECT_DELAY} 秒后重试) finally: try: s.close() except Exception: pass time.sleep(RECONNECT_DELAY) if __name__ __main__: connect_and_read()这里settimeout(5)只作用于连接阶段连接成功后必须设回None否则收数据时也会 5 秒超时扫码枪不扫码时就会不断抛异常。RECONNECT_DELAY不要设得太短有些扫码枪在断开后需要几百毫秒才能重新监听设 3 秒比较稳妥。如果现场有多把枪做 Server你需要为每把枪起一个线程或进程不要在一个循环里轮流连否则一把枪断线会拖累其他枪。3. 把原始字节变成业务条码结尾符、编码与触发模式3.1 先看十六进制再决定用 strip 还是正则扫码枪吐出来的数据最容易被忽略的是结尾符。常见的有\r、\n、\r\n也有用\x03ETX或\x00结尾的。如果你直接data.decode().strip()遇到\x00可能去不掉遇到\x03也会留在字符串里。我一般会先打印data.hex()看清楚最后一个字节是什么再决定解析方式。下面是一个解析函数它同时处理\r\n、\r、\n和\x03结尾并且对非 UTF-8 编码做了兜底。def parse_barcode(raw: bytes) - str: # 先去掉常见的结尾控制符注意顺序先 \r\n 再单个 \r 和 \n cleaned raw.rstrip(b\r\n\x03\x00) try: # 工业扫码枪多数输出 ASCII少数支持 UTF-8 中文 return cleaned.decode(utf-8) except UnicodeDecodeError: # 如果不是 UTF-8按 GBK 再试一次国内设备常见 return cleaned.decode(gbk, errorsreplace)rstrip的参数是一个字节集合它会去掉末尾所有属于这个集合的字节所以b123\r\n和b123\n\n都能处理。errorsreplace是为了避免个别乱码导致整个程序崩溃但生产环境最好记录原始字节方便追溯。如果条码本身包含\r或\n比如某些二维码内容就不能用rstrip而应该根据扫码枪配置的固定长度或分隔符来截取这一点在选型时要确认清楚。3.2 触发模式决定你收到的是“一串”还是“一条”扫码枪的触发模式常见有三种手动按键触发、自动感应触发、命令触发。手动按键和自动感应模式下扫一次码通常只发一帧数据帧与帧之间有明显间隔用recv一次就能拿到完整条码。命令触发模式下上位机先发一个触发命令扫码枪再回数据这时候你要注意发送命令和接收数据之间的时序。如果扫码枪配置了“连续扫描”或“同一码重复上传”你可能会在短时间内收到多条相同数据。业务层需要做去重否则同一个包裹会被重复录入。去重可以用“条码内容 时间窗口”的方式比如 500 毫秒内相同条码只处理一次。不要用全局集合永久去重否则同一件商品二次扫码会被误判。另外有些扫码枪支持“前缀/后缀”配置你可以在扫码枪里加一个自定义前缀比如这样上位机收到123456\r\n时就能确认这是完整帧而不是半截数据。这个技巧在多枪并发、网络抖动时特别有用相当于给每帧数据加了一个简易的帧头。3.3 多枪并发时用连接对象区分数据来源当上位机做 Server、多把扫码枪做 Client 时所有数据都从同一个端口进来你必须知道哪条数据来自哪把枪。最直接的办法是在accept时记录addr然后把addr和连接对象绑定后续处理时带上来源标识。clients {} # key: conn, value: addr def handle_client(conn, addr): clients[conn] addr try: while True: data conn.recv(1024) if not data: break barcode parse_barcode(data) # 把来源 IP 和端口一起传给业务层 print(f[{addr[0]}:{addr[1]}] 条码: {barcode}) finally: clients.pop(conn, None) conn.close()如果扫码枪的 IP 是固定的你可以进一步用 IP 来映射工位号比如192.168.1.101对应 1 号打包台。这样业务层不需要额外配置就能知道条码来自哪个工位。注意addr里的端口是扫码枪的临时端口每次重连可能变化所以映射要用 IP不要用端口。4. 避坑与排查扫码枪 TCP 通讯最常见的 5 个翻车现场4.1 能 ping 通但连不上端口现象上位机 ping 扫码枪 IP 是通的但 TCP 连接被拒绝或超时。原因通常有三个扫码枪的 TCP Server 功能没开启或者端口号填错了或者扫码枪只允许特定 IP 连接白名单。解决先用扫码枪配置码确认 TCP Server 已启用端口号与代码一致再用telnet 扫码枪IP 端口测试如果 telnet 不通说明不是代码问题。有些扫码枪默认端口是 9004但配置菜单里显示的是 9005这种玄学差异只能靠翻手册或逐个试。4.2 收到数据但结尾多一个字节现象条码内容正确但字符串末尾多了一个不可见字符导致数据库查询失败。原因扫码枪配置了\r\n结尾但代码只strip()了空格没有去掉\r和\n。解决用rstrip(b\r\n\x03\x00)处理字节而不是先 decode 再 strip。如果条码本身可能以\r结尾那就不能盲目 rstrip要在扫码枪里关掉结尾符改用固定长度解析。4.3 程序重启后端口被占用现象调试时 CtrlC 停掉程序再启动报OSError: [Errno 98] Address already in use。原因TCP 连接处于 TIME_WAIT 状态操作系统默认要等 60 秒才释放端口。解决在bind之前加server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)。这个选项在 Linux 和 Windows 上都有效是调试阶段的后悔药。4.4 扫码枪频繁断连重连现象日志里不断出现“新连接”和“断开”但扫码枪实际没有移动。原因可能是网络抖动也可能是扫码枪的 Client 模式设置了“空闲超时”比如 30 秒没有数据就主动断开。解决先检查交换机端口是否有丢包再确认扫码枪的“心跳”或“保持连接”选项是否开启。如果扫码枪不支持心跳可以在上位机侧定期发一个空包或特定命令维持连接。注意不要发太频繁有些扫码枪会把非条码数据当成触发命令。4.5 多把枪同时上传时数据串了现象A 工位扫的条码显示在 B 工位的记录里。原因多线程处理时共享了同一个缓冲区或全局变量导致数据交叉。解决每个连接独立处理不要把recv到的数据放到全局列表再统一解析。如果业务层需要汇总用队列传递并且每条消息带上来源标识。另外检查扫码枪的 IP 是否重复有些现场用 DHCP重启后 IP 变了映射关系就乱了工业环境建议全部静态 IP。5. 进阶把 demo 变成可上线的小工具以及一个验证习惯5.1 加一层配置文件和日志别把参数写死在代码里demo 跑通后下一步是把 IP、端口、结尾符、编码这些参数抽到配置文件里。我一般用 JSON 或 YAML下面是一个最小配置示例{ server: { host: 0.0.0.0, port: 9004 }, barcode: { strip_bytes: \r\n\x03\x00, encoding: utf-8, fallback_encoding: gbk }, log: { raw_hex: true, file: scanner.log } }strip_bytes用字符串表示代码里再转成字节集合。raw_hex打开后每条原始数据都会以十六进制写入日志方便事后排查是扫码枪发错了还是解析错了。日志文件要按天切割否则长时间运行会占满磁盘。这个配置层不需要多复杂但能让你在现场改参数时不用重新打包程序。5.2 用“回环测试”验证解析逻辑不依赖扫码枪扫码枪不在手边时怎么验证解析代码我习惯写一个回环测试用本地 TCP 客户端模拟扫码枪发送预设的字节序列看服务端解析结果是否符合预期。下面是一个简单的测试脚本import socket import time def fake_gun_send(payload: bytes): s socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect((127.0.0.1, 9004)) s.sendall(payload) time.sleep(0.1) s.close() if __name__ __main__: # 模拟三种常见结尾 fake_gun_send(bABC123\r\n) fake_gun_send(bDEF456\r) fake_gun_send(bGHI789\x03)这个脚本可以快速验证parse_barcode是否把三种结尾都处理干净。你还可以故意发送半截数据比如先发bABC隔 100 毫秒再发b123\r\n看服务端会不会把两段拼成一条。如果会说明你的解析逻辑需要加帧边界判断不能简单依赖一次recv。5.3 一个让我少熬夜的习惯先抓包再改代码最后分享一个习惯当扫码枪和上位机通讯异常时先别改代码用抓包工具看原始 TCP 流。Wireshark 是最常用的过滤条件写tcp.port 9004就能看到扫码枪到底发了什么、上位机回了什么。很多“代码问题”其实是扫码枪配置问题比如它根本没发数据或者发了但目标端口不对。抓包能看到十六进制原始内容比日志更可靠。我遇到过扫码枪配置了\r\n结尾但实际只发\n的情况抓包一看就清楚了省得在代码里反复试。这套方案的核心不是代码多复杂而是把“扫码枪角色、结尾符、编码、多枪区分”这四个变量固定下来。先跑通最小 Server再用十六进制确认数据最后加配置和日志。希望帮到你。本文还有配套的精品资源点击获取
简介这份资源是面向工业自动化与上位机开发者的扫码枪网口TCP通讯示例重点解决基恩士扫码枪与计算机之间稳定数据交互的问题。项目以计算机作为服务端、扫码枪作为客户端涵盖连接建立、指令下发触发扫码、条码数据回传等完整流程并封装了可复用的网口通讯基类便于按业务需求扩展数据解析与逻辑处理。包内共51个文件以13个cs源码文件为核心辅以pdb调试符号、exe可执行程序、dll类库、config配置、resx资源及sln解决方案等压缩包约291KB结构紧凑、开箱即用。其中异步重连机制通过定时器检测连接状态在网络中断后自动恢复通讯降低工业现场数据丢失风险。目前已有3993人学习下载适合需要快速实现扫码数据实时采集、参考TCP客户端服务端编程与断线重连思路的开发者。1. 扫码枪网口TCP通讯demo及源码从“插上就能用”到“稳定收得到”很多做产线采集、仓储出入库、门店收银的开发者第一次接触工业扫码枪时都会有一个朴素的想法网口扫码枪不就是插上网线、配个 IP然后像串口一样读数据吗真上手才发现扫码枪的 TCP 通讯和普通 Socket 编程之间隔着一层“设备语义”——它可能是服务端也可能是客户端它可能只在触发时吐一串字节也可能持续广播它可能用回车换行结尾也可能用 STX/ETX 包起来。扫码枪网口TCP通讯demo及源码这个标题讲的正是把这层语义用最小可运行代码固定下来让扫码枪和上位机通过 TCP 建立连接把条码内容稳定、可解析地拿到业务层。它适合做 MES、WMS、分拣线、门店 POS 的工程师也适合刚接触工业设备通讯、想先跑通再优化的新手。下面我按“先跑通、再讲清、最后避坑”的顺序把一套可复现的方案拆开。2. 先分清扫码枪是服务端还是客户端TCP 角色选型与最小连通2.1 网口扫码枪的两种工作模式选错方向连不上工业扫码枪的网口通讯常见做法是把它配置成两种角色之一TCP Server扫码枪监听端口上位机主动连它或 TCP Client扫码枪主动连上位机指定的 IP 和端口。这两种模式没有绝对优劣但决定了你代码里谁先 bind、谁先 connect。如果扫码枪是 Server 模式上位机就是 Client。你需要在扫码枪的配置菜单或配置码里设置一个监听端口比如 9004然后上位机用connect去连它。这种模式的好处是扫码枪不依赖上位机是否在线上电就监听适合固定工位、单枪单机的场景。缺点是如果上位机程序重启需要重新连接而且扫码枪的 IP 必须固定否则上位机不知道连谁。如果扫码枪是 Client 模式上位机就是 Server。扫码枪上电后会主动向上位机发起连接你需要在扫码枪里填上位机的 IP 和端口。这种模式适合多枪汇聚到一台工控机的场景上位机只需要监听一个端口哪把枪连上来就处理哪把枪的数据。缺点是扫码枪会不断重连如果上位机没启动它可能一直重试有些型号还会在重试间隔上做文章导致你调试时误以为枪坏了。我一般会先确认扫码枪当前固件支持哪种模式再看现场网络拓扑如果扫码枪和上位机在同一个交换机下且上位机是固定工控机优先用扫码枪做 Client、上位机做 Server这样上位机代码最简单一个accept循环就能接多把枪。如果扫码枪要跨网段或者经过网关那扫码枪做 Server、上位机做 Client 更稳因为上位机主动连可以控制重连节奏。2.2 用 Python 写一个最小 TCP Server先接住扫码枪的第一串字节下面这段代码是我在验证阶段最常用的最小 Server。它不依赖任何第三方库只做三件事监听端口、接受连接、把收到的原始字节打印出来。先别急着解析条码先确认“能收到东西”。import socket import threading HOST 0.0.0.0 # 监听所有网卡方便扫码枪从任意网段连入 PORT 9004 # 与扫码枪 Client 模式里配置的目标端口保持一致 def handle_client(conn, addr): print(f[新连接] {addr} 已接入) try: while True: data conn.recv(1024) # 一次最多收 1024 字节条码通常远小于这个值 if not data: print(f[断开] {addr} 主动关闭) break # 先不做任何解码直接打印十六进制和原始字节方便看结尾符 print(f[原始字节] {data!r}) print(f[十六进制] {data.hex()}) except ConnectionResetError: print(f[异常] {addr} 连接被重置) finally: conn.close() def main(): 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[监听] 0.0.0.0:{PORT} 等待扫码枪接入...) while True: conn, addr server.accept() # 每把枪一个线程避免一把枪阻塞影响其他枪 t threading.Thread(targethandle_client, args(conn, addr), daemonTrue) t.start() if __name__ __main__: main()这段代码的关键参数只有三个HOST用0.0.0.0是为了让工控机多网卡都能被扫码枪连上PORT必须和扫码枪 Client 配置里的目标端口完全一致常见的是 9004、9100、5000 这类recv(1024)的缓冲区大小对条码来说足够但如果你后面要收图片或大批量数据需要改成 4096 或更大。SO_REUSEADDR是血泪经验调试时频繁重启程序不加这个选项会报“Address already in use”等一分钟才能再启动。运行后用扫码枪扫一个条码你应该能看到类似b1234567890\r\n的输出。如果什么都没看到先检查扫码枪是不是 Client 模式、目标 IP 是不是这台工控机的 IP、端口是不是被防火墙拦了。Windows 上临时关掉防火墙测试是最快的排查手段但生产环境要加例外规则不要直接关。2.3 扫码枪做 Server 时上位机 Client 怎么写才不容易断如果扫码枪是 Server 模式上位机就要主动连它。下面这段 Client 代码加了自动重连和超时避免扫码枪重启后上位机傻等。import socket import time GUN_IP 192.168.1.100 # 扫码枪的固定 IP按现场实际改 GUN_PORT 9004 # 扫码枪监听的端口 RECONNECT_DELAY 3 # 断线后 3 秒重连一次 def connect_and_read(): while True: try: s socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.settimeout(5) # 连接超时 5 秒避免卡死 s.connect((GUN_IP, GUN_PORT)) print(f[已连接] {GUN_IP}:{GUN_PORT}) s.settimeout(None) # 连接成功后切回阻塞模式正常收数据 while True: data s.recv(1024) if not data: print([断开] 扫码枪关闭了连接) break print(f[收到] {data!r}) except (ConnectionRefusedError, socket.timeout, OSError) as e: print(f[重连] 连接失败: {e}{RECONNECT_DELAY} 秒后重试) finally: try: s.close() except Exception: pass time.sleep(RECONNECT_DELAY) if __name__ __main__: connect_and_read()这里settimeout(5)只作用于连接阶段连接成功后必须设回None否则收数据时也会 5 秒超时扫码枪不扫码时就会不断抛异常。RECONNECT_DELAY不要设得太短有些扫码枪在断开后需要几百毫秒才能重新监听设 3 秒比较稳妥。如果现场有多把枪做 Server你需要为每把枪起一个线程或进程不要在一个循环里轮流连否则一把枪断线会拖累其他枪。3. 把原始字节变成业务条码结尾符、编码与触发模式3.1 先看十六进制再决定用 strip 还是正则扫码枪吐出来的数据最容易被忽略的是结尾符。常见的有\r、\n、\r\n也有用\x03ETX或\x00结尾的。如果你直接data.decode().strip()遇到\x00可能去不掉遇到\x03也会留在字符串里。我一般会先打印data.hex()看清楚最后一个字节是什么再决定解析方式。下面是一个解析函数它同时处理\r\n、\r、\n和\x03结尾并且对非 UTF-8 编码做了兜底。def parse_barcode(raw: bytes) - str: # 先去掉常见的结尾控制符注意顺序先 \r\n 再单个 \r 和 \n cleaned raw.rstrip(b\r\n\x03\x00) try: # 工业扫码枪多数输出 ASCII少数支持 UTF-8 中文 return cleaned.decode(utf-8) except UnicodeDecodeError: # 如果不是 UTF-8按 GBK 再试一次国内设备常见 return cleaned.decode(gbk, errorsreplace)rstrip的参数是一个字节集合它会去掉末尾所有属于这个集合的字节所以b123\r\n和b123\n\n都能处理。errorsreplace是为了避免个别乱码导致整个程序崩溃但生产环境最好记录原始字节方便追溯。如果条码本身包含\r或\n比如某些二维码内容就不能用rstrip而应该根据扫码枪配置的固定长度或分隔符来截取这一点在选型时要确认清楚。3.2 触发模式决定你收到的是“一串”还是“一条”扫码枪的触发模式常见有三种手动按键触发、自动感应触发、命令触发。手动按键和自动感应模式下扫一次码通常只发一帧数据帧与帧之间有明显间隔用recv一次就能拿到完整条码。命令触发模式下上位机先发一个触发命令扫码枪再回数据这时候你要注意发送命令和接收数据之间的时序。如果扫码枪配置了“连续扫描”或“同一码重复上传”你可能会在短时间内收到多条相同数据。业务层需要做去重否则同一个包裹会被重复录入。去重可以用“条码内容 时间窗口”的方式比如 500 毫秒内相同条码只处理一次。不要用全局集合永久去重否则同一件商品二次扫码会被误判。另外有些扫码枪支持“前缀/后缀”配置你可以在扫码枪里加一个自定义前缀比如这样上位机收到123456\r\n时就能确认这是完整帧而不是半截数据。这个技巧在多枪并发、网络抖动时特别有用相当于给每帧数据加了一个简易的帧头。3.3 多枪并发时用连接对象区分数据来源当上位机做 Server、多把扫码枪做 Client 时所有数据都从同一个端口进来你必须知道哪条数据来自哪把枪。最直接的办法是在accept时记录addr然后把addr和连接对象绑定后续处理时带上来源标识。clients {} # key: conn, value: addr def handle_client(conn, addr): clients[conn] addr try: while True: data conn.recv(1024) if not data: break barcode parse_barcode(data) # 把来源 IP 和端口一起传给业务层 print(f[{addr[0]}:{addr[1]}] 条码: {barcode}) finally: clients.pop(conn, None) conn.close()如果扫码枪的 IP 是固定的你可以进一步用 IP 来映射工位号比如192.168.1.101对应 1 号打包台。这样业务层不需要额外配置就能知道条码来自哪个工位。注意addr里的端口是扫码枪的临时端口每次重连可能变化所以映射要用 IP不要用端口。4. 避坑与排查扫码枪 TCP 通讯最常见的 5 个翻车现场4.1 能 ping 通但连不上端口现象上位机 ping 扫码枪 IP 是通的但 TCP 连接被拒绝或超时。原因通常有三个扫码枪的 TCP Server 功能没开启或者端口号填错了或者扫码枪只允许特定 IP 连接白名单。解决先用扫码枪配置码确认 TCP Server 已启用端口号与代码一致再用telnet 扫码枪IP 端口测试如果 telnet 不通说明不是代码问题。有些扫码枪默认端口是 9004但配置菜单里显示的是 9005这种玄学差异只能靠翻手册或逐个试。4.2 收到数据但结尾多一个字节现象条码内容正确但字符串末尾多了一个不可见字符导致数据库查询失败。原因扫码枪配置了\r\n结尾但代码只strip()了空格没有去掉\r和\n。解决用rstrip(b\r\n\x03\x00)处理字节而不是先 decode 再 strip。如果条码本身可能以\r结尾那就不能盲目 rstrip要在扫码枪里关掉结尾符改用固定长度解析。4.3 程序重启后端口被占用现象调试时 CtrlC 停掉程序再启动报OSError: [Errno 98] Address already in use。原因TCP 连接处于 TIME_WAIT 状态操作系统默认要等 60 秒才释放端口。解决在bind之前加server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)。这个选项在 Linux 和 Windows 上都有效是调试阶段的后悔药。4.4 扫码枪频繁断连重连现象日志里不断出现“新连接”和“断开”但扫码枪实际没有移动。原因可能是网络抖动也可能是扫码枪的 Client 模式设置了“空闲超时”比如 30 秒没有数据就主动断开。解决先检查交换机端口是否有丢包再确认扫码枪的“心跳”或“保持连接”选项是否开启。如果扫码枪不支持心跳可以在上位机侧定期发一个空包或特定命令维持连接。注意不要发太频繁有些扫码枪会把非条码数据当成触发命令。4.5 多把枪同时上传时数据串了现象A 工位扫的条码显示在 B 工位的记录里。原因多线程处理时共享了同一个缓冲区或全局变量导致数据交叉。解决每个连接独立处理不要把recv到的数据放到全局列表再统一解析。如果业务层需要汇总用队列传递并且每条消息带上来源标识。另外检查扫码枪的 IP 是否重复有些现场用 DHCP重启后 IP 变了映射关系就乱了工业环境建议全部静态 IP。5. 进阶把 demo 变成可上线的小工具以及一个验证习惯5.1 加一层配置文件和日志别把参数写死在代码里demo 跑通后下一步是把 IP、端口、结尾符、编码这些参数抽到配置文件里。我一般用 JSON 或 YAML下面是一个最小配置示例{ server: { host: 0.0.0.0, port: 9004 }, barcode: { strip_bytes: \r\n\x03\x00, encoding: utf-8, fallback_encoding: gbk }, log: { raw_hex: true, file: scanner.log } }strip_bytes用字符串表示代码里再转成字节集合。raw_hex打开后每条原始数据都会以十六进制写入日志方便事后排查是扫码枪发错了还是解析错了。日志文件要按天切割否则长时间运行会占满磁盘。这个配置层不需要多复杂但能让你在现场改参数时不用重新打包程序。5.2 用“回环测试”验证解析逻辑不依赖扫码枪扫码枪不在手边时怎么验证解析代码我习惯写一个回环测试用本地 TCP 客户端模拟扫码枪发送预设的字节序列看服务端解析结果是否符合预期。下面是一个简单的测试脚本import socket import time def fake_gun_send(payload: bytes): s socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect((127.0.0.1, 9004)) s.sendall(payload) time.sleep(0.1) s.close() if __name__ __main__: # 模拟三种常见结尾 fake_gun_send(bABC123\r\n) fake_gun_send(bDEF456\r) fake_gun_send(bGHI789\x03)这个脚本可以快速验证parse_barcode是否把三种结尾都处理干净。你还可以故意发送半截数据比如先发bABC隔 100 毫秒再发b123\r\n看服务端会不会把两段拼成一条。如果会说明你的解析逻辑需要加帧边界判断不能简单依赖一次recv。5.3 一个让我少熬夜的习惯先抓包再改代码最后分享一个习惯当扫码枪和上位机通讯异常时先别改代码用抓包工具看原始 TCP 流。Wireshark 是最常用的过滤条件写tcp.port 9004就能看到扫码枪到底发了什么、上位机回了什么。很多“代码问题”其实是扫码枪配置问题比如它根本没发数据或者发了但目标端口不对。抓包能看到十六进制原始内容比日志更可靠。我遇到过扫码枪配置了\r\n结尾但实际只发\n的情况抓包一看就清楚了省得在代码里反复试。这套方案的核心不是代码多复杂而是把“扫码枪角色、结尾符、编码、多枪区分”这四个变量固定下来。先跑通最小 Server再用十六进制确认数据最后加配置和日志。希望帮到你。本文还有配套的精品资源点击获取
