【 声明：版权所有，欢迎转载，请勿用于商业用途。 联系信箱：feixiaoxing @163.com】
作为上位机，它很重要的一个部分就是需要和外面的设备进行数据沟通的。很多时候，也就是在这个沟通的过程当中，上位机软件才有了自己的价值。如果上位机可以通过收集数据，进一步构建自己的算法，那么上位机自身的价值就更大了。之前说的usb、can、232这些都是沟通的媒介，本质上最重要的还是通讯的协议。
所谓通讯的协议，其实就是沟通的方式和报文的格式。沟通的方式，一般代表谁先主动发起沟通，谁被动应答沟通；报文的格式，则代表每次沟通的数据有多少个，每个数据代表着什么样的含义。这就是通讯的全部内容。
1、通讯沟通的方式
大部分上位机在沟通的时候都是作为主动的一方存在的，被沟通的设备一般都是被动响应报文的。比如说一个卷帘门设备、一个充电设备、一个机器人设备等等，基本上都是上位机要求它做什么，它就会去做什么。在作业的过程中，上位机会不停轮询当前的工作状态。
2、哪里可以看到数据协议
这种协议还是很多的。如果是网站服务器类的协议，这种一般都是私有协议，只需要和对应网站的开发人员搞好对接就可以了；如果是设备类的协议，那么我们通过线上或者线下的方式拿到设备之后，就可以通过它们的售后人员拿到对应设备的开发协议。当然，现在很多设备供应商也会提前在自己的官网或者是github上发布对应的通讯协议，这都是可能的。
3、常见的协议有哪几种
对于工控领域来说，最常见的协议就是modbus协议，它的通讯格式非常简单，就是简单的应答模式。上位机发送一个请求，设备回复一个请求。主要的请求也只有读写两种模式，读写的报文也很短，一般就十几个字节，这也是因为本身modbus设备功能比较单一，十几个字节加上对应的bit位，其实很容易把大部分功能就说清楚了。
4、某设备232通信协议分析
4.1 读设备协议
这就是一个读设备协议，整个数据是16进制形式，数据内容是0x0101006400087c13。整个数据有8个字节。第一个01代表设备地址，第二个01代表功能，这里是读。第三、四个字节是0064，转成10进制就是100，代表寄存器地址是100。第五、六个字节是0008，代表需要读8个寄存器。第七、八两个字节7c13，这个是校验码，一般通过crc算法计算得到。
4.2 读设备返回协议
如果我们按照4.1的形式发送数据之后，那么没什么问题的话，上位机就会从设备读到返回的数据。假设这个数据是0x0101010f118c。这个时候和4.1一样，我们只需要按照官方给出的example去一个一个字节解析就可以了。从长度上看，返回的数据只有6个字节。第一个字节01代表设备地址。第二个字节01代表功能码01，即读。第三个字节代表数据长度01，即1个字节。第四个字节0F代表返回的数据0F。第五、六个字节0x118c代表检验码，用户可以根据校验码判断一下下发的数据是否有错误。
**这里可以思考下，假设返回的数据是4个，那么格式应该是什么样的？**比如说还是这里，那么返回的数据可能是这样的，01+01+04+0000000f+校验码2个字节，这样所有的数据长度加起来就是9个字节。
4.3 写设备协议
和读设备协议相比较，读设备协议稍微复杂了一点。这里写设备的命令是0x010f00640008010fcf59。其中有两个个地方需要注意一下，第一，功能吗从01变成了0f。第二，和读设备相比较，这里多了一个010f，其中01代表要写的数据长度，0f代表要写的数据内容。其他部分和读设备协议差别不大。
4.4 写设备返回协议
和写设备协议相比较，写设备返回则简单很多。基本上，把写的数据长度、写数据内容拿走，剩下来就是写设备返回的内容。当然，对应的校验码肯定也发生了改变。
5、数据内容代表什么
前面我们讨论了设备协议，但是大家有没有注意，我们没有讨论读写数据里面的内容。这主要是因为，具体数据的含义其实和设备本身是相关的，它可能是一个门、一个灯、一个开关、一个电机、一个显示屏幕，凡此种种，我们使用的时候再分别分析具体的bit位、具体的数据含义就可以了。这次要学习的主要就是怎么分析这个通信协议的逻辑。
6、其他要注意的地方
编写协议的时候，还是需要非常小心的，通常来说有这么几点要注意；
1）注意字节序；
2）注意每个bit的含义；
3）一收一发，不断检验执行的返回结果；
4）严格根据设备的要求，保证输入参数的合法性；
5）大胆怀疑，小心假设；
6）出问题的时候，大部分是参数没设置好、环境发生了变化，设备出问题概率不大。