Rolf Kalbermatter

There is another "little" culprit, and its the most likely reason for this discrepancy. LabVIEW only uses 8-bit ASCII text and accordingly only posts a so called ANSI (that's what Windows calls it when you use an 8-bit codepage encoding) to the clipboard. Notepad and Notepad++ are definitely Unicode applications. While they may enumerate clipboard data formats and only request ANSI if there is no Unicode string format in the clipboard, they almost certainly will use the MultiByteToWideChar() Windows API to translate the text, and if they do request Unicode anyhow, Windows will be helpfully translating it for them using that function. But this function will terminate converting a string on the first occurrence of a NULL character. Most code doesn't bother to check if the translated code has consumed all the input bytes. It's also not trivial to do, as the function returns how many codepoints it placed into the output buffer, but that does not have to match the number of input bytes, since some ANSI encodings can use more than one byte for some characters, and the used UTF-16 standard in Windows can theoretically generate more than one codepoint per character for certain very rarely used characters. For instance the MUSICAL SYMBOL G CLEF is outside of the 16-bit code range that UTF-16 can represent in a single codepoint. So if you want to preserve possible input strings beyond an embedded NULL character, things get fairly hairy when using the Windows conversion function as you would have to call it repeatedly on each individual text section that is separated by a NULL character. But trying to build your own conversion routine is an even worse idea. Nobody in his sane mind wants to do encoding translations themselves. 😀

My projects usually have one or two folders called Tests and Junk. Tests are VIs that I create to test certain functionality. For instance in a recent project I created a number of test VIs for various subVIs that I used in an FPGA program. These are typically not real tests in the sense of Unit Tests but more a test bed to easily run the VIs interactively and test functionality and improvements as well as behaviour of the various functions. Junk I put VIs in that I sometimes create for a quick and dirty test of some function, occasionally also VIs that I might create for helping in a forum post while waiting for the FPGA compiler or some tests to finish. Outside of these two folders there is usually almost never any unused VI. I make a point to regularly check for VIs that are not anymore used and to simply delete them (or sometimes move them into the Junk if I think there might be some future possibility that it is needed again), but most are left overs from earlier attempts of reworked VIs that are now used in the program, so they can safely go away. And of course everything gets regularly checked into Version Control, with some more or less useful commit message. 😀

Hmmm, clipboard copy! That has a very good chance of trying to be smart and to do text reformatting. I would definitely drag the entire control with all the data from one VI to the other, which should avoid Windows trying to be helpful. As a control, LabVIEW puts it in an application private format in the clipboard together with an image of the control. LabVIEW itself can pull the private format out of the clipboard, other applications will not understand that format and pull the image from the clipboard. If you only select the text, LabVIEW will store it as normal ASCII text in the clipboard and Windows may try to do all kinds of things including trying to translate it to proper Windows text, which could replace all \r "characters" with \r\n and there is even the chance that the text goes through ASCII to UTF-16 and back to ASCII on the way through the clipboard and that is not always a fully 100% back and forth translation, even though they may look optically the same. Text encoding translations is a total pitta to fully understand.

I can't guarantee that there is not some problem somewhere in a function, but I didn't find anything in my testing. How did you copy the deflated string? As binary data or as string? If as string, are you sure your transfer mechanism didn't do some text translation such as automatic \n to \r\n translation somehow? Did you use the LabVIEW Text File Read and Write functions to write your strings? A deflated stream is not a text string but a byte stream, no matter if LabVIEW lets you display it as a string. It is not a problem for LabVIEW itself as it does not use special characters such as a terminating NULL character. But if you are not careful and use the File Text Write and Read functions in line conversion mode, your binary stream gets of course modified and that destroys the integrity of the binary information as the inflate algorithme expects it (and checks it with CRCs too).

Thanks for the feedback. I'll have to check how it would be possible to create a package that can be added as stream in NI-MAX.

It actually made me poke at both accounts here on LavaG and the only posts done by both of them were clearly promoting this product and nothing else. Despite being told in one of the threads that it is only very loosely related to the thread at hand as the original post was about an Open Source alternative, which this clearly isn't. And in two threads the last reactions from both were within 24 hours. Agreed, it is as a follow up post from Omer to the post by Elena, but still all very marketing style. As I said I consider it bordering spammy, not actually spam, otherwise I would have reported it.

Not so interesting! Both Elena and Omer have so far only posted to boost about the TVI framework. Omer supposedly as an employee of the company that sells TVI and with Elena I'm not so sure, but it could be also from their marketing department. 😀 While technically related it is bordering spam based on the repeated marketing style postings.

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