TCP 客户端例程 4：现场常用脚本 网口透传.LPLUA（原文）

这一页只讲这一个例程。同组其余例程、以及这个库的函数说明都在 05-03-tcp-client。

适用：带以太网口的机型 ｜ 依赖模块：tcp_client plc system ｜ 难度：★★☆

场景：让设备的网口跟远端服务器（这里 192.168.0.238:6000）之间拉一条透传通道， 服务器侧直接读写设备后面的现场设备。等网口就绪的那段判断 + 三种回调都写成注释留在文件里， 是网口透传项目里复用最多的一份（文件 网口透传.LPLUA），原文收录如下。

完整代码（网口透传.LPLUA 原文）：

while(plc.bite(plc.ds(5),6)==0)
do
	system.sleep(1000)
	print("正在等待网口就绪");
end
client=tcp_client.creat("192.168.0.238",6000,plc.eth_ip())--建立对象
client:set_transparent()
--client:reg(tcp_client.RECVDATA,function(x)--注册接收数据回调函数
	   --print(x)
--client:send(x)--将收到的数据回应给服务器
	   --end)
--client:reg(tcp_client.CONNECTED,function()--注册连接成功回调函数
	   --print("连接成功")
	   --end
	   --)
--client:reg(tcp_client.DISCONNECTED,function()--注册断开连接回调函数
	   --print("服务器主动断开连接")
	   --end
	   --)
--client:start()--启动协议栈

要点：

• tcp_client.creat(ip, port, 本机IP) 的第三个参数可选，含义是「用哪个本机地址出去」；这里传 plc.eth_ip()（当前以太网 IP），等于显式声明走网口而不是 WiFi。不传第三参固件自己选。
• client:set_transparent() 只做一件事：把这条连接登记成透传通道，它不会替您发起连接。原脚本最后一行 client:start() 是注释掉的 —— 透传一直没建起来时，先把它解开。
• 顶部那段 while(...) do system.sleep(1000) end 跑在脚本主线程上：这一句没过去，下面所有代码一行都不执行；只要 D5 的 bit6 没置位，脚本就永远停在「正在等待网口就绪」。而这个位是脚本自己约定的（一般由梯形图在网口参数配好后置位），不是固件内置的网口就绪标志，换项目务必按自己的程序改判据。
• 中间三大段 reg(...) 全被注释，是「要用哪种回调就解开哪段」的模板。解 RECVDATA 那段时注意回调参数顺序是 (data, sock)，且原脚本示例里 client:send(x) 的 x 用的是回调第一个形参，位置不要改动。
• client= 是全局赋值，这正好对：客户端对象一旦被 GC，连接就断（见本页末尾注意事项）。

不阻塞主线程的等价写法（推荐新项目用这个）：

local client
local wait_eth
local function try_connect()
    if plc.bite(plc.ds(5), 6) ~= 0 then      -- 就绪判据按你的程序改
        client = tcp_client.creat("192.168.0.238", 6000, plc.eth_ip())
        client:set_transparent()
        client:start()
        wait_eth:stop()                       -- 建好了就不再轮询
    end
end
wait_eth = timer.start(1000, try_connect)     -- 每秒看一眼，脚本立刻跑完

验证方法：

1. 服务器侧监听 6000 端口，解开 client:start() 后应看到设备连上来（CONNECTED 回调那段解开会打印「连接成功」）。
2. 从服务器发一帧原始报文，串口侧应原样送出；现场设备应答应原样回到服务器。
3. 把 D5 bit6 一直留着不置位，观察是否卡在「正在等待网口就绪」—— 用这条确认自己改的判据是对的方向。

注意事项：

• 只调 set_transparent() 不调 start()：链建不起来，表现是服务器侧一直看不到设备。
• 顶层 system.sleep 死等：网口没就绪时整份脚本停在那里，后面配的通道一条都不生效，容易被误判成「透传功能坏了」。
• 同一条 TCP 连接上既透传又自己 send，数据会互相抢，透传期间应完全交给固件。