春有百花秋有月，夏有凉风冬有雪。若无闲事挂心头，便是人间好时节。
一、 前言
我之前写过一篇帖子：【LabVIEW开发】如何使用LabVIEW进行TCP通信？，里面比较详细地介绍了在LabVIEW的开发环境下如何与第三方进行TCP通信，内容比较基础，感兴趣的可以去看看。
当时写完这篇帖子，我就乐呵呵的以为这是LabVIEW进行TCP通信的终极形态，直到现实给了我当头一棒。在后来的一次项目中，我用LabVIEW开发上位机，使用TCP协议与西门子S7-1200进行数据通信，一开始在家做调试的时候上位机软件没啥问题，直到有一次在项目现场调试设备的时候，发现下位机上传给上位机软件的参数都没了，一检查发现：与工控主机连接的PLC网口的网线松动，就把网线重新插好，但是软件依然没有接收硬件上传的数据，这时我才意识到自己写的上位机软件没有断线重连功能。
这个问题虽然可以通过重启软件来解决，重启软件后通信恢复了，但依然说明我写的TCP通信程序是由缺陷的。既然发现了问题，当然要解决问题，不然跟咸鱼有什么区别。在网上查阅了大量资料后，终于找到了一位大佬写的程序完美的解决了这个问题，我觉得有必要把他贴出来：
也许是LabVIEW版本不同或者操作系统不一样的原因，这位大佬给的源程序在我的电脑上运行时会报一些小错误，而且程序面板里的连线纵横交错(估计是版本不同导致的)，不利于基础相对较差的人阅读和修改。为此我在源程序的基础上重新写了一个相对精简的程序，并成功实现了TCP通信的断线重连功能。
二、 实战练习
1、编程思路
具体实现程序的编写思路是：使用TCP客户端/服务端单独与网络调试助手进行通信，通信成功后，手动点击网络调试助手界面上的“断开连接”按钮，此时LabVIEW与网络调试助手通信断开，数据无法收发；然后再手动点击网络调试助手界面的上“打开连接”按钮，观察之前断开的TCP连接是否重新连接，收据是否可以收发。
网络调试助手主要是用来模拟第三方具备以太网通信功能的硬件设备，比如个人PC、PLC、单片机等。如果与网络调试助手通信正常，那么与其他硬件进行TCP通信也就不会有什么问题。后期有时间我会用LabVIEW与西门子PLC通信，然后重启PLC，看TCP通信是否会断线重连。
2、Client端断线重连
客户端的前面板只有字符串显示框，用来显示网络调试助手发过来的数据；程序面板与我之前写的如何使用LabVIEW进行TCP通信？中所写基本一样，最大的区别是使用移位寄存器，然后为了让网络调试助手接收的每一帧数据是变化的，发送数据改用随机数生成的数组转化为字符串后进行发送，而不是手动输入。
client端程序实现断线重连的核心原理是：通过判断TCP模块输出的错误代码是否等于66或63，如果通信异常或断开，条件为真进入到条件结构里的顺序结构部分，顺序结构依次为断开TCP连接、延迟3秒、重新打开TCP连接。如果此时网络调试助手server端恢复正常，那么client端的通信就恢复了，也就实现了断线重连。
如果第三方server端一直没有打开监听，那么TCP模块的错误代码会一直是66或63，那么程序就会每隔3秒进行重连操作，直到通信恢复正常。在多次重复测试中，我发现错误代码一直都是66，一次也没检测到63，可能是测试次数不够未能检测到，建议两个数字都用。至于TCP通信异常的错误代码为啥是66或者63，说实话我也不知道，这可能要去问NI公司的软件开发工程师了。
具体的实现程序如下图所示：
下面再来看下程序运行的结果，将网络调试助手设置为server型，IP和Port分别设置为127.0.0.1和6666。此时，不管是先运行LabVIEW的client端程序，还是先运行调试助手的server端程序，双端之间都可以正常进行TCP通信。由于我在client端的TCP read模块设置的接收数据字节数为4，所以调试助手发送的数据是4个字节，目前client端程序无法自动获取接收数据的字节数，需要手动设置。程序具体运行结果如下图所示：
此时点击调试助手上的“断开”按钮，可以看到client端前面板的字符串显示框中的数据消失了，说明此时软件没有接收到数据，通信已中断；然会再点击调试助手界面上的“打开”按钮，然后点击发送数据，双端之间的通信自动恢复正常。同样，保持server端运行，中断client程序运行，然后重新运行client程序，TCP通信依旧可以自动恢复。
3、Server端断线重连
server端的前面板是一个字符串显示框和一个停止按钮，分别用来显示调试助手发送的数据和关闭程序。程序面板编写的核心原理是：
首先设置"TCP Listen.vi"模块的端口为6666，通信超时设置为0，然后判断该模块输出的错误状态码，通信正常时状态码为0，通信异常时状态码为1。也就是说，当client端通信中断后，server端侦听模块的状态码就变为1，错误码会变为62或者66，而条件结构“真”里面的代码为空，此时程序开始执行外部大循环里侦听模块的程序，与此同时，条件结构中的小循环读/写程序被中止。
经过我多次测试，发现错误码大部分时候是62，少数情况下会出现66，所以这两个数必须要使用。具体的实现程序如下图所示：
如果client端打开连接，server端一旦侦听到了该连接，通信恢复正常，状态码和错误码会立刻转变为0，数据就可以正常收发。与我之前写的基本版通信程序相比，这个程序最大的改变就是client端通信中断后，会不断循环运行“TCP Listen.vi”这个模块，进行循环监听；而基本版的程序只进行过一次监听，如果中途通信断掉了，这个侦听模块不会再重新运行，也就不能实现断线重连。
程序运行的结果如下图所示：
先运行server端程序，然后将调试助手设置为Client模式，并设置好IP和Port，点击面板上的“连接”按钮，调试助手立马显示同行已连接，再点击循环发送按钮，数据就可以正常收发。为了方便观察，我把调试助手的循环发送周期设置为1.5s。
依次点击调试助手面板上的“断开”--“连接”--“发送”，模拟客户端连接中断（网线拔掉），重新连接（网线插上）的过程，可以看到与server端的通信马上就恢复了，说明上述程序实现了断线重连功能。
三、 小结
1、数据收发的周期一般是双端匹配的，不管我上位机软件收发周期设置为多少毫秒，下位机硬件的发送周期如果比上位机的接收周期长，就会以时间更长的一端为准。这个在实际的项目中需要注意一下。
2、软件没有自动识别接收数据字节数的功能，所以在read模块需要设置好接收数据的字节数，并与调试助手上发送的数据字节数保持一致。如果不一致，会导致数据无法接收挥着接收数据乱码。
