大家好，我是荣小菜，也可以叫我Richie，今天继续分享基于LabVIEW OOP的仪表控制库系列。
上一期我们完成了配置文件读写Vi开发，该造的轮子造的差不多了，今天就可以进入正题。我们的目标是设计一个“仪表配置”Vi，具体功能详见荣小菜补钙记第8期：基于LabVIEW OOP的仪表控制库(5)。
先把一些感想写在前面：代码大家都会写，但是写代码前需要考虑很多实际情况，因此思路思维和行业经验很重要。不但要分析需求是什么、需求的本质是什么、当前需求是真的需求吗、实现需求方法有哪些。还要衡量时间够不够、代码实现方法有哪些、哪种更好、代码产出后可复用好维护吗等一系列问题。因此我除了讲讲代码实现，还想更详细的聊聊我在写代码时考虑了哪些东西，为什么这么写，优劣有哪些，如何决断的。大家可能行业不同，但解决问题的思路肯定有很多可以互相借鉴讨论的地方。后续可能文字占比会多一些，也会讲的慢一些，见谅见谅。
下面就开始逐步实现啦^_^
1. 查询在线IP
想要与仪表通讯，首先要能查询到在线的IP。此时我们面临以下实际情况：
a) 仪表IP不固定(会被不同的人改来改去)；
b) 仪表IP不能固定(有时仪表IP还要兼顾和其它设备同字段)；
c) 在上两种情况下，一般不会同时大规模使用仪表(可能每次仅使用1~3台)；
d) 仪表IP可查看，也可手动修改(大部分仪表支持)；
e) 我们大都使用Windows系统(可以利用系统指令)。
那么实现方法有哪些呢：
a) 每次启动去Ping同字段下全部IP肯定不行，速度太慢；
b) 每次启动时弹出个对话框让用户去输入仪表的IP地址，显得很笨；
c) 做成NI MAX那样让用户为当前仪表自己配置一个IP？同上同上；
d) 另谋出路。^_T
为什么另谋出路，这里其实一语双关，我仔细说一下我的思路：
a) 如果做成c)那样，不如我们干脆直接用NI MAX加VISA句柄好了。但这样会造成除了要额外教用户使用NI MAX，还要打包NI MAX进安装包，打包NI MAX困难时(挺难的)甚至还要让用户自行安装LabVIEW才能解决；
b) 采用TCP Link的优势就在于可以摆脱NI MAX，而劣势就是官方驱动都是VISA句柄T_T。不过由于官方驱动(由于功能太强大且覆盖太全面)的代码过于复杂，当使用官方驱动的时候会导致Debug十分困难(真的超难T_T)；
c) 在国产化大环境下，厂家鱼龙混杂，官方驱动有没有我们不知道；有了能不能用我们也不想成为热心的“测试员”；能用能不能兼容，额，肯定不兼容别想了(自家的都不一定兼容呢)；
d) 再看看我们的题目“基于LabVIEW OOP的仪表控制库”，我们要写的就是一个兼容的库啊，这不就是另谋出路嘛，一下子就感觉事业很伟大了^_^。
通过上述分析，相信大家已经明白我们为什么在这搞来搞去了，那么回到“查询在线IP”上来，考虑到上面的实际情况，既然仪表IP改来改去很难固定，既然一般不会同时使用很多仪表，既然可以使用Windows指令，既然Ping一下IP是用户的习惯(改了IP不Ping就感觉没改成功的那种，哈哈)。我最终“另谋出路”，采用了ARP查表法，代码如下：
这样用户使用哪台仪表，只要在仪表上设好IP，再在电脑上用cmd来Ping一下(若是仪表很多就比较麻烦，但一般不会同时使用很多仪表，而若真一下子用很多，可以帮用户搞个.bat来Ping嘛^_^)，ARP表里就会记录相关信息(不断电可长期缓存)。这样我们在代码里直接查询ARP表就可以知道哪些IP在线了。此时，细心的同学可能发现了，若是有其它非仪表设备和我们的仪表设备同字段，岂不是也会被查询到。是的，不过既然它是非仪表，我们后续肯定会处理掉。
2. 总结
本期我们完成了“查询在线IP”的Vi开发，这是“仪表配置”的基本功能之一。本期涉及的代码不多，但是写代码之前考虑了很多，尝试了很多，沟通了很多，甚至间接引出了我们这个仪表控制库系列出现的本质原因。
大家觉得这样侧重讲详细思路的方式如何，欢迎留言讨论^_^
嘿嘿，不知道大家有没有注意到一个细节哈，a)，b)…之后的内容结尾改成分号啦。因为它们是并列项，最后一项结束前都用分号。
举报
