All Activity

VISA would be my first port of call. NI state that multiple run-time versions can co-exist side-by-side but ... After 2016 you can configure the run-time version, IIRC. If you are really stuck, you can try running in a VM on an older version of Windows.

OK thanks, I’ll try this solution and hope it sorts out my problems. But as for the applications I use: my suppliers have informed me that one of them requires the RT 8.5 runtime environment to work properly, whilst the other two require RT 2016 and 2020. In this case, RT 2022 might resolve the issues, but the transition from version 8.5 to 2022 is a very long process, and I’m not sure whether that environment will support such old applications.

After years of commercial availability, the CalcExpress toolkit has transitioned to an open-source project under the terms of the MIT License. Starting with version 4.0, which also introduces new features, all LabVIEW VIs, C engine source code, developer tools, and documentation assets are publicly available on GitHub: https://github.com/konstantin-shifershteyn/calcexpress Installation and Distribution • VI Package Manager (VIPM): CalcExpress is listed in the VIPM package repository for direct installation. • Direct Downloads: Distribution packages are available via GitHub and the NI LabVIEW Tools Network. https://github.com/konstantin-shifershteyn/calcexpress/releases/tag/v4.0.1 https://www.ni.com/en/support/downloads/tools-network/download.calcexpress.html#372381 Licensing and Contribution Under the MIT License, users are free to download, install, modify, and integrate the toolkit into both personal and proprietary commercial applications without restriction. Community members are welcome to use the software free of charge and contribute to future development. About CalcExpress toolkit CalcExpress is an add-on for LabVIEW on Windows (32-bit and 64-bit) that introduces text-based scripting, formula/expression evaluation, and advanced data management tools. CalcExpress is a mature product with a quarter-century history of active development and successful use across many organizations worldwide. For many years, it has been listed on the LabVIEW Tools Network. More information can be found in the GitHub repository and the product's documentation.

Assuming you don't have any applications installed that actually need the 8.5 or 2016 runtime, I would start by updating VISA to 2022Q3. That is the first version that officially is supported on Windows 11 and should still be fully compatible with LabVIEW 2020. That may potentially fix your communication issues, but no guarantees.

Hello everyone I have a question for my more experienced colleagues in LabVIEW programming I use various applications supplied by a third-party company, built using LV2020 and RunTime 8.5, 2016, 2020 and VISA 4.6. Recently, I’ve noticed that various stability issues have started to occur whilst they’re running (freezing, slow performance, loss of communication via COM ports, etc.) Consequently, I began to look into the matter and discovered that LV2020 does not support Windows 11, let alone the aforementioned drivers and RunTime. Is there any way to run such applications stably on Windows 11 without having to modify them or rebuild them using a newer version of LabVIEW, such as 2025?

Nice to see the source and docs opened up too, not just a free binary drop. MIT should make it much easier for old LabVIEW projects to keep this alive.

Never heard of or used it but great news about MIT open sourcing.

After years of commercial availability, the VI Helpeks toolkit has transitioned to an open-source project under the terms of the MIT License. Starting with version 3.1, all source code, developer tools, and documentation assets are publicly available on GitHub: https://github.com/konstantin-shifershteyn/vihelpeks Installation and Distribution • VI Package Manager (VIPM): VI Helpeks is listed in the VIPM package repository for direct installation. • Direct Downloads: Distribution packages are available via GitHub and the NI LabVIEW Tools Network. https://github.com/konstantin-shifershteyn/vihelpeks/releases/tag/v3.1.0 https://www.ni.com/en/support/downloads/tools-network/download.vi-helpeks.html#372323 Licensing and Contribution Under the MIT License, users are free to download, install, modify, and integrate the toolkit into both personal and proprietary commercial applications without restriction. Community members are welcome to use the software free of charge and contribute to future development. About VI Helpeks VI Helpeks is a LabVIEW add-on providing UI tools and API VIs for generating professional documentation for VIs and palettes in HTML and CHM formats, matching the native LabVIEW Help style. It has been listed on the LabVIEW Tools Network for many years and was named a finalist for the LabVIEW Tools Network Innovation Product of the Year 2013.

I’m seeing compile insanities in JSONtext’s “Get all Object Items (by Offset).vi” during a mass compile. The VI is installed at: C:\Program Files\National Instruments\LabVIEW 2026\vi.lib\JDP Science\JSONtext\Offset\Get all Object Items (by Offset).vi The errors are: Insane Numeric(1203) in FPHP of "JSONtext.lvlib:Get all Object Items (by Offset).vi": {tdname } (0x4000): owner=Array(1541) Insane Numeric(1660) in FPHP of "JSONtext.lvlib:Get all Object Items (by Offset).vi": {tdname } (0x4000): owner=Array(1610) They appeared while mass-compiling code in a LabVIEW 2026 Q3, 64-bit project. Our project manifest pins JSONtext 1.9.1.125. Note: It seems like this issue was reported a couple years back on the VIPM forum but never addressed. Just recreating the controls should solve it i think.

Simple solution. Remove it from the palette. If someone accesses "private" methods to do things and encounters unexpected problems stemming from unexpected use of such methods, it's entirely their problem. If a function is however on the palette, it should have a minimal protection against wrong inputs.

Seems a bit of a cop-out. Especially so since it is designed to return "Not a JSON Value"

JSON type.vi is not a validator; it is a very cheap operation to determine the type of a JSON item. If you feed it non-JSON then it will be wrong. If you want to validate, use the Next JSON Value function first.

I mainly work in LabVIEW 2026Q1 and since shortly Q3 on my work machine but keep the project sources in LabVIEW 2020 or sometimes older and use those VIs sometimes back to version 2018 on other machines without such problems at all. It's quite likely something in some VIs you are using in your project and which are part of your sources. Did you maybe happen to copy some stock VIs of LabVIEW and modify them and add them to the sources of your project? I could imagine that that might cause possibly problems if they call into specific DLLs.

I’ve always used LabVIEW 2021 for development. Later, I started using LabVIEW 2026. I have a project that was originally developed in LabVIEW 2021 and was later maintained in LabVIEW 2026. Now I want to switch back to LabVIEW 2021, and I’m running into a problem. After I use LabVIEW 2026 to save the project as a LabVIEW 2021 version, I can open it in LabVIEW 2021. But after I save the project, when I open it again in LabVIEW 2021, LabVIEW crashes immediately. I don’t know what’s causing it. Has anyone encountered a similar issue and could offer some suggestions?

Te comento que revise tu referencia y logre que funcione y cubre mis expectativas. Ahora debo consolidar la info que recibe y sus calibraciones. Luego buscaré mejorar la interfaz gráfica. Muchas gracias por tu interés. Un saludo desde Córdoba, Argentina.

Definitely try running without the UI and anything plugged into the display port. I know we had an issue with the display port causing crashes after 2 days. Pulled the display port and the cRIO ran fine.

Lo he estudiado y podria andar para lo que necesito, pero no sera facil al menos para mi. Respecto al otro, Si, comenté pero sin respuesta. Muchas gracias por tu ayuda 😊

Hello together, since we moved to LV 2026Q3 (from 2023Q3), some of our classes are locked as soon as a certain packed lib is loaded. I'd like to know whether anyone has seen this or has an idea what is going on. Setup, where i recreated the issue: BaseLib.lvlibp : BaseCtrl.lvclass | has a dynamic dispatch method "DoSomething.vi" CtrlLib.lvlibp (uses BaseLib.lvlibp) | an XControl whose Init ability calls "DoSomething.vi" on a ChildCtrl object. ChildCtrl.lvclass overrides "DoSomething.vi" SrcChild.lvclass: a source class that inherits from BaseLib.lvlibp:BaseCtrl.lvclass Repro: Open Test/Test.lvproj which contains BaseLib.lvlibp and SrcChild.lvclass -> SrcChild is editable. Add Test/CtrlLib.lvlibp to "My Computer" -> SrcChild is locked. The error message I get on "Why is Library Locked?": The library is locked for the following reason(s): A vi in the library is reserved in this application instance or another application instance. The containing library is locked. Nothing else is running and no XControl instance exists on any FP. The execution states after adding CtrlLib.lvlibp: Running: Init.vi, Facade.vi, BaseCtrl:DoSomething.vi, the ChildCtrl override and SrcChild.ctl Idle: Data.ctl and State.ctl Before CtrlLib.lvlibp is added, everything is idle. Where I stand so far: LV 2023Q3 with the identical code does not have this issue. The XControl is required. CtrlLib.lvlibp with only ChildCtrl (XControl removed) does not lock SrcChild.ctl Classes without a parent are not affected. SuperSecretPrivateSpecialStuff does not matter. I tested with and without it -> same result LV 2024 and 2025 are untested. My environment: Windows 11 24H2 LabVIEW 26.3.1f1 64-bit Has anyone seen this problem before and knows what i can do to prevent it? I attached the repro projects in versions 2026Q3 (to show the issue) and 2023Q3 (to show that it worked before). Thanks in advance! ReproCode_LV2026Q3.zip ReproCode_LV2023Q3.zip

JSON type.vi returns JSON Object when trailing } is missing:

Maybe this could be a start to look at: https://forums.ni.com/t5/Example-Code/Artificial-Horizon-with-LabVIEW/ta-p/3498922 Or this discussion as some inspiration, it does not contain any VIs you could download and not sure if Chris Ludwig is still active and can be contacted: https://forums.ni.com/t5/LabVIEW/Aerospace-Indicators-Artificial-Horizon-Primary-Flight-Display/td-p/4217092 But you seem to have commented on this second thread already back in August.

Have you tried running the application without UI? The NI Linux RT UI subsystem is a handy debug tool and tempting to use as local operator interface, despite its somewhat arcane look, but I remember having had quite some trouble in the past when using that for normal operation. Admittingly it's some years ago, ca LabVIEW 2018/19 but certain setups with specific additional software tended to lock up frequently in very similar ways. Sometimes it was only the local UI that hung but often the entire controller seemed kind of hung somewhere and even remote connections couldn't reach it anymore without a power reset. Debug logs sent to NI at that time indicated that resource management in the UI seemed to be buggy and accumulate stale memory objects until the controller run out of resources and the whole OS kind of stopped responding to anything. Our resolution back then was to only use the local UI for testing and debugging and disable it for in production operation.

Hola, necesito un instrumento: Horizonte Artificial o Control de Actitud, para panel frontal version 2010. Si alguien puede apartarlo desde ya muchas gracias. PD: seguramente este tema ya ha sido tratado pero, utilice el buscador y no lo pide hubicar.

大家好，我正在学习LabVIEW如何调用模拟量输入输出模块，在程序运行时出现错误，各位大佬有没有知道这是什么原因，该怎样解决呢，万分感谢！

Thank you for your very fast answers. How stupid from me using the wrong conversion. Also the simplification of String to Byte array. Good night.

You should replace the Type Cast with a String To Byte Array. It turns the type cast into a NoOp under the hood and is just a lot easier to read. I also highly recommend you turn on the Display Style for all of your string controls and indicators (Right-Click->Visible Items->Display Style). This is a way of making sure you know how your data is encoded and eliminate a lot of confusion. CT003 CRC checksum.vi