好久没写博客了，上一次写还是在上一家公司
现在在的这家公司目前做的是隧道内的探伤项目，我现在主要的工作是做工控机，也就是控制各种硬件组织作业。
目前的产品架构见https://github.com/LeventureQys/South_Gathering_Doc 中多设备采集软件相关内容，这篇文章仅是记录旧版软件的修改日志。
架构大致如下：
2023.4.27
CarClient.exe进行了修改
原先的CarClient控制的小车，当结束任务的时候是不会主动停下小车的，现在修改后CarClient会在任务结束后主动将小车停下。
FaroClient.exe进行了修改
为什么程序的自检流程显得那么长？原因其实也很简单，这个要从我们的自检方式说起。
旧版程序的检查模式是这样的：
1.点击开始检查之后，控制端程序会向中控端发送指令，中控端将消息转发给各个采集端。
2.采集端会开始ping自己的设备，顺序如下:
3.检查完一个阶段后，会将当前的设备状态返回给中控端，中控端会将所有的消息再转发给控制端。
为了应对以后的开发，这里需要提两个问题：
1.为什么要一个中控端而不是所有的采集设备都是采集端？
答：和平台组的组长稍微聊了一下，直连也可以，中控的模式也可以。
直连有直连的优势，就是可以少一个环节，这样出错的地方就少一部份。其次需要考虑到性能问题，因为在大量IO下不一定能保证服务器还能正常转发数据，而且多一个数据转发的环节对服务器也不够友好，这个中控服务器不一定能很好地组织起来整个系统的运转。
但是中控有一个决定性优势，就是在隧道下作业不能保证无线网连接正常，如果无线网连接正常就意味着直连模式下需要做大量的状态同步（因为要考虑断线的情况）。但是如果提供一个中控服务器，那就不需要这样的状态。也就是说最好的情况就是通过一个中控服务器就可以单独完成作业，甚至可以提供一个单独的交互系统放在中控机上，这样就不需要再有一个单独的采集机了。
2.自检为什么这么慢？
说到这个问题，就必须要从上述自检流程说起了。上述1-8个步骤并不是同步执行的，一定要上面一步执行完了之后才会执行下一步，这就会有一些问题。
其中最主要的问题就是法如的扫描仪的连接是耗时且阻塞的，并不是在另外一个线程ping一下就可以直接连接。也就是说后续所有的操作都需要等待法如正常连接上之后才可以进行。
经测试，灯光，GNSS，IMU，相机的自检时间都可以忽略不计，但是法如的连接模式必须重新设计。
修改方案
CarClient.exe 在任务结束之前发送一条小车停止的命令。
目前FaroClient.exe的修改方案是在程序启动的时候就执行轮询自检，当需要的时候是直接读取当前的状态，如果是连接正常则不再返回，如果是连接异常则再启动一次自检。但是轮询自检可能会导致faroclient.exe出现线程阻塞的问题，目前仍有待测试。