Rolf Kalbermatter

LabVIEW realtime support is only existing in the never officially released OpenG ZIP Library 4.1. That package is only available as download from earlier in this discussion thread here on LavaG and over at the NI forum I believe.

All I can say is that you are operating in the LabVIEW attic, which has many rusty nails sticking out and blank unisolated life copper wires. 😀 As Greg Mc Kaskle once said in some different words about this attic: We do reasonable efforts to protect the innocent from getting into it and getting hurt, but if someone is determined to go in there he should not complain if he gets hurt somehow.

Well the OpenG ZIP tools don't really represent a lot of elements on the realtime. Basically you have the shared library itself called liblvzlib.so which should go into /usr/local/lib/liblvzlib.so and then you need to somehow make sure to run ldconfig so that it adds this new shared library to the ldcache file. When you install the Beta version of the ZIP Tools package you should get a prompt at some point for administrative login credentials (or an elevation dialog if you are already logged in as administrator) which is caused by the ogsetup.exe program being launched as PostInstall hook of the OpenG package. This ogsetup.exe program does nothing more than extract the different shared libraries into C:\Program Files (x86)\National Instruments\RT Images}\OpenG ZIP Tools\4.2.0. Depending on your target you need to copy the according liblvzlib.so from either the LinuxRT_arm or LinuxRT_x64 subdirectory to /usr/local/lib/liblvzlib.so on your target. That should be all that is needed although sometimes it can be necessary to also run ldconfig on a command line to have the new shared library get added to the ldcache for the elf loader. With the old installation method in NI-MAX this was taken care of by the installer based on the according *.cdf file in the OpenG ZIP Tools\4.2.0 directory. I tried to checkout the NI Package Builder but can't see how one would make a package for RT targets. I also only see the 20.5 and 20.6 versions of the NI Package Builder as last version, maybe that is why?

So is there a problem with installing the OpenG ZIP tools for LabVIEW 2020 and/or 2021 on a cRIO at all or was that inquiry from Jordan something else? I can not place packages on the NI opkg streams so yes this library will always have to be sideloaded through NI-MAX in some way, unless you want to copy it over yourself by hand into the right directory and create the necessary symlinks on a command line and then run ldconfig. 😀

I would guess that it uses the standard MgErr codes: 5 - file already open, 8 - permission error which might be a follow-up error, 6 - file IO error which means that something happens during reading or writing of a file that the programmer is not finding another error to map it too.

Well VIPM originated from OpenG Package Manager and OpenG Package Builder which had several different incarnations before it was sort of abandoned and then taken over by JKI to build the VIPM from. However VIPM is not just a somewhat niced up OpenG Package Builder but uses a rather different concept of building packages. The OpenG Builder simply listed all the files and gave you various options to change for each file how it needs to be installed and where. Very flexible but also quite complicated to keep an overview. VIPM changed that to let you create file groups that are all handled as a whole. Much simpler to manage and configure for the user but somewhat more limited. But it does the job for 99% of the users perfectly. Very few people want a fine grained configuration down to file level. The only gripes I have with VIPM is that it still doesn't natively support to include both 32-bit and 64-bit versions of files and have them install depending on the LabVIEW version in which it is installed. As to trying to use OpenG Package Manager (and/or OpenG Package Builder) for Linux, I'm afraid that is going to be a major project in its own. Those two were never very actively used and tested on anything but Windows, except maybe some MacOS X enthusiast, once LabVIEW run on those machines. It always took some time for LabVIEW to support new non-Windows versions after they got available.

Actually I have to admit that I have no idea how this works in 2020 and/or 2021. I haven't been working with these versions so far together with RIO projects. I know they changed the package format for installation of software packages from the CDF to the nipkg format either with 2020 or 2021 but I have no idea how one would go about building such a package. I checked the NI Package Builder but so far it only seems to support building packages for Windows installations. Not sure about how the package part for the RT distribution would work.

I would not know if this type of low level control is even possible with the MPSSE controller in the chip. That is something you will have to take up with FTDI customer support as that is really very deep down in the belly of MPSSE.

Yes the dialog resource is in fact a VI, but the diagram is never used no matter what you do. The LabVIEW kernel loads the dialog resource as a template but assigns its own (in C implemented) DlgProc to it which does the whole event handling. The diagram is totally decoupled from the VI as soon as the LabVIEW Dialog Manager loads the resource.

There is no diagram at all. The LabVIEW executable implements the functionality of those dialogs entirely in C(++) code and only uses the dialog resource to create the window. It's very important to NOT change the controls and their labels as that is how the code refers to them. You can adjust the size and color of elements and most likely even change the style of controls as long as you make sure that the control datatype and label ID remain the same but if you mess up, LabVIEW will crash hard.

Sounds like a no brainer to me. Granted a VI that has gotten so complex that the LabVIEW compiler has a problem with it is probably a huge maintenance nightmare in itself. I still have to encounter this problem with any VI I ever created but am pretty sure that chances for that are pretty much zero. 😀 However back to your problem. Your SSP expires in half a year. It means that it still covers LabVIEW 2021 SP1 once it is released, so your existing perpetual license basically grants you the right to use LabVIEW 2021 SP1 or earlier. Once you extend your SSP it automatically converts to a subscription. The only advantage of extending the SSP is that you can lock in the subscription price for up to three years for the current SSP cost which is about half of what the yearly subscription price is. Instead you can keep your perpetual license and decide at a later point in time to buy a yearly subscription when you decide you want to go to a newer version that supports the newest and greatest "Quantum Computer Future Prediction Technology" TM Until then and even after you signed up for that yet to be future subscription, you can still keep using your existing perpetual license for LabVIEW 2018 (or 2021 if you ever decide to make the jump). You loose direct support, access to training material and such perks until you buy a subscription, but that is likely something you can live with for some time. Also in the long run you might get into trouble as NI drivers only support the current and previous 3 versions. So NI-DAQmx (or any other driver for that matter) 23.x will stop providing support for your current LabVIEW 2018 version and if you then want to use an NI board introduced in 2023 and hence only supported in NI-DAQmx 23.x, you have a problem.

Most likely no real malice involved here. But simply the fact that he has only the latest version installed and there is always the (not so likely) chance that the new version fixes the problem magically either through a bug fix introduced since or a fresh new full installation of all software components.

I think you can NOT purchase perpetual licenses anymore since January 1, 2022. So unless your current SSP does run until after the release of 2021 SP1, you would have to go with 2020SP1 (2021 non SP is not an option IMHO). As to your previous post about trying to get LabVIEW into the TIOBE index: It has been for almost 20 years, with the highest ranking somewhere in the 20ies I believe, and currently lingering around 40, on the brink to falling out of the top 50. But that has been the case for over 10 years already.

What have you tried so far? It should not be a big problem to use this with any of the Modbus libraries out there. I usually use the NI Modbus library but I think the Plasmionique library should work too. You need to make sure to use the correct Modbus Unit ID, which Omega calls Modbus Address (Function 34) in its menu structure on the display. They need to match if you want to read any value (Read Holding Register). For writes you also can use a Unit ID of 0 which will address any connected Omega Unit but it will not return any indication if the write was successful. The default address if the Omega Units should be 1 when delivered. Then you need to figure out what register address to read and/or write. The according addresses are documented in chapter 19 of this manual.

Indeed and LabVIEW DSC is on the way out. There have been no updates to it in years and support questions are blissfully ignored for a long time. HIQ was acquired in the first half of the 90ies and had the potential to compete with Mathematica and Matlab back then, but NI mainly used it to cannibalize some of its mathematical routines and add some of it to LabVIEW and then lost interest on it. Lookout was acquired around the some time. It was a very unique DSC software package with a rather interesting object oriented architecture. NI used the low level components to create its Logos network protocol infrastructure on which things like Datasocket and later Shared Variables were implemented. They also used various components of Lookout to convert the originally purely LabVIEW based BridgeVIEW system into LabVIEW DSC. After that Lookout spend its existence as a rather badly cared for step child in the NI product portfolio and eventually nobody was left over to support it anymore. LabWindows/CVI changed from yearly updates with new features added regularly to two year updates with not much more than cosmetic bugfixes for several years already. It's worse in terms of new features added than LabVIEW ever was for many years. But with LabVIEW they used the excuse that all effort was directed towards LabVIEW NXG and LabVIEW was going to be replaced by it one day. NI MultiSim used to be two products from the same company (Electronics Workbench) who were named Electronics Workbench and ULTIboard before they got acquired by NI and were at that time one of the leading EDA products in the educational market worldwide. Nowadays they are completely insignificant in the EDA market. If you have the money you will subscribe to Altium Designer, if you try to be a bit cheaper you may use Autodesk Fusion 360 or if you are an old time Eagle user then maybe Autodesk Eagle PCB and if you insist on Open Source then KiCAD will be very likely your choice (which has made large strides since CERN has decided to back it). Electronics Workbench (or NI MultiSIM) is not on that list for sure. I have used it a few times since it is part of our Alliance Member software lease but it is not up to the task of creating modern PCB designs and hence not worth the effort to learn its many specific mechanisms and bugs.

Open sourcing sounds very unlikely. And what I feel here is not that they will abandon it in the next few years just like that. There is also the question about their original assurance for a software escrow of LabVIEW, that NI used when trying to convince companies to use LabVIEW in the 90ies. Never heard about that since, so it may have been not much more than a smoke screen or some empty promise, or it may still be an actual fact. But if you look at what is happening with LabWindows CVI now, it may be an indication about what they are heading for with LabVIEW in the coming 10 years. And NI's track record with acquired software and how they treated it is not very encouraging either. Ever heard of HIQ, Lookout, BridgeVIEW, Electronics Workbench and a few others?

No! An rtexe is not a real executable. It is more like a ZIP archive that can not be started in itself but that needs to be started by invoking the runtime engine and passing it the rtexe as parameter. And the exact mechanism is fairly obscure and not well researched and totally not documented. Unless you are a Linux kernel hacker who knows how to investigate the run level initialization and how the LabVIEW rtexe mechanisme is added in there.

But it existed since around LabVIEW 6.1. You had to add a funkyErrorWire=True or something similar into LabVIEW.ini

Actually the color distinction of a wire is not specifically between a fixed size cluster and variable sized cluster and if it can be typecasted or not. Aside from adding a fixed size cluster into another cluster there is also the case where you add a boolean into a cluster. Both result in a pink wire but are still fixed size and can still be typecasted. I think the brown wire only indicates that the cluster only contains numeric scalars and can coerce into a similar cluster with the same number of numeric scalars even if their numeric type is not exactly the same. Not really a very useful distinction I believe but 35 years back LabVIEW (and most other programming languages) wasn't as strictly formalized in many aspects.

Unfortunately I do think there is a strategy behind this. In the past NI was a company centered around hardware sales in the form of computer plugin cards. The fact that they were a lot better in providing good and well designed supporting software for that hardware was for years a distinguishing factor that made them grow while the competition had a hard catch up game to do and eventually all more or less faltered. The software in itself never really was the money maker, much of it even was given away free with the hardware and was considered a supporting expenditure that was financed with part of the profit for the hardware. When they had pretty much the whole market of what they possibly could get, they run into the problem that there was very little grow in this market anymore for them. So they set out to find new markets and moved towards turn key semiconductor testers that they could sell a dozen a time to the big semiconductor manufacturers for big money. Suddenly those pesky DAQ cards and DAQ boxes were just a margin anymore and they were at best a supporting technology, but the accompanying software was getting more an more a costly burden rather than a supporting technology. Nowadays there isn't one NI marketing but each division has pretty much its own marketing department and is also its independent profit center. And then an independent software/LabVIEW division suddenly shows mainly as a post in the cost category that doesn't bring in as much as it costs. So they try to increase the income but I think they missed that train already 15 years ago when they were refusing to consider other venues for LabVIEW. Nowadays the LabVIEW community is a marginalized small group of enthusiast who are looked at by the rest of the industry as a bunch of crazies who can't let go of their pet IDE and the rest of the world has moved on to Python and .Net and will move on to another hype in a few years. And the higher NI management is likely aware of that. While I do believe that the LabVIEW developers and the managers who directly work there really would like to make LabVIEW a good and flourishing product, I feel the higher management has already decided that this is going to be a dead end and have very little intentions to do anything else than let it bleed to death, so they can get rid of that liability.

Would have to see the code in question. But generally I would think that you can call Functions like LocalAlloc() with the return value configured as pointer sized integer and using a 64-bit integer to transport it on the diagram/front panel. Then when passing it to an API, pass it again as pointer sized variable and when putting it into a cluster, assign it to either the 32-bit integer or the 64-bit integer respectively. There should be no problem with this since if you are on a 32-bit platform only the lower significant 32-bit should have been assigned by the Call Library Node, although there might be a sign extension happening if you happen to configure it as signed integer but that should not be a problem either.

I think I misunderstood or you explained it somewhat poorly. There should be no reason to have to do any byte (word, int) swapping in this case unless you use the Typecast function to Typecast a properly sized byte array to or from the cluster. And that would be actually not the right thing to do. Typecast always will (De)Standardize a bytestream to or from Big Endian format. If you really want to pass a byte array to the function, you can instead use the Flatten To String or Unflatten from String with the type set as Native Format. Then there won't be any swapping done. Alternatively I usually create two separate clusters, one with 32 bit ints and one with 64 bit ints for the pointers. Then using Conditional Compile I setup two separate calls to 32-bit and 64-bit variants of the Call Library Node and pass the according cluster to it. And yes it is a pain in the ass to do that for more than one or two callsites, so when there are many of them and/or other nasties that don't fit well with a LabVIEW direct interface, I tend to create an intermediate shared library that properly translates between LabVIEW friendly clusters, handles and what else and the C specific API datatypes directly in C.

Actually shareholders can be stakeholders too. Stakeholder is anyone who has a significant (usually directly or indirectly monetary or otherwise motivated) interest in something. 🙂 The disruptive sounds actually rather bad in my ears but it seems to have been getting a different meaning in marketing nowadays. And Synergy comes everytime up when NI acquires another company. It's one of the most used reasons why an acquisition is a good thing. You can't say of course that you simply buy up possible competition. 🙂

Use "LabVIEW" (without quotes and case is important) as Library Name in the Call Library Node. LabVIEW recognizes this as referring to the current kernel that runs. Once you built an executable their is no LabVIEW.exe anymore but instead a lvrtdll.dll that exports these functions and in fact that is only a forward to the real mgcore_xx.dll since many versions.

Would you care to elaborate which pointers you mean? I can't think right now of where what you say could apply.