20240305-labview-2024q1-released

LabVIEW 2024 Q1已发布

LabVIEW新特性

LabVIEW 2024Q1已经发布,没有什么太明显的改变,主要是增加了LVClass路径支持,可以动态载入类了。
除了大包,还有Linux RT和RF相关没有在大包里面可以自行下载有备无患。

下载地址

64bit Offline Installer

Software Platform Bundle 2024 Q1
Name Checksum File Size
2024 Q1 (MD5) d2112118119e7a7b3e7716a40a53f745 46.58 GB
(SHA256) 82126e006f09f5df52a4926a613abeb49b0d89419c75f3c69123f5777c8a1dbf

From https://www.ni.com/en/support/downloads/software-products/download.software-platform-bundle.html#521708
https://download.ni.com/support/nipkg/products/ni-s/ni-software-platform-bundle/24.0/offline/ni-software-platform-bundle_24.0.0.49239-0+f87_offline.iso

32bit eng Offline Installer

Software Platform Bundle 2024 Q1
Name Checksum File Size
2024 Q1 (MD5) 606cd0aaaef273f2b8a71c518e458cba 47.71 GB
(SHA256) d346ace3b03d72ba3ea1a94a2db8c15a9def6c69ad8171eeb958ce6e053ac958

From https://www.ni.com/en/support/downloads/software-products/download.software-platform-bundle.html#521709
https://download.ni.com/support/nipkg/products/ni-s/ni-software-platform-bundle-x86/24.0/offline/ni-software-platform-bundle-x86_24.0.0.49238-0+f86_offline.iso

32bit chs Offline Installer

Software Platform Bundle 2024 Q1
Name Checksum File Size
2024 Q1 (MD5) f14299f5750ebd7b1f414e40ad3f01d7 48 GB
(SHA256) 7e5d8aeb6aeb8d91b15e7d22f9e578fafc27337bda297a4651c3a21b52921836

From https://www.ni.com/en/support/downloads/software-products/download.software-platform-bundle.html#521579
https://download.ni.com/support/nipkg/products/ni-s/ni-software-platform-bundle-x86-zh-cn/24.0/offline/ni-software-platform-bundle-x86-zh-cn_24.0.0.49238-0+f86_offline.iso

Offline Installer

NI Linux Real-Time Offline Installation Support 2024 Q1
Name Checksum File Size
2024 Q1 (MD5) 0f638edc2102f474ed7bf8d4f87787b4 8.71 GB
(SHA256) 4895c78a1020b2a44272bb4bd13d3ea444bdd206a9ae62ac8083d30fd228e6fa

From https://www.ni.com/en/support/downloads/software-products/download.ni-linux-real-time-offline-installation-support.html#521675
https://download.ni.com/support/nipkg/products/ni-l/ni-linux-rt-offline-installation-support-24.0/24.0/offline/ni-linux-rt-offline-installation-support-24.0_24.0.0_offline.iso

Offline Installer

RFmx 2024 Q1
Name Checksum File Size
2024 Q1 (MD5) 260dcd916070a285be516766edc05bb7 2.86 GB
(SHA256) 9b439f81fc108e13e90e2889828bf39d5f2b6c28dd9079c77231e22058033e01

From https://www.ni.com/en/support/downloads/software-products/download.rfmx.html#521553
https://download.ni.com/support/nipkg/products/ni-r/ni-rfmx-suite/24.0/offline/ni-rfmx-suite_24.0.0.49308-0+f156_offline.iso

NI-RFSA 2024 Q1

Name Checksum File Size
2024 Q1 (MD5) c1e6cda2a94fba81c6615a3f17034cb2 4.12 GB
(SHA256) fccf95a10b0a6d9f50751905092397a05d44f2b1890380191f8b7983c359d0b1

From https://www.ni.com/en/support/downloads/drivers/download.ni-rfsa.html#521697
https://download.ni.com/support/nipkg/products/ni-r/ni-rfsa/24.0/offline/ni-rfsa_24.0.0_offline.iso

NI-RFSG 2024 Q1

Name Checksum File Size
2024 Q1 (MD5) 9c1c1283ff4c77f12d60feecada2a7ee 4.39 GB
(SHA256) 401ad25266e775de26ad0852fc433194938013626fb3cfaff6e7cf78b071aa33

From https://www.ni.com/en/support/downloads/drivers/download.ni-rfsg.html#521569
https://download.ni.com/support/nipkg/products/ni-r/ni-rfsg/24.0/offline/ni-rfsg_24.0.0_offline.iso

20230811-labview-202023Q3-released

LabVIEW 2023Q3新特性

NI发布了LabVIEW 2023Q3,主要的新特性就是以下几点
第一个是等了很久的程序框图支持缩放,不过对字体的处理感觉不是很好
第二个是正在连出的连线左键双击快速创建控件,右键弹出快捷菜单,之前从右键移到二级菜单,如今终于回归了。
第三个是选中快速替换。
第四个是高亮执行可以选择速度了,长按高亮执行按钮可以在四种速度之间选择。

macOS下原生支持ARM CPU

不过这些新特性不是我最想聊的,我最感兴趣的是在Apple的macOS平台上终于原生支持M系列ARM CPU了,无需x86转译,并且驱动也已经移植了NI VISA,也可以原生支持ARM CPU了。这个时候可以畅想一下未来的Apple生产线测试设备可能是什么样的。

之前查到Apple要求所有生产测试环节一定要运行在MacOS平台之上。
Refhttps://www.zhihu.com/question/545108671/answer/2720242493
LabVIEW在这方面确实会有一定的优势,毕竟1.0的时候就是诞生在Macintosh平台上,后续的LabVIEW也一直有macOS平台的对应软件。

首先我们回顾一下Intel Mac时代,我们的选择有哪些?

对于需要硬件参与的测试设备,很重要的一点就是驱动支持,mac下主要就是DAQmx Base和NI Visa,可以使用M系列或者E系列的数据采集卡以及传统的台式仪器来开发测试系统。

DAQmx base最新版本是15.0,最高支持到OS X 10.14,所以最新的刨丝器Mac Pro 2019是用不了的,老款的Mac Pro垃圾桶是没什么扩展性的,显卡都是专门定制过的,更老的Mac Pro基本上是电子古董了。

用iMac或者Mac Mini的雷电接口连接NI的雷电 MXI机箱PXIe 1090就更不用想了,NI PXI Platform Service是没有OS X版的。

综合下来能用USB M系列数据采集卡(DAQmx Base)+LXI的台式仪器(NI VISA)就是这个测试系统基本构成了,上位机可以选择能装OS X 10.14以下的Intel iMac或者Mac Mini,性能需求特别高的也可以选Mac Pro,不过也就是垃圾桶,不见得就比iMac强。

如果稍微放松一点,允许使用双系统,那么上位机装Windows,就可以使用MXI连接PXI机箱,那么基本上所有的PXI板卡都可以选型和传统的测试设备其实区别不大。

如果未来Apple强行要求所有测试设备使用M1设备来开发,又有什么选择呢?

目前来看只能使用传统的台式仪器来搭建测试系统,梦回八十年代LabVIEW刚刚诞生的年代。

不过我要说不过了,台式仪器的操作系统Apple可没法限制,例如示波器的操作系统,有些是定制的Linux,有些是Windows For Embeded,那么我配一个下位机,装个WES的Windows是不是也可以擦边呢?

哪怕不用Windows,就用Linux RT,开发好RTEXE之后,定一个通讯协议或者就用VI Server,在上位机的Mac上用LabVIEW开发一个测试软件似乎也是可行的?

稍微展望一下未来,Apple生态下的测试系统可能会是什么样的?

展望未来,一种可能是NI出了适配macOS的DAQmx,这样就可以在M2的Mac Pro上使用PCIe的数采卡了,不过以NI停产绝大部分非PXIe的趋势,应该是不太可能了。

另一种是NI的驱动完善gRPC接口,LabVIEW通过gRPC接口从M系列ARM CPU的MAC上远程调用Linux RT下位机的板卡,这样板卡的选型也能更丰富一些

小小的总结

其实从操作系统的演进历史来看,硬件驱动的开发也是越来越复杂,并且限制越来越多的,DOS时代只要有中断和内存映射的地址就可以直接操作硬件,NT时代就有了WDDM,区分了Kernel驱动和User驱动,Vista时代更是有了驱动强制签名认证,Windows 10有了UWP驱动,系统封装的越来越完善。对于OS X也是类似,Kext内核扩展驱动也是增加了签名认证,并且现在系统有了SIP系统完整性保护System Integrity Protection。

未来如何达成系统方便性和安全性以及扩展性的平衡,只能等待厂家,开发商,用户三者达成新的博弈平衡了。

20230221-labview-cross-platform-interoperate

Windows和Linux下LabVIEW的VI互操作

LabVIEW 的一些问题

From https://lv.qizhen.xyz/appendix_problem

看到阮奇帧写的一个关于labVIEW Unicode支持的话题,这其实也是一个LabVIEW的顽疾了,实际上LabVIEW中文环境下的bug很可能就和这个有关。
Linux和macOS下,LabVIEW不仅早早完成了UTF-8支持和64位化甚至已经开始适配原生M1的ARM支持,但是Windows下仍然还是ASCII编码,导致LabVIEW RT不支持中文,Linux RT还是Pharlap下都会乱码导致VI断线。

现在Windows10和Windows11为了改善和WLS的互操作性,在控制面板的区域语言选项已经有了测试版的UTF-8支持,在Control Panel\Clock and Region\Region\Administrative\Language for non-Unicode programs\Change System Locale\Beta:Use Unicode UTF-8 for worldwide language support.可以尝试看看能不能生效,缺点是这个副作用是全局的,会影响所有非Unicode程序。如果生效,可以考虑用NTLEA或者其他第三方工具单独设置LabVIEW。

1676954407979

However there’s a “Beta: Use Unicode UTF-8 for worldwide language support” checkbox since Windows 10 insider build 17035 for setting the locale code page to UTF-8

From https://superuser.com/questions/1033088/is-it-possible-to-set-locale-of-a-windows-application-to-utf-8

可以利用微软官方的Windows SDK给LabVIEW签名,测试是可以单独给LabVIEW启用UTF-8支持的具体方法参考
https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page
用的是LabVIEW 2023Q3 64bit。

Fusion manifest for an unpackaged Win32 app:

From https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page

gb2312

From https://learn.microsoft.com/en-us/windows/win32/intl/code-page-identifiers?source=recommendations

首先备份一个LabVIEW.exe以备不时之需,
编写一个以下内容的LabVIEW.manidest文件:





UTF-8



然后安装Windows SDK,利用MT.exe对labVIEW.exe进行签名,如果都安装在默认路径,在命令行里面运行以下命令
“C:\Program Files (x86)\Windows Kits\10\bin\10.0.22621.0\x64\mt.exe” -manifest “C:\Program Files\National Instruments\LabVIEW 2022\LabVIEW.manifest” -outputresource:”C:\Program Files\National Instruments\LabVIEW 2022\LabVIEW.exe”;#1
用Linux的LabVIEW编写一个Test.VI

1676954492996

用普通的Windows下的LabVIEW打开,中文是乱码

1676954512158

用签过名的LabVIEW打开,中文可以显示

1676954528197

但是字体列表里面的中文乱码了

1676954542172

可以把签名和没有签名的LabVIEW.exe都保留,测试都可以打开使用

1676954554389

20221210-labview-fonts-fix

LabVIEW字体bug终极修正

图标编辑器中的文本变得模糊

来自 https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019ZTFSA2&l=zh-CN

除了设置控制面板为英文环境,也可以用改INI的方式修正

FontCodePageList=Small Fonts,1252
设置为中文显示

设置为英文字体显示

安全字体:

所有中文字体和英文界面字体:FixedSys,Terminal,SegoeUI,tahoma
不能显示的字体:Arial,Calibri,CourierNew,NI7SEG,consolas,Times New Roman,Small Fonts;

多字体修复

经过尝试,
可以添加多个字体
对EXE也有效
FontCodePageList=Small Fonts,1252;NI7SEG,1252

用注册表查询系统所有字体,然后追加到LabVIEW的INI文件

程序修复

发现LabVIEW读取注册表键值时没法确认键的数量,所以动态增加NumValues的数量直到超过后报错,然后再从大向小尝试直到不报错,就可以刚好把所有键值读取出来。

经过多次整理之后再把字体名称重复的去掉,最后添加配置项到搜索出来的LabVIEW.INI

常见Windows字体修复

如果没有其他特殊字体也可以直接给INI添加这一句
FontCodePageList=”Andalus,1252;Angsana New,1252;AngsanaUPC,1252;Aparajita,1252;Arabic Typesetting,1252;Arial,1252;Browallia New,1252;BrowalliaUPC,1252;Calibri,1252;Candara,1252;Comic Sans MS,1252;Consolas,1252;Constantia,1252;Corbel,1252;Cordia New,1252;CordiaUPC,1252;Courier New,1252;DFKai-SB,1252;DaunPenh,1252;David,1252;DilleniaUPC,1252;DokChampa,1252;Ebrima,1252;Estrangelo Edessa,1252;EucrosiaUPC,1252;Euphemia,1252;FZShuTi,1252;FZYaoTi,1252;FangSong,1252;FrankRuehl,1252;Franklin Gothic Medium,1252;FreesiaUPC,1252;Gabriola,1252;Gautami,1252;Georgia,1252;Gisha,1252;Impact,1252;IrisUPC,1252;Iskoola Pota,1252;JasmineUPC,1252;KaiTi,1252;Kalinga,1252;Kartika,1252;Khmer UI,1252;KodchiangUPC,1252;Kokila,1252;Lao UI,1252;Latha,1252;Leelawadee,1252;Levenim MT,1252;LiSu,1252;LilyUPC,1252;Lucida Console,1252;Lucida Sans Unicode,1252;MV Boli,1252;Malgun Gothic,1252;Mangal,1252;Microsoft Himalaya,1252;Microsoft JhengHei,1252;Microsoft New Tai Lue,1252;Microsoft PhagsPa,1252;Microsoft Sans Serif,1252;Microsoft Tai Le,1252;Microsoft Uighur,1252;Microsoft YaHei,1252;Microsoft Yi Baiti,1252;Miriam,1252;Miriam Fixed,1252;Modern,1252;Mongolian Baiti,1252;MoolBoran,1252;Narkisim,1252;Nyala,1252;Palatino Linotype,1252;Plantagenet Cherokee,1252;Raavi,1252;Rod,1252;Roman,1252;STCaiyun,1252;STFangsong,1252;STHupo,1252;STKaiti,1252;Sakkal Majalla,1252;Script,1252;Segoe Print,1252;Segoe Script,1252;Segoe UI,1252;Shonar Bangla,1252;Shruti,1252;SimHei,1252;SimSun-ExtB,1252;Simplified Arabic,1252;Simplified Arabic Fixed,1252;Small Fonts,1252;Small Fonts,1252;Sylfaen,1252;Tahoma,1252;Times New Roman,1252;Traditional Arabic,1252;Trebuchet MS,1252;Tunga,1252;Utsaah,1252;Vani,1252;Verdana,1252;Vijaya,1252;Vrinda,1252;Webdings,1252;Wingdings,1252”

安装

修正程序的源代码已提交github
https://github.com/lhb5883/LabVIEWFontsFix

可以在VIPM中搜索font找到LabVIEW Fonts fix 安装
安装好以后重启labVIEW,在LabVIEW的Tools菜单选择Fix Fonts…再重启LabVIEW就可以正常调用字体了。

20220802-labview-2022-released

LabVIEW 2022 Q3已发布

概述

NI在7月底发布了新版的LabVIEW和套件供下载,版本号为2022Q3,22.5,从这个版本开始,软件改为订阅模型,但是不知道以后会不会改成滚动发布,从LabVIEW的另存为低版本来看,还是有独立的版本号以解决兼容性问题。

值得关注的一个大变动是驱动和LabVIEW版本分离,详情可以看新特性中的具体说明。如果用高版本的labview打开和保存了公共VI,低版本打开估计会有问题,默认分离已编译代码应该只是规避了一部分,之前LabVIEW的打包EXE后可以用更高版本Runtime支持应该也是为了这个特性做的准备,怀疑公共库里面不少关键VI应该是封装成了打包库。但是对于需要修改的范例,不知道能不能做到未来2023修改后低版本的2022可以打开,我猜测应该是不行的,毕竟NI现在应该是希望客户一直升级的,现在就是不知道2023版会是原位升级还是会新装一个目录。

目前NI的这种订阅服务模式对需要维护客户固定版本的应用不太友好,除非都用SystemLink进行托管,要不然维护多个不同版本LabVIEW Runtime的工作量其实也不小,如果是工厂等没有公网环境下维护代码就更加麻烦。好在NI现在的订阅制是允许使用低版本LabVIEW的,可以规避这个问题,但是对于希望项目开发环境能够保持在一个稳定版本的LabVIEW上,就只能用非订阅制的旧版了。希望NI能把软件的授权改成JetBrains的半订阅制,订购一定时间长度的软件可以保留最初版本的软件激活,NI之前的口风是有一个专门的调试版的授权是永久的。(更新)查看了一下NI官网,调试版授权比LabVIEW一年订阅要略便宜,不过不提供安装媒体,而且看描述需要先购买一个订阅版的服务才行。

NI软件订阅计划

From <https://www.ni.com/zh-cn/landing/subscription-software.html>

其他小的变化有支持M1的Mac和支持Windows 11,不过对于目前的Windows 11还不算稳定,Bug还是不少,微软自己官方的Windows Server 2022还是基于Windows 10的,并且企业版的LTSC目前也是Windows10,并没有Windows 11的LTSC,我个人还是建议等到Windows 11稳定发布LTSC之后再配合LabVIEW使用。

除此之外需要验证LabVIEW 2022 64bit对cRIO的支持是已经做好了还是鸽掉了,不过这一点需要时间安装之后测试,从文档来看,暂时没有官方宣布。(更新根据实际安装测试,64bit下不支持cRIO,支持RT cDAQ)

另外一个缺点是2022默认使用NI网站的在线帮助了,不过好在本地帮助的CHM文件还在,32bit的帮助位于”C:\Program Files (x86)\National Instruments\LabVIEW 2022\help\lvhelp.chm”,64bit的也类似。

经过测试,NI在大包里面集成的版本号低于22.0的驱动都不支持LabVIEW 2022,包括Veristand也是,要等后续的更新了。估计和21版一样等到SP1的时候才能基本补齐。

目前看起来在RoadMap里鸽掉的我期待很久的特性有以下几个,希望未来能开发出来:

gRPC驱动远程调用协议支持

LabVIEW 64bit的cRIO支持

Uincode支持

LabVIEW在运行时中动态创建控件

高分屏支持

我个人比较期待的是Unicode支持,毕竟从2011之后,字体BUG就一直没修,LabVIEW如果把区域和语言选项如果设置成中文,很多字体是加载不出来的,而设置成英文的话,有可能会删除半个汉字,如果能借着这个机会把这个问题修正了,可以让人舒服不少,不用当2011钉子户了。

高分屏支持也是一样,如果有多显示器并且缩放比例不一致的话,LabVIEW鼠标和菜单经常错位,希望能好好修复一下。

长期来看比较重要的的特性其实是gRPC的调用,彻底实现了驱动层的解耦和分布式系统的底层支持,还有一个是运行时动态创建控件,不过这个需要一个NI官方实现数据和控件动态绑定的方法,不知道Data Grid Control是不是就是干这个的

另外补充一点,NI把InsightCM卖给了CutForth,其他大规模使用cRIO的场景就不太多了,感觉cRIO有点像Intel的凌动平台,很多搞物联网的都是用Intel的开发板搭出来原型,然后用ARM的板子量产。尤其是Intel收购赛灵思以后,cRIO也换了集成x86核的FPGA,虽然支持了DAQmx,但是成本也变高了,适合走量的场景不多。

CUTSFORTH ACQUIRES INSIGHTCM™ FROM NI

From <https://cutsforth.com/insightcm-acquisition-annoucement/>

新特性

已剪辑自: https://www.ni.com/docs/zh-CN/bundle/upgrading-labview/page/labview-2022q3-changes.html

在LabVIEW中比较VI

LabVIEW 2022 Q3(基础版、完整版和专业版)的所有版本现在都提供了比较VI的功能,并且不仅限于专业版许可证。

Python支持

LabVIEW 2022 Q3支持通过Python对象引用句柄使用Python节点。该引用句柄可用于传递Python对象,作为Python节点输入参数或返回类型。

选项默认值的改动

在LabVIEW 2022 Q3中,从新文件中分离已编译代码选项的默认值为启用。

调用MATLAB函数

可在调用MATLAB函数上设置断点,然后使用步入调试打开MATLAB(R)编辑器执行脚本。如安装了多个版本MATLAB,可右键单击函数并在快捷菜单中选择在MATLAB中打开,指定LabVIEW调用的MATLAB版本。

Actor.lvclass的uninit方法

在操作者框架中,Actor类新增了Uninit方法(取消初始化)。Actor可重写该方法,释放在执行Pre Launch Init.vi or Actor.vi时获取的资源。即使之前有错误发生,该方法仍然会执行。

支持独立于LabVIEW版本的驱动程序/工具包

LabVIEW早期版本的模块、工具包等附加内容都位于LabVIEW目录之下。从LabVIEW 2022 Q3开始,LabVIEW将从LVaddons共享目录加载这些内容。在Windows操作系统上,LVAddons的默认位置是C:\Program Files\NI\LVAddons。请注意,只有一部分NI驱动程序和工具包会随2022 Q3版本安装到此位置。驱动程序或工具包转到LVAddons目录后,无需升级或重新安装即可与新版本的LabVIEW一起使用。

贴上路径图作为参考

LabVIEW Roadmap (2022) - NI Community

https://forums.ni.com/t5/LabVIEW/LabVIEW-Roadmap-2022/td-p/4218319

Capability Upcoming 1-2 Releases Future Development
项目管理 Improvements to workflows with source code control tools
LabVIEW VI compare tool included in all editions (Base, Full, Pro)
Driver version independence from LabVIEW (no need to update drivers for every new LabVIEW release)
Improved LabVIEW Project Dependency Management
互操作 Call Python code running in virtual environments
Deploy Python scripts to NI Linux RT devices
Native gRPC server/client interfaces in LabVIEW
Better integration with MATLAB® for debugging between environments
Support for calling .NET Core Assemblies (.NET 5 or later)
系统支持 Support for Windows 11
Support for MacOS on Apple M1 devices
LabVIEW RT/FPGA 64-bit module support for CompactRIO
Data Communication additions (SSH API, IPv6 support)
改进 Support for Unicode in the IDE
Introducing Data Grid Control
Dynamically create controls at runtime
Improve LabVIEW IDE experience on high resolution monitors (e.g. 2560 x 1440)

大包下载

Windows 2022 Q3 Professional 64-bit English

Software Platform Bundle 2022 Q3

Name Checksum File Size
2022 Q3 (MD5) ce06c4ca6d95ff99a334d0ba6aa2927d (SHA256) 990fcd6f52a8b57cb7f1d31cee356e99406a047d6e82f87f9e20756a6e2f48c0 58.29 GB

From <https://www.ni.com/en-us/support/downloads/software-products/download.software-platform-bundle.html#460282>

https://download.ni.com/support/nipkg/products/ni-s/ni-software-platform-bundle/22.5/offline/ni-software-platform-bundle_22.5.0.49199-0+f47_offline.iso

Windows 2022 Q3 Professional 32-bit English

Software Platform Bundle 2022 Q3

Name Checksum File Size
2022 Q3 (MD5) c7c80ad9cd6f436a6d38a79ca05ebb3d (SHA256) 27869760ad84a02ecc0bed4cb8150152aa296b2a30fcbdacd55f18c441df767f 58.14 GB

From <https://www.ni.com/en-us/support/downloads/software-products/download.software-platform-bundle.html#460698>

https://download.ni.com/support/nipkg/products/ni-s/ni-software-platform-bundle-x86/22.5/offline/ni-software-platform-bundle-x86_22.5.0.49199-0+f47_offline.iso

Windows 2022 Q3 Professional 32-bit Simplified Chinese

Software Platform Bundle 2022 Q3

Name Checksum File Size
2022 Q3 (MD5) 0bd962fce7a18c0e71f347aa3c9ee1b7 (SHA256) 09402c7abfaccd7e174d0307339eb35897a082d99775fd61dcd7a7a46302a4b6 58.36 GB

From <https://www.ni.com/en-us/support/downloads/software-products/download.software-platform-bundle.html#460299>

https://download.ni.com/support/nipkg/products/ni-s/ni-software-platform-bundle-x86-zh-cn/22.5/offline/ni-software-platform-bundle-x86-zh-cn_22.5.0.49199-0+f47_offline.iso

LabVIEW 2022 Q3 Professional Mac OS English

Checksum(MD5)b474aa15fd54508dfaa05561ab83055b

https://download.ni.com/support/softlib/labview/labview_development_system/2022%20Q3/502141BB-01M_2022Q3LV-LMPro.iso

NI Linux Real-Time Offline Installation Support 2022 Q3

Name Checksum File Size
2022 Q3 (MD5) 39f7aef09d49123ec0ff221b1a0395a2 (SHA256) 142f11ca1c144c93f437733d92e7ab41ed9adf9a79ed2d65a628b0dd3b4a40c7 6.78 GB

From <https://www.ni.com/en-us/support/downloads/software-products/download.ni-linux-real-time-offline-installation-support.html#460621>

https://download.ni.com/support/nipkg/products/ni-l/ni-linux-rt-offline-installation-support-22.5/22.5/offline/ni-linux-rt-offline-installation-support-22.5_22.5.0_offline.iso

20220711-create-a-usb-reinstall-disk-from-a-ni-offical-pxi-controller-reinstall-usb-disk

NI Windows 10 系统恢复优盘复制

前言

NI PXIe-8861控制器出场安装的是Windows 10 IOT Enterprise 1809 SAC(The Semi-Annual Channel)版本,会自动更新到次新版本的Win10,对应的是企业版的Current Business Branch.
必须使用U盘进行安装才能识别为正版系统,IOT版本的特殊之处是不连接公网是不需要激活的,有一个延迟激活状态(Windows 10 IoT offers a third option, allowing devices not connected to the Internet to remain in a deferred activation state)而普通的企业版系统是必须要180天激活一次的。

注意点:

预装的Windows 10 IOT Enterprise 1809并非是LTSC版本而是SAC,是有商店和预装程序的,也会滚动升级;
官方的优盘虽然是16G的插进电脑是识别成一个8G的空优盘和8G的光盘镜像,使用UltraISO抓取镜像只有2.7G,无法完整抓取,经过刻盘测试无法正常安装系统。
使用复制的方法提取出来的安装包大概有8G,直接复制到优盘时会报错,经测试UEFI启动必须是FAT32分区,镜像的WIM文件有4.5GB,超过了上限。而使用exFAT分区得U盘是无法在NI控制器上正常启动的(按照标准UEFI启动只支持Fat32分区启动,有些第三方主板做了特殊处理支持其他格式的分区如NTFS或者exFAT启动到UEFI).
解决的办法是利用DISM命令或者第三方工具将Install.wim拆分为一系列Install.swm文件,使用工具拆分WIM镜像后要注意修改应答XML文件中的对应路径。第三方拆分工具gimagex可以图形化的拆分镜像文件。

其他

和之前尝试过的利用Acronis True Image提取一键恢复备份文件的方法相比,这种方式安装的Windows可以确保和硬件无关,不会因为网卡Mac地址不同而触发延迟激活失效。

20220427-what-is-the-relation-between-lean-6s-and-close-loop-management

精益生产 6s管理 归零管理的逻辑关系

前言

首先精益生产 6s管理 归零管理都是指导生产领域,对于研发领域,MBSE的V模型和双V模型才是更适合的方法论.

精益生产

精益生产结合了小批量和流水线的优势,提高了生产效率和资金效率:
小批量生产灵活性高,但是不容易标准化,成本高,航天是典型的小批量生产,并且研发和生产是二合一的。
福特的大批量流水线生产效率高,但是不灵活,库存和备料多,市场竞争下过度生产是常态,造成浪费。
人机料法环中机器必然过剩,减小料的耗费可以控制成本。
例如精益生产中十大工具中很多就是为了控制材料和元件的耗费
安灯系统:及时发现和处理异常,及时停线避免原料浪费。
看板管理:需求拉动控制库存。

6S管理

6s管理是为了实施精益生产的管理手段
6S即整理(SEIRI)、整顿(SEITON)、清扫(SEISO)、清洁(SEIKETSU)、素养(SHITSUKE)、安全(SECURITY)
目的其实是充分调动人的因素,在小批量的生产中控制复杂度,排除无效因素干扰。

归零管理

归零对应着精益生产的持续改进
技术归零指的是“定位准确、机理清楚、问题复现、措施有效、举一反三”;管理归零指的是“过程清楚、责任明确、措施落实、严肃处理、完善规章”。
归零法:这个方法的本质就是放大已经发现的任何微小异常,通过反复的追问,找到问题背后的本质原因,从而彻底解决问题。借鉴PDCA的方法论,所有问题都尽量解决在前,预防在前,是风险防控的理念,而质量管理归零就是风险防控措施的最有效手段,风险防控最精华的部分就是零缺陷管理。
用于极端小批量生产中控制风险,缺点成本较高。
1、对产品供应链完全掌控:指标、参数、性能、材料、工艺等等。甚至包含供应商的供应商。这样的控制程度无疑要付出巨大代价。产品成本会高出民用市场几倍以上。
2、零部件和产品总成必须有很好的跟踪机制。这样的回溯机制要付出巨大代价:每一个零件、工艺、批次、供应商、生产人员、日期等信息都是可回溯的。就像是古代盖城墙,每块砖上都有工匠的名字。用做菜举例:你知道你吃的午饭是什么品种、哪块地、什么时候收割、哪个厂家去壳、在哪装箱、谁来运输、谁做成米饭、谁给你端上来的?
3、全体人员都认可这一游戏规则,认为归零是必要的、必需的。这是企业文化层次的认同,最难形成。十年树木,百年树人。

20220425-how-to-choose-a-labview-version

如何选择LabVIEW版本?

LabVIEW 常见的BUG

  • LabVIEW 2010的Dll导入功能有问题,支持目录选择cINTools目录后无法继续.
  • LabVIEW 2009字体和语言处理有bug,并且无法绕过.LabVIEW 2009本身容易闪退.
  • LabVIEW 2012+字体和语言处理BUG可以通过语言格式设置绕过,但是可能会删半个字,或者计算字符串显示区域出错.
  • LabVIEW 2019+中文版安装其他软件时会报RabbitMQ错误.
  • DAQMX中文版建立任务时文字描述出错,可能会把输出搞成输入.
  • 中文版LabVIEW在计数器任务生成范例和代码是出错,只能生成空VI.
  • 中文版RT模块打包RTEXE之后断线

    LabVIEW建议跳过的几个版本

    LabVIEW 2009:出了64bit

LabVIEW 2010:换了LLVM编译器

LabVIEW 2016:放弃32bit XP,开始NXG的开发

LabVIEW 2019:开始更换NI Package Manager 支持Linux RT

LabVIEW 2021:放弃Pharlap ETS

LabVIEW 值得关注的几个版本

LabVIEW 7.1本体无需激活的最后一版

LabVIEW 8.5模块和工具包无需激活的最后一版

LabVIEW 2011个人使用Bug最少的一版

LabVIEW 2015支持XP系统的最后一版

LabVIEW 2018传统安装包的最后一版

LabVIEW 2020支持Pharlap的最后一版

LabVIEW的VI兼容策略

LabVIEW高版本可以打开低版本VI,目前来说打开VI可以向下兼容到LabVIEW 6,

LabVIEW无法打开高版本的VI

加密VI可以升级版本,但是没有密码的情况下无法降级

另存为前期版本最多可以保存到LabVIEW 8.

LabVIEW的模块和工具包兼容策略

LabVIEW模块必须和LabVIEW版本一一对应,模块一般对应的是不同的运行目标和对应的编译工具链,所以图像,控制设计仿真,状态图和RT还有FPGA一样都归属于模块.简单的来说能给LabVIEW增加交叉编译功能都属于模块

LabVIEW官方工具包分为两种情况,新版也是一一对应,LabVIEW,旧版有的可以兼容三个版本,有的自动安装到最新版本的LabVIEW里。

VIPM安装的工具包理论上如果没有依赖特定版本的官方模块或者工具包,一般都是可以被高版本的LabVIEW支持的,只是不能被低于编写工具包版本的LabVIEW使用。

LabVIEW的驱动策略

一般驱动是向下兼容三个版本的LabVIEW,但是依赖特定版本模块的除外。

另外NI的驱动是可以并行选装的,所以安装的驱动越多,后台服务越多,占用的资源也越多。

LabVIEW的语言和Bit兼容策略

LabVIEW的32bit有六国语言,但同版本只能安装一种语言。

LabVIEW的64bit版只有英文,不过64bit的可以和32bit的同时安装,z共用同一个License

结论

简单用户

对于英语不好只使用DAQ板卡,不使用RT或者FPGA的用户,可以用LabVIEW2011中文版(或其他值得关注版本)加对应DAQmx。

进阶用户

如果必须要使用RT和FPGA,但RT和FPGA部分较为简单,可以确认自身编写的代码没有问题,可以考虑装最新的中文版LabVIEW和RT+FPGA,出现BUG之后再替换为英文版的。

学习者

在学习阶段,装一个次新版本的中文版LabVIEW及对应模块,装一个最新英文版和64bit版的LabVIEW及对应模块,驱动安装最新版的,利用向下兼容支持次新版的LabVIEW。

资深开发人员

建议全套英文版开发环境,如果有多版本的项目同时开发,可以通过虚拟机分离,一个虚拟机里面最好只装一个对应版本的全套开发软件和驱动。
本机上编写代码装一个LabVIEW 2011,查看代码安装一个最新版的LabVIEW,避免从别的地方接收到的VI无法打开。但是不建议装驱动,因为具体开发还是要在对应版本的环境中比较好。

展望

另外多说一句LabVIEW 2021开始64bit官方功能完全和32bit对齐的一版,具备了RT和FPGA模块,不用在64bit中写下位机,32bit中写上位机,等迭代上几年后解决了安装包冲突的问题,以后初学者就可以装一个32bit的中文环境用来学习,同时64bit的英文环境用来开发,入门可能会更方便一些。

20220403-something-about-python-and-playback

之前一些没有发到github上的文章汇总

Python调用LabVIEW动态链接库

Python调用LabVIEW动态链接库其实和调用一般Windows链接库类似,但是也有一些额外要注意的事项。

32bit和64bit问题
ctypes封装问题
LabVIEW runtime依赖问题
32bit和64bit问题
Python调用DLL出错最常见的就是bitness不一致,64bit Python调用32bit LabVIEW DLL会爆出以下错误

OSError: [WinError 193] %1 is not a valid Win32 application

Python基本上现在都是64bit的了,但是LabVIEW现在还是32bit居多,因为虽然NI自己大部分工具包和驱动虽然已经支持64bit的LabVIEW了,但是很多第三方工具还只支持32bitLabVIEW。

究其根本原因,还是Windows下 64bit进程只能调用 64bit DLL,IE11以及Office能支持32bit旧插件全靠黑科技多进程64bit进程混合32bit进程调用,Chrome的32bit版也是靠多进程跨过32bitOS的2G内存限制,不过很多没有那么多开发人手的公司选择了放弃32bit只支持64bit。

例如Adobe的Photoshop以及Mathworks的Matlab,很早就64bit化并放弃32bit支持。NI的LabVIEW其实很早就开发了64bit版本,但是因为有很多硬件支持并且有很多代码是已经编译的32bit dll,因此一直还在维护32bit的LabVIEW。

并且32bit的LabVIEW还是大部分人的主力版本,所以这个问题是绝大部分LabVIEW开发人员都会遇到的第一个问题。解决问题的方法就是LabVIEW和Python都用32bit版本,或者都用64bit版本,如果没有特殊情况比如必须用的某个工具包是32bit的,那么建议用64bit版,内存使用可以比较充裕,并且现在64bit版本的Python已经是主流版本,32bit下出现问题不一定能找到解决方案。

ctypes封装问题
python和LabVIEW一样有一个类似Call library Node的调用DLL的库,名字叫ctypes,这个库和CLN一样,只能调用c接口的DLL,并且要指定是ANSI C还是WinAPI C(这个主要是决定调用方清理内存还是被调方清理内存)一般来说,只要这个选对了,至少dll就能在Python中加载了,但是调用成功就要看函数参数的配置了。

CLN节点在定义的时候就要设置函数原型,并且要声明每个参数的数据类型,这一点决定了LabVIEW中如果有复杂的动态长度的动态类型,就可能无法正确分配内存和调用,而ctypes的好处是这个构建过程是编程控制的,可以动态创建数据结构,非要对比的话,类似于之前LabVIEW有一个CIN(C Inline Node)c内嵌节点,可以直接嵌入C语言源码由LabVIEW编译执行,但是因为容易崩溃,后来的LabVIEW新版本取消了这个功能。

理论上因为LabVIEW打包的DLL一般数据类型比较确定,所以只要注意簇或者数组结构的配置应该没有什么问题。

LabVIEW runtime依赖问题
其实和用Visual Studio开发的VC DLL需要依赖C runtime一样,LabVIEW打包的Dll也是需要LabVIEW对应Runtime Engine的,并且如果调用了其他dll或者dot net需要把C Runtime,dll,dot net都要打包。

尤其要注意路径关系,有些库写死了计算相对路径的方式,所以源代码调通之后,打包dll之后一定也要调通确认。打包安装包之后也最好在新机器/虚拟机上部署一遍,确保没有遗漏依赖项。另外在调试过程中也可以借助Dependency Walker确认依赖关系。

数据文件回放的一些思考

最近在做一个cDAQ的数据采集分析项目,遇到了一个不大不小的问题。cDAQ上只有2G内存,安装了WES7 32bit OS。采集时因为波形是部分显示,所以没什么问题,虽然CPU占用较高,但可以正常保存纯文本数据文件。但是在回放数据时,需要做全趋势显示,加载文件到波形图时提示内存不足;

这个问题我之前在一亿像素的图像采集中遇到过,用加内存和换64bit LabVIEW解决了,但是这种嵌入式的cDAQ内存和CPU都很有限,只能螺蛳壳里做道场了。最后总结出来的几个原则:

显示器上横向分辨率是有限的,因此能显示的点数不可能超过横向分辨率;
LabVIEW的波形图控件在显示前做了抽点,但是全曲线需要把整个文件赋值给控件,这样内存占用就会很高;
TDMS利用Offset可以很容易的手动编程抽点,不需要很多内存。
CSV文件也可以利用文件大小进行粗略的抽点,设置Offset之后,读取两行,第二行是完整的。
如果需要缩放功能,根据缩放的范围进行二次抽点即可
如果希望抽出的点能代表轮廓,需要计算抽取间隔中所有点的最大值和最小值,这种情况建议生成一个索引文件以减小后续的计算量。

20210818-labview-2021-released

LabVIEW 2021 Released

经过上周末的NI网站维护,LabVIEW 2021终于发布。

从这个版本起,LabVIEW不再支持Win7,Win8等老操作系统,最低也要是Win 10起,以下是支持的操作系统:

Windows 10

Windows Server 2019

Windows Server 2016

除此之外虽然LabVIEW还有32bit版本,但是已经不再支持32bit的OS了,也就是说只能在Win 10 64bit上安装和使用。

对于今年发布Win11,NI还没有作正式声明是否支持,不过理论上来说是可以靠向下兼容支持的,但是如果微软在权限上继续收紧,也许会有未知的bug。

对于LabVIEW RT 从这个版本正式去掉了Pharlap ETS支持,也就是只支持Linux RT一个系统了,不过要注意的地方是NI的硬件板卡对Linux的支持和对NI Linux RT是有区别的:

Linux支持的板卡较多但可能仅有板卡驱动和C接口,没有LabVIEW接口;

NI Linux RT支持的板卡较少,目前NI还在不断地移植,除了板卡驱动,还有LabVIEW支持,能够直接用LabVIEW调用板卡。

例如之前NI Switch一直说在20.5加上NI Linux RT支持,但是NI一直没有发布20.5,网站上能下载到的就是20.0。

此外之前LabVIEW NXG Web Module现在变成了独立软件“G​网络​开发​软件”,不再依赖NXG