Rolf Kalbermatter

Well, if you stick to strict OOP principles, modularizing it through plugin mechanism and similar should be fairly easy to do! It takes a bit of time to create the necessary plugin mechanisms and requires about at least 3 iterations before you end up with something that really works but that is still magnitudes easier than waiting on a 18k VI project to load every time and fall asleep between edit operations. That's one more reason why I usually have a wrapper shared library that adapts the original shared library interface impedance to the LabVIEW Call Library Interface impedance. 😀

One thing I have seen in the past running really havoc with the LabVIEW editor and/or compiler were circular dependencies. Very easy to end up with even in moderately sized projects if one uses globals. Absolutely unavoidable without a proper design and avoiding globals almost entirely, except in very carefully chosen places, for large projects. The LabVIEW editor/precompiler does pretty much a full pass over the internal data graph for every edit operation. With circular dependencies the graph gets effectively infinite in length and while the system has checks in place to detect such circular references and abort the parsing at some point, it seems not able to do that safely just on the first occurrence without missing some paths, so goes on longer than is most of the times necessary. First sign usually shows up as frequent inability to build the project without obscure errors, especially for realtime targets. Things go ok much longer for builds on Windows, but drop the project code into a realtime target and builds and/or deploys will cause all kind of hard to explain errors. A 18k VI project! That's definitely a project having grown out into a mega pronto dinosaur monster. I can't imagine to even consider creating such a beast. My biggest projects were probably somewhere around 5000 and that was already getting very painful to do any work on. And caused me to modularize it eventually, with parts moved into realtime targets. The cost for the additional hardware were actually smaller than the time lost keep trying to get the monster to build and work, despite that NI realtime hardware is anything but cheap. But I inherited in the long ago past a project that consisted only of maybe 100 VIs. However it consisted of a main VI that was something like 15MB in size (the other VIs were mostly just simple accessors to drivers and ... shudder ... several dozen global variables), with the main VI being one huge loop with sequence structures inside case structures, inside loops, inside more sequence structures, inside even more case structures and loops and this continued for a few more levels like that. Not one shift register, everything was put in globals and written and read back 100ds of times. Editing that VI was a painful exercise, select a wire or node, wait 5 seconds, move the wire or node, wait 5 seconds ... . I have no idea how the original developer ever got this to that point without going insane, but more likely he was insane to begin with already. 😀 I was several days busy to just get the diagram a bit cleaned up by adding some shift registers to manage the actual data more efficiently, identify common code constructs that appeared all over the place over and over and place them into subVIs, and get everything to a state that was reasonably workable before I could really go and refactor that application. In the end I had maybe 500 or so VIs and a main VI that was well below 1MB with a proper state machine and almost no sequence structures anymore. And it run reliably and when you pushed the stop button you did not have to wait half an eternity before the application was able to detect that. The biggest irony was that the application actually was working with an enum state with some 100 or more states, maintained in a global and in almost every sequence frame there was a case structure that would have one or a few cases for a specific state and a default that was doing pretty much nothing. It was a state machine turned inside out and then put into a cascade of sequences!

Libre Office/Open Office is an open source implementation of an Office suite of applications. It delivers similar application as the Microsoft Office package and they work in many ways similar but are not the same. If you are a seasoned Excel, Word or whatever user, they require a little bit of relearning and getting used to. They support a 3rd party interface similar to the Microsoft Office Active X interface but it's not the same and will not work with the Report Generation Toolkit (RPT). One would need to write extra RPT plugins for that, except that while NI made the RPT plugin based, they kind of borked the instantiation of plugins by not making it easily extendable. The available plugins are hardwired in the implementation and extending that would require modifications to the NI implementation, which is considered by most developers a no go as you have to modify the Toolkit on every installation and reapply the modification anytime the Toolkit is reinstalled/updated by NI, which might or might not break your modifications too.

There is a good chance that Microsoft eventually dropped support in Office for 32-bit applications. What I wrote above was true 2015 - 2020. Haven't ever tried to use Excel from LabVIEW since, and generally use Libre Office anyhow if I need an Office application.

It could be made to work in the past. Basically the Office interfaces are all ActiveX based. ActiveX is very well able to invoke an ActiveX Automation Server out of process through an ActiveX proxy server process in the background. If the ActiveX Automation Server is properly registered this happens transparently in the background without extra user interactions. Unfortunately the so called Click to Run MS Office installers that are nowadays used, either forget to do the 32-bit registration of their Automation Server component or somehow bork it up. I have been in the past able to fix that on different machines by running a Repair Install from the Windows Applications control panel.

I've got the same HA Yellow. Still need to actually set it up properly. Got it installed and started up but not integrated with the devices in the house. So many other things to do too. I like that the CM4 module uses real flash memory rather than the SD card of the normal RPi. Much more reliable for a box that typically is put in some corner or your metering cabinet and then left on its own for pretty much all of the time.

They still have something akin to the Alliance Member program. Not sure if it is still called that. Used to work at one too, but am now in academia. As to running LabVIEW directly on a HA, that is not currently possible. Well it may be possible with some emulation if you get an x86_64 emulator running on your ARM HA hardware but that is: 1) a major project to get running, with lots of obstacles, many tricks and a huge chance that what worked yesterday suddenly fails for unexplainable reasons 2) a taxing solution on the poor ARM CPU in your typical HA box The current Hobbyist Toolkit is maybe the most promising solution at this point. It can deploy compiled VIs to a Raspberry Pi and run them headless on the Raspi. But as it is now it's a bit of a pitta. It requires its own chroot environment to provide an ARM environment that is compatible with the ARM CPU in the low cost NI RIO hardware. This is distinctively different from the ARM binary mode typically running on your Raspberry Pi or any other modern ARM hardware. It is 32-bit, and uses the so called softFPU mode where FPU commands are emulated on the ARM core itself, rather than using Neon or similar FPU hardware integrated in all modern ARM chips. And new Raspberry Pi OSes including what HA is using (when running on Raspi hardware) have all changed to 64-bit nowadays, which is with the current Hobbyist Toolkit still a bit of a hurdle but can be worked around if you know what you are doing. There is some talk from NI that they may maybe support a native Raspberry Pi version of this, where the LabVIEW program is deployed to the actual Raspi itself rather than into a chroot container on the Raspi. If that is ever going to see the light of the public, how and in what form is completely unclear. There are several challenges, some technical such as making sure the LabVIEW runtime properly can interact with the window manager on the Raspi (that should be fairly trivial as it is the pretty much the same as what LabVIEW for Linux needs) but also more economical/marketing: How to justify the effort and cost of developing and especially maintaining such a solution without any tangible income in the form of hardware sales? Making it an extra licensed feature is also not very feasible, people are usually not willing to pay 100ds of bucks for a software license for something to run on a 50 to 100 bucks hardware platform. And even with that, your development would still be on a Windows box, in the same way as you develop code for the NI RIO hardware, where you have that hardware as a target in your LabVIEW project. Writing VIs and debugging them happens on your Windows box and when you are confident that it works, you deploy the resulting compiled VI code to the target and let it run there. This so far only works under Windows. And porting that to a Linux host is a major undertaking that I'm not sure NI has invested any real effort into so far. Directly running the LabVIEW IDE on the Raspberry Pi is probably even more unlikely to happen any time soon.

LabVIEW DSC does this with an internal tag name in the Control and the according configuration dialog allows to configure that tag name.

I assume that support for the old *.cdf NI-Max format for installation onto pre LabVIEW 2020 RT targets is not a topic anymore and you guys rather expect *.ipk files? Maybe add a download feed to the OpenG Github project for this? 🙂

I come across them regularly here at the university. There are quite a few setups that are fairly old already and just need some modifications or updates and they work and work and work and work like a clock once setup properly. Developing for them gets harder as you have to use LabVIEW <= 2019 for that.

Actually I do vagualy remember that there was an issue with append mode when opening a ZIP file but that is so far ago, I'm not really sure it was around 4.2 times rather than a lot earlier. I'll have to get back to the 5.0.x version and finally get the two RT Linux versions compiled. Or are you looking at old legacy RT targets here?

You may also want tell people where you can actually download or at least buy this. Although if you want to sell it, do not expect to many reactions. It is already hard to get people to use such toolkits when you offer them for free download.

Reformatting the post which is more easy on the eyes and uses a normal font and doesn't require a 200" monitor to read properly would already help a lot. Pretty much all of that Dynamic Signal stuff with Express VI complexity would be possible to do in a simple VI that uses a lot less code and screen space. And you are not using an Excel file but a tab separated text file, which is of course more than capable to do what you need, and can be read by any application that can read text files.

That question seems very unspecific. LabVIEW base package? What has that to do with PXIe? Why high end (and price) hardware on one side and lowest cost LabVIEW license on the other? LabVIEW Base is simply the IDE. No application builder, no source code control help tools, no analysis libraries, no toolkits and no nothing. You still can get pretty far with it, especially if you use VIPM and OpenG libraries, but yes it is limited.

If your system is not resource constrained I kind of doubt that the 550kB VI size is the issue. It would more likely seem to be a corrupted VI somehow. While it may still load for simple executing, LV Compare tries to access a lot more information in the VI resources to make a proper comparison, and if some of that is corrupted in one of the two VIs it may simply crash over such inconsistent data.