156 篇博文 含有标签「我和labview」

原计划是每翻译一段，就立即进行人工修正。然而，我后来发现人工校对实在是太耗时了。由于我的闲暇时间有限，若要认真地逐字逐句进行修改，估计整个过程需要一到两年的时间。因此，我决定暂时跳过人工校对这一步，先使用机器将其全部翻译成英文，日后再逐步进行优化。

我主要采用了 ChatGPT 进行翻译工作，并且也试验了其他几种大型语言模型。经过比对，ChatGPT 的翻译效果是最佳的。尽管如此，ChatGPT 也并不完美：阅读几行后，仍然能发现其翻译的内容与真人撰写的有所不同。它最明显的不足之处包括错误地翻译了一些专有名词，例如，LabVIEW 中的许多术语，比如 tool palette 等都被错误翻译了；此外，其用词偏好和写作风格也与真人不同。比如，“instrumental” 这个单词在平常几乎不会使用，但在 ChatGPT 的翻译中却频繁出现。我推测，这可能是因为 LabVIEW 与 “instrument” 高度相关，而 “instrument” 又与 “instrumental” 有关联，所以模型可能误以为 LabVIEW 相关文章就应当多使用 “instrumental”。

但无论如何，ChatGPT 的翻译效果已经远超以往所有的专业翻译模型。在大型语言模型兴起之前，谷歌翻译被认为是效果最佳的翻译工具，即便如此，其翻译内容仍然基本无法直接使用。现在，ChatGPT 已经可以当作一个相当靠谱的翻译工具了。

最近开始大语言模型把 LabVIEW 书翻译成英语：https://lv.qizhen.xyz/en/

我是一章一章的翻译的。一般，每一章要过两遍。第一遍先用大语言模型中翻英。但机器翻译往往难以摆脱中文的句式结构，导致英文表达显得生硬。所以还要再用大语言模型进行改写，确保语句流畅、符合英语表达习惯。最后产生的英语文本我会检查一遍，确保没有错误，也同时学习学习英语。

如果没有大语言模型的帮助，我是不敢想象自己把文章翻译成英语的。大模型生成的英语文章可能依然赶不上真人写出来的文章，但它已经比我的英语好太多了，不但能保证语法正确，用词也比我丰富的多。之前从来没预料到，在写作方面，计算机这么快就赶上真人了。

现在翻译 LabVIEW 书籍最麻烦的是如何把插图中的中文翻译成英语。我只好暂时先不管了，留到以后有空再说。

大语言模型在给我带来极大帮助的同时，也带来不少问题。比如，编程面试。我们公司现在的招聘面试全部是视频面试，可能是为了节省成本吧。这在之前还好，可是自从有了 ChatGPT 等工具，明显就可以感觉应聘者编程能力普遍大幅提高。有些粗人，面试的时候，敲一行代码，就歪头看两眼，再写一行代码。你也不能说人家一定是在作弊，人家可能就是这种编程习惯。ChatGPT 不仅仅会写代码，解释代码也很在行。我也没有什么十分完美的方案来应对这些新问题，只希望公司能恢复现场面试吧。

最近一个多月的时间，差不多把业余时间全部用来写一本 Python 编程书了 https://py.qizhen.xyz/

除了为了学习 Python 语言本身，也是为了深入体验大语言模型为学习和写作带来的新机遇。总体感觉就是大语言模型真牛。在它的帮助下，我花了一个多月的时间，让这本书答题成型，虽然还有很多问题，内容也不完整。但是如果没有大语言模型的帮助，写作到达到同样的程度，至少需要多花费二到三倍的时间。

大语言模型极大地加快了我完成本书的进程。然而，从另一个角度来看，它也降低了写作的门槛，如果过去三个月的劳动现在仅需一个月即可完成，那么这项工作的价值也可能只有以前的三分之一，甚至可能更低。以后，单从对读者的价值来说，可能再也没有写作这类书的必要了：看书还不如直接去问大语言模型。

就目前来说，我写 LabVIEW 的书相对价值还高一点，虽然 LabVIEW 的使用者非常少，但是大语言模型还无法产生高质量的 LabVIEW 编程资料。所以看我的书还有一些价值。

大语言模型最牛的地方不在于处理编程语言，而在于处理自然语言。我的英语水平有限，自从有了大型语言模型之后，无论我写什么，我总是先让它帮我进行修改。它不仅能纠正我语言中的错误，还能帮我润色文章，达到我自己无法企及的水平。所以，我正考虑将我之前写的 LabVIEW 教程翻译成英文。之前一直没有下决心开始这个项目，主要就是因为对自己的英语水平不够自信，但现在，我已经充满信心了（其实是对大语言模型充满信心）。

大约去年这个时候，我把《我和 LabVIEW》这本书做成电子书发布在了网站上。当时已经计划每年会做一些更新，今天回顾了一下这一年来的改动，实际上改进的内容比我预估的还更多一些。

刚开始做准备的时候，我担心我的 LabVIEW 编程技术已经忘光了，也担心这十年来 LabVIEW 变化太大，打开之后都不认识了。但后来发现，我开始的预计都有些太悲观了。我的编程技术确实退化了，但基本的方法都还记得，恢复的很快；LabVIEW 也并没有太大变化，基本操作几乎一模一样。

变化比较大的是网上的中文资料。10 年前网上关于 LabVIEW 的中文资料少得可怜。但现在，无论哪一方面都能搜到一大堆资料，而且很多资料的质量也是相当高的。这些年也有不少关于 LabVIEW 的中文书籍出版，网上评价也不错。如果我在国内的话，肯定当时就买来看看了，不过现在人在国外考虑到运费，嗯，还是等下回回国再说吧。

再有，就是近几年视频逐步崛起，成了网上最重要的知识分享方式。但是考虑到我个人还是会继续以文字加图片的方式分享自己的编程经验。这主要是因为视频制作要花费更多的精力，如果我有时间，还是倾向于增添更多的内容。另外，就是我分享的很多东西也不是太成熟的，发布后还会经常改来改去。文字改起来非常容易，视频要改其中部分内容就麻烦多了。

在搜索 LabVIEW 中文内容的过程中，我还特意尝试用了很多国内的搜索引擎，结果大失所望。百度是国内市场占有率最大的搜索引擎了，先不说它垃圾广告的问题，单说搜索质量也是十分差劲。搜索一些技术内容，返回的常常都是灌水文，最后只能换回 Google。

相比起写纸质书，我还是更喜欢这种类似博客的电子书发布方式的。最主要的原因是可以及时和读者交流。从读者的反馈和问题可以直接了解到自己那里写的不清楚，甚至写错了，然后可以及时纠正。除了读者留言，我还使用了网站统计工具来查看这本书被阅读的情况，工具可能并不精确，但大致可以反应读者的分布。

首先让我觉得比较吃惊的是，这本书最大的流量来源是 Google，尽管在国内无法直接访问 Google。这一说明了搜索引擎对一个网站的流量作用极大，可惜的是，国内的一众搜索引擎都不能搜索我的网站，可能是歧视我没钱买关键词吧。唯一一个我发现能搜索我的网站的国产搜索引擎是 https://fsoufsou.com/ 。也试了一下用这个网站搜索技术文章，比百度的结果好太多了。可惜它的用户量太少，几乎可以忽略不计。希望这个搜索引擎能继续坚持做下去。

除了 Google，比较多的来源网站是知乎和微信。知乎上网友的推荐贴给本书带来了不少流量。微信的对话和群都是封闭的，而我又不在任何群里，就无法得知网友们都在讨论啥了。

再有就是发现绝大多数读者关注的还是基础内容，而不是 LabVIEW 一些高级用法。除首页外，访问量前五的章节是《数值和布尔数据》，《Hello World 程序》，《图形化显示数据》，《什么是 LabVIEW》，《数组和循环》。除首页外，Google 点击页面的前五分别是：《图形化显示数据》，《界面设计实例》，《什么是 LabVIEW》，《安装 LabVIEW》，《事件结构和程序界面》。深入一些的内容比如性能优化，面向对象等访问量比起基础内容零头都不到。我想想也是有道理的，那些比较高级的用法，可能并不是看看书就会用的，最好还是要有交流，有个专门的人来指导一下。相反写书的话更适合介绍一些基础知识。所以我也调整了自己的更新维护计划。今年上半年的时候，我重写了整个面向对象一章，也是为了让零基础读者能更容易理解。后来，就把主要时间用来从头更新那些基础章节了。

之前用 LabVIEW 编写了一个黑白棋程序，作为学习 XControl 的示例。那个程序基本完整，但是缺少一个 AI 自动走子的功能。最近抽空尝试训练了一个网络模型，添加到了演示程序中。

所有AI下棋的思路都是非常类似的：根据当前的盘面，给每个可以落子的位置打分，选取分数最高的那个走法。这里的关键就是设计一个最为合理的打分算法。

黑白棋最终判定胜负的标准是看谁的子多，所以最符合直觉的打分方法是：在一个位置落子后，把己方的棋子数目作为这个位置的分数。这个算法有个缺陷，就是当前棋子数最多的走法不见得就能保证将来也棋子数最多。

解决这个缺陷的思路有两条：其一是，不要为当前这一步打分，而是向后预测几步。比如，把双方各下三步棋（也就是总够六步）后的所有可能出现的局面都列出来，然后看那个局面得分最高。考虑的步数越深，棋力也就越高，极端情况，如果预测的足够深，甚至可以找到必胜的下法。这个方法的缺点是预算量非常高，增加预测的深度，计算量会指数级增加。可以通过剪枝做一些优化，但效果有限。

第二条思路是采用更复杂的打分算法，如果只考虑棋子数量还不够好，那么就也同时考虑落子的位置，稳定的棋子的个数，周围空间的个数等等。在这众多的因素中哪些更重要，如何分配权重，对于我这种非专业棋手来说是很难做选择的。不过这部分可以利用机器学习算法，让电脑自己找到最优解。

当然以上两条思路可以结合使用：先找到一个最优的打分算法，再尽量预测到更深的步数。

我尝试训练了一个基于神经网路的打分模型。

我采用的是一个只有一层隐藏层，64节点的全链接神经网络。单隐藏层64节点的神经网络对于解决黑白棋来说，有点太小了。我也不能确定多大才合适，但估计至少也应该采用一个七八层的CNN，才能达到不错的效果。不过，我的目标不是最好的效果，而是只要试验一下可行性。并且，我需要把训练好的模型移植到 LabVIEW 代码上，复杂模型移植起来太麻烦。所以我选择了这个最简单的模型。

模型的输入数据是当前棋盘状态（每个位置棋子的颜色）和一个准备落子的位置，模型输出一个实数表示得分。

训练模型的大致思路是：让模型分别持黑子和白子，自己跟自己下棋，并且记录下每一步的走法。最终胜利一方所有走过的位置都获得正标签，失败一方所有走过的位置都是负标签。用这些标签训练模型，然后重复以上过程。

在训练模型的过程中，我遇到了一些以前从未考虑过的问题。比如，采用何种激活函数。我开始采用的 ReLU 函数，但模型始终无法被训练到预期效果。调试后发现，是 ReLU 的神经元坏死造成的。ReLU 在输入值小于零时，梯度永远为0，这个神经元很可能再也不会被任何数据激活了。这对于目前常见的有着几万乃至几百亿节点的大规模模型来说，根本不是问题。但是对于一个本来就没几个节点的小型模型来说，损失神经元是非常致命的。我把激活函数换成 Sigmoid 之后，效果就好了很多。

我训练模型的方法效率非常低下。在下棋过程中，大多数的步骤可能都不是太重要，不论走这还是走那，对最终结果影响都不大。关键的就那么少数几步，可以决定输赢。但是在训练时候，我也不知道每一步的权重应该有多大，只能假设所有步数都是一样的权重。那些垃圾步不但占用资源，也会影响训练结果。

模型训练好之后，我把它移植到了之前编写好的 LabVIEW 黑白棋 VI 中。棋力算不上很好，但至少是明显优于随机落子。等我空闲的时候，看看还能不能进一步优化下。

程序在： https://github.com/ruanqizhen/labview_book/tree/main/code/%E7%95%8C%E9%9D%A2%E8%AE%BE%E8%AE%A1/Xcontrol/Othello

https://lv.qizhen.xyz/appendix_problem

以前从来没有意识到过这个问题，直到最近，我试图去查看自己很久之前写的一些VI的时候才开始注意到它的。

先简略的介绍一下unicode的背景：

计算机是在美国被发明的，所以很自然的最开始只考虑了处理英文。早期最著名的关于如何在计算机中表达字符的标准是ASCII标准（American Standard Code for Information Interchange，美国信息互换标准代码）。它定义了128个字符，包括英文字母大小写，数字，常用的标点和一些特殊符号。当时世界上所有的计算机都用同样的 ASCII 方案来保存英文文字。这个方案最大的问题是只包含了英文字母，于是其它国家，组织和公司纷纷开始扩展这个标准用以支持其它字符，比如制表符、数学运算符号、中文字、日文字等等。比如在中国最常用的标准 GB2312，GBK，GB18030 等都是对 ASCII 的中文扩展。之后扩展出的这些标准有个很大的问题，就是同一个数值在不同的标准中被定义了不同的含义。某一数值在中文的标准下可能是一个中文字符，放到韩国的系统的某标准下，可能就是一个完全不相关的制表符。这就造成了，在中文环境下开发的软件，运行到韩国系统下显示的就完全是乱码。如果有人需要在一个系统下同时运行一个中国软件和一个韩国软件，恐怕就不行了。

为了解决这个问题，1990年开始，计算机业界开始研发一种编码标准，它可以覆盖全世界所有的字符，这样任何一个字符都有自己独占的编码，这样就不会出现换个系统就乱码的问题了。这就是unicode，也叫万国码、单一码。unicode规定了字符集，但是这套字符集也还有多重不同的编码格式。Windows采用了UTF-16LE格式的unicode编码（UTF全称为 Unicode Transformation Format），使用16位的(双字节)数据表示一个字符。但是当前最流行的unicode编码格式却是 UTF-8，这是一种变长的编码方式，根据字符的常用程度，可能由1到6个字节来表示。目前大多数的unicode文档采用的都是 UTF-8 编码的。

目前，大多数的软件也都是基于unicode的了。但是LabVIEW始终没有支持unicode。虽然Windows很早就开始支持unicode了，但是为了兼容那些还没有支持unicode的软件，Windows系统保留了一个默认字符集的设置，对于非unicode的软件，Windows会使用默认的字符集来解释那些字符编码。国内使用的电脑几乎都设置了默认的字符集为中文字符集，所以，一个软件是不是支持unicode，对于绝大多数中国用户来说根本感觉不到什么差别。所以，我之前也从来没觉得LabVIEW不支持unicode有什么问题。

直到最近我才发现了问题。我家里有两台电脑，一台操作系统安装了英文的Windows，并且没有修改过默认的非unicode字符集；另一台操作系统是中文Deepin Linux。我在两台电脑上都安装了社区版的LabVIEW 2021。我想在两台电脑上查看一下自己十年前写的一些VI，这时才发现，如果VI的路径中包含中文，是无法在Windows上被LabVIEW打开的。不过，我主要使用的是Linux，在Linux上还可以打开大部分的VI。但很快我就又发现，如果那些VI中如果有我以前设置的中文的常量或注释，在Linux下是无法正确显示的。但是呢，我还可以再Linux下添加中文常量或注释。之后，又遇到了更严重的问题：以前那些项目中，如果有中文名的子VI，或是库中、类中有中文名的VI，就通通都打不开了。我开始还以为是不是10年过去了，LabVIEW系统有什么变化，但是没听说过啊。于是我开始怀疑是不是文字编码的问题，我把Windows的默认字符集换乘了中文，果然在Windows下一切正常了。而且我还发下，在Linux下，给VI添加的中文注释，拿到Windows下，看到的全是乱码。

总结我看到的现象，我深刻怀疑，目前LabVIEW在Windows下是不是用unicode的，字符编码由Windows系统决定，对于大部分中国用户来说，采用的是GB18030中文编码；但在Linux下却使用了UTF-8编码。

在Linux由于系统和LabVIEW采用的都是unicode，所以一个VI在不同Linux版本下应该行为都是一致的。但Windows系统用的是unicode，LabVIEW用的却不是。我们现在假设一个项目中有两个VI，本别是“界面.vi”和“任务1.vi”，其中“任务1.vi”是“界面.vi”的子VI。在操作系统层面，有两个文件：“界面.vi”和“任务1.vi”，它们的名字都是使用unicode保存的。但是在“任务1.vi”内部，它记录了自己要调用“任务1.vi”，却用的是非unicode编码保存的子VI的名字。所以LabVIEW中用于记录这个子VI的一段二进制数据与操作系统中记录这个子VI文件名使用的二进制数据是不同的。每次LabVIEW需要操作系统找到相应的VI文件时，还需要做一次编码转换，把文字转为系统认识的unicode编码。如果保存VI，和读取VI都是在中文Windows中，这没有问题，VI名字总能被正确转换。但是把之前在中文Windows系统下保存的项目拿到非中文Windows（默认语言编码不是中文）下打开，文件名编码转换这一步就会出错，LabVIEW就无法找到正确的VI了。同理，中文Windows下保存的VI，如果有中文名，拿到Linux下打开会出错；反过来也是一样会出错。

总之，由于LabVIEW在Windows下没有使用unicode，造成了中文显示在不同系统下的不一致行为，切换系统就会出现乱码，甚至VI无法被加载。目前没有什么好办法可以解决这个问题。我只好将来在LabVIEW中只使用英文，不是用中文了。

最近学习完了React，又使用Docusaurus重新为书籍制作了网页：https://lv.qizhen.xyz/

实际上，Docusaurus已经帮我作为绝大部分工作，我学习的React技能基本没有用上，毕竟书籍的格式还是比较简单固定的，不需要非常炫酷的界面。

之前是用Docsify制作的页面。我对于Docsify的界面和功能已经非常满意了，最主要的问题是它制作的网页是客户端渲染的，搜索引擎都不会爬取。墙外的搜索市场已经被Google垄断，恐怕Google是不会有动力去支持搜索客户端渲染页面了。国内的搜索市场竞争还更激烈一点，可以它们居然做的都比Google还差很多，也没有指望。只能自己修改网页了。

Docusaurus使用起来比Docsify麻烦不少，所需技术门槛也稍高。这一是因为Docsify只支持制作文档网页，而Docusaurus还可以制作个人主页和博客，功能复杂了不少，虽然都是我都用不上的。二是因为Docusaurus是制作服务端渲染页面的，多了一个Build步骤。再有Docusaurus比较新，资源相对来说少一些。

但不管怎么样，Docusaurus也是非常令人满意的。现在Google可以爬取我的页面了，国内的搜索引擎都还不行，但这不是网页的问题，最可能是我的域名没有工信部认证，国内引擎不愿意访问。

Docusaurus开发团队非常活跃，应用前景应当超过其它类似工具。非常推荐用于创建静态的个人主页、博客、文档等。

https://lv.qizhen.xyz/

毕竟不是专业做LabVIEW编程了，写作速度也大为减缓。因为之前太久没维护了，近期我还是会尽可能多的做一些修改。长期的来说，希望保持每年可以更新一两章的内容。

将来会逐渐补充一些我比较了解的内容，比如：面向对象编程，泛型编程，数据结构，设计模式，网络编程，调用Python等。当然这些都是很长远计划了，不能期望太高。

只大致看了看前后面板。发现跟10年前差别不大，功能有所增加，但也没有太多，没有2000~2010那十年变化大。这也可以理解，编程语言的基础部分还是要稳定一些的。重大的功能添加可能主要会以插件的形式发布了。

也有可能NI过去10年精力主要都放在了LabVIEW NXG上面。看看下个十年会怎么样吧。

我把书的原稿开源放到GeiHub上之后，给它做了个页面方便阅读。做好的网页是一个单页面应用，也就是说书里的所有内容都是放在同一个页面上：https://lv.qizhen.xyz/。别看每个章节都会在地址栏上显示不同的URL，比如“https://lv.qizhen.xyz/#docs/structure_condition”，其实#号后面的都只是同一页面不同的参数而已。浏览器只能展示 HTML 格式的内容，但GitHub的网站上并没有存HTML格式的文档，所有文档使用Markdown（*.md）格式保存的。GitHub的网站也不会把MD格式文件动态渲染成HTML格式再传给读者的浏览器，网站发给浏览器的还是 MD 格式的数据，是浏览器端运行了一段JavaScript程序，才把 MD 格式的数据渲染成了HTML。

GitHub的服务器应该是不支持后台渲染的，做成前台渲染的单页面应用，用户体验会好一些：换页反应比较快，还可以随时改变背景配色等。但是这种做法对搜索引擎非常不友好。

搜索引擎在检索网站时，一是它不会尝试不同的参数，也就是说它只检索 https://lv.qizhen.xyz/ 这一个首页面；二是搜索引擎的爬虫也不会运行JavaScript，所以即便是首页的内容，它也看不到。总之搜索引擎根本看不到这本书的任何内容，也就别想搜索到它了。

我还不知道这个问题怎么解决，不过GitHub上搭建博客还有很多其它方法，有一些是产生静态HTML的，应该没有这个问题。等有时间再试试其它的那些工具吧。

GitHub自带的搜索也几乎没法搜索中文书，它是按词搜索的。它定义的“词“就是两个空格或者符号之间的字符串，这对于代码或者英文文档都非常合适。但是中文的词和词之间是没有空格的，GitHub对于中文只能整句匹配，只有文章里恰好有跟搜索内容一模一样的句子时才会被找到。