Rolf Kalbermatter

This is undocumented territory for sure and as such there is a high chance that: - parts of what you want to do might be obscure and difficult to impossible to find out without the according non-public documentation - it might be present but not implemented, either returning an error or simply doing nothing - it might be simply not possible as the LabVIEW developers haven't found a need for this particular operation yet, and why would they spend time on implementing something that is neither a public function nor required for internal use?

So what is your problem or question? I never said that you can't access the 987x modules from FPGA. But you never specified in your OP that you meant those. As far as scripting these things, it's undocumented territory. And complicated enough that reverse engineering would be a pretty tedious job. Supposedly the C module development Toolkit has some documentation about how so called Elemental IO can be created, but I highly doubt that it documents how that is done through scripting, but it simply provides some tools that do all these things behind the surface. That Toolkit was however not free (~1600 for non-commercial version, 6k for commercial version). The non-commercial version does let you develop your own C modules, but you are not allowed to sell them to others. However it is not anymore findable in the NI store as an order-able product.

Well I'm for sure sure about the built in serial ports on cRIOs and sbRIOs. The987x serial C modules are a different story. And serial ports through USB ports definitely never ever could be just accessed from FPGA mode. You need at least a USB-CDC driver and while that might be possible in FPGA, it is not something that the Xilinx chips that are used on the RIO hardwares would even support, even if you might find some IP design somewhere implementing that. The communication channels such as Ethernet, Uart, USB and similar are NOT directly routable to the FPGA fabric but only accessible through their register interface, which requires a software driver to control them (and an OS on which that driver can be loaded).

A particular device can ONLY be used by one application at any time. Either you can use it on Dasylab or in NI-MAX but not in both at the same time. That is standard procedure. A hardware device is a global resource and two applications trying to do anything on them at the same time will at best produces spaghetti but potentially also crashes.

I think you are confusing an IO signal with a logical interface. The serial port is typically a logical device that contains a TxD and RxD pin and possibly others. On the FPGA you deal exclusively with IO signals. But there is no way to access the serial port as an IO signal. Either you would have to access the individual IO pins that make up the serial port individually and implement the serial port bit protocol yourself in FPGA or you need to access the serial port through the RT OS on the controller as serial port and let the OS driver handle the actual IO control (usually it doesn't really control the IO pins directly but uses a device driver to communicate with the serial port registers).

Just a heads up. I'm working on this including getting more Linux Virtual Machines setup, but it is a slow and tedious process. There seems always something that won't work. LabVIEW installation on non-rpm systems is tedious and often almost impossible, depending on the Linux variant and version. On Fedora 34 the rpm files use a feature that a security fix to the rpm program had disabled and now it complains about invalid rpm files. Updating rpm requires kernel development files installed that can't be installed anymore. Fedora 36 allows installing of the LabVIEW 2014 SP1 that I could organize but LabVIEW segfaults on startup, likely because the kernel, libc or stdlibc is to new for it. Older Fedora images are difficult to get at and even more difficult to install. Open source is nice but the version conflict hell seems to be still as it used to be 15 years ago, where anything but installing from source was a Russian roulette game. So while I'm slowly getting towards something that eventually, hopefully will work, I'm for now going for one week of ski vacation and work on this will have to wait a bit.

I didn't mean to indicate that the SD card is the reason for the lockup, although it is not entirely impossible. But SD cards are not a good solution for anything but occasional data transfer. It is not a question if they will fail, but when!

Yes that is the main problem to support something like this. And no I don't have a 2014 installation either for Linux. I could of course download 2017 SP1, which is the oldest that can be downloaded from the NI site, but I would actually prefer to have a version that was also supporting 32-bit (which 2016 was the latest).

I would be very hesitant to use SD cards for anything but occasional backups (and not to keep the backups on there, but just to transfer them to a different more safe location). SD card reliability is a big issue and "the" major reason for Rasperry Pi applications in 24/7 unattended operation mode to eventually just die (well not the Raspberry Pi is of course dying but it won't boot up from the SD card anymore eventually). The S of SD is definitely a misnaming.

Well, do you have a LabVIEW 2009 installer for Linux (and Mac) for me to use for testing? I would be even willing to settle for 2014 but it should be an older version than 2020. I used to have 2014 on an old iMac both for 32-bit and 64-bit but that hard disk has irrecoverably died and there was no backup of it.

Sure: https://github.com/RolfKal/openg-lvzip

Thanks guys for actually checking out the OpenG ZIP library. Yes there is no Realtime support yet in 5.0. I was already struggling with normal Linux support quite enough, so did not want to add yet another challenge. There will almost certainly be no support for Pharlap and VxWorks in 5.0, unless someone is really begging very nicely for it. 😁 As to the Linux installation problems, I'm sorry about that. I did move to LabVIEW 8.6 for testing and building, since that is the Linux installation that I have available, but apparently forgot that I had patched the LabVIEW 7.0 OpenG Builder to not bork the shared library names when building a distribution for a package. So I have to investigate that. Also there is still an issue with support for Unicode ZIP archives, but since that is not happening to often it should not be a serious issue for the moment. But I'm investigating the proper fixes for that. I just hope that the NI Linux RT installations offer a similar support for dealing with Unicode as do normal Linux distributions, otherwise things will get nasty.

That's definitely a potential problem. If the RT image does not match the LabVIEW version, you usually can't even connect the project to it. What CompactRIO version have you installed?

The old version was basically using the same config File refnum trick as the current one, only was the refnum a mask for something else than a queue, which did not exist back then. It was worse in the respect that it did read the ini file each time when writing anything to the configuration, so performance wise it was pretty sucky, and with a great possibility of concurrent access race conditions. As such the current implementation is definitely a huge improvement, but yes it caches all the configuration information in a queue which uses some extra memory.

It would have been a much more painful, and for most affected users even less trivial point to fix, if they replaced the original INI file fake refnum with a proper private user refnum. Any code that used a copy of that refnum in their own code somewhere would have simply broken. It was a judgment call: risk breaking a lot of existing code that improperly made a copy of that refnum or live with the limitations of the fake refnum. Not breaking existing code was always one of the top priorities in the LabVIEW development team, even if that existing code was born out of bad practice. And it's not ANY file API. Only file functions that legitimately can operate on datalog file refnums. And they properly generate an error 1, since the refnum in question is indeed NOT a valid file refnum. There are other situations where you can logically connect data types to nodes but that node can't operate on that specific flavor of data type. LabVIEW is strongly typed but sometimes there is simply no easy way to make sure at compile time. As long as it produces proper error codes at runtime and doesn't crash, I consider it a valid trade off.

About 30 years indeed. And bug is a strong word, it was a smart find back then to create your own refnums. While there would have been a better alternative around LabVIEW 7.1 (User refnums) there were several reasons not to use them. It was a new and not extremely well tested facility, it was really meant to incorporate binary shared library drivers with very little LabVIEW VIs and it would have broken the many Config File wrappers and application users that were creating a private copy of that “refnum” instead of using the Config File typedef.

Neil, that queue reference is type casted to a LabVIEW datalog refnum. This is done to create a custom refnum "light". It works to prevent users from connecting this refnum to anything that is not an INI refnum ....... except file IO functions that also can deal with datalog refnums. The file IO function then tries to extract the underlaying file handle and that of course fails since the queue refnum does not have a file handle. Therefore you get the error 1. If the OP really wants to hack a Flush into the library it would have to be added to the Config Close. But since this is the only time the whole file is even accessed with write access and there seems to be a little window of opportunity during the Write File function and the Close File function in there in which, when the power is yanked just in time, in the right way, the transfer to the disk is corrupted. The File Close should do a Flush too, although it may be somewhat delayed. How a Flush right before the Close would really help is more than doubtful. I think Shaun's recommendation to check the S.M.A.R.T data for the drive in question may have some real merits here!

That's technically not exactly correct since there exists something like lvrtff. However trying to use that in order to be able to build LabVIEW applications from within a LabVIEW application is definitely not worth the hassles.

You can NOT install LabVIEW RT on non-NI hardware without a license from NI! And they have so far hesitated or stalled to say if they ever plan to sell such a license. What you can do is install NI Linux RT on whatever hardware you care since the Linux kernel is GPL software. And that is also what the NI Github repository is about. To provide a means to fulfill the GPL requirement to have the source code to the GPL covered software accessible to any user. What the NI Linux RT Github repository does NOT contain are the LabVIEW RT runtime kernel , NI-VISA, NI-DAQmx, NI-this and NI-that since they are closed source software and the Linux kernel comes with a special GPL clause that allows people to build and distribute closed source software that runs on it. Quite some kernel folks would love to get rid of that clause and force everybody to open source everything everywhere, but that didn't even fully work for kernel drivers, where they did a lot of effort to prevent closed source drivers from being able to do high performance operations. The big point here is that NI Linux RT is NOT LabVIEW RT. The whole LabVIEW RT runtime and NI driver stack are closed source and you can not install it on random hardware without an according agreement from NI. If you install NI Linux RT on your Jetson hardware, what you basically get is a somewhat expensive Raspberry Pi or Beaglebone Black board with additional soft RT capabilities but no LabVIEW target support at all! And no, the LabVIEW Hobbyist Toolkit can't be easily repurposed to run with such a hardware either. It's support is limited to ARM Cortex A hardware platforms and you may be able to get the according schroot image installed and running on the Jetson, but that is an entirely different thing than getting NI Linux RT installed on the Jetson. It is legally questionable but maybe you could get away with it, but it is technically quite a suboptimal solution as the schroot environment in which the LabVIEW RT kernel is running is a limited non-RT capable virtual machine running on the normal Linux host on your Jetson.

It happens in a lot of locations. When you go to the download page of NI software (their specific canonical download entry for each product where you can choose the version and bitness and such) you usually have a link that goes to another page that shows available readme's, and similar documents and there it often states this sentence. However it happens both for very old releases of software (I assume the person creating that entry felt to lazy or to frustrated to search the NI document management system for the according document) as well as very new releases (here the document may indeed not yet officially exist and has not been added to the document management system).

Doesn't seem to have an MPSSEngine. Which is not so surprising. The MPSSEngine is a Multi Protocol Synchronous Serial Engine. There is nothing truly multiprotocol about the FT4222H chip, it's simply an I2C/SPI interface chip without support for other GPIO, RS232, and similar interfaces. https://www.ftdichip.com/old2020/Products/ICs/FT4222H.html You can use it through the FTD2xx driver though. there is also a LibFT4222 DLL which sits atop the FTD2xx driver and implements the FT4222 specific stuff. You would have to create LabVIEW Call Library Node wrappers for this DLL if you want to use this driver.

Your suspicions are partly right! lvanlys.dll is for the most part the conversion layer from the LabVIEW AAL functions to the MKL. In old days lvanlys.dll was the NI implementation of the Advanced Analysis library. But when they changed to use the MKL they could (or did not want to) change the entire LabVIEW Call Library Nodes to adapt to the MKL entry points. Basically the MKL is NOT written with LabVIEW in mind but fully designed to be called by C(++) code. An intermediate translation layer written in C(++) that provides a LabVIEW friendly interface is the most easy thing to do in that case (no it's not easy at all but the alternatives are much worse in terms of effort and maintainability). Also there were some specific assumptions in the LabVIEW AAL that are slightly different how the MKL library expects things, so the lvanlys.dll also takes care of such differences. Alternative would have been to change some of the conditions for callers of the LabVIEW functions, which would have been a very serious backwards compatibility problem.

The Intel Math Kernel Library. NI occasionally updates the Intel MKL used but doesn't painstakingly follow the latest and greatest from Intel. And there might have been some licensing perils in recent years. NI got a license to distribute the MKL when it was still its own product and Intel was very keen to have as many people as possible adopt it. Nowadays it is part of the One API initiative and Intel is a lot more pushy about monetizing that, so they may have altered the license deal that NI had, and NI might or might not have accepted that.

In my experience there is indeed not. The standard is more or less whatever Koolaid your client has been buying into. 😀

Same as other mentioned. If your device comes with a proprietary serial protocol over RS-232, you can consider yourself lucky as at least the electrical layer of that interface is standardized. Alternatives are USB, which sometimes come with Virtual Serial Ports, making them on a similar level than good ol RS-232, but quite often require their own proprietary driver and only are compatible with the vendors software or an expensive SDK from them. Some vendors claim to have developed the super duper vendor independent communication standard, only to let you find out that they are really only compatible to themselves and sometimes not even across different series of instruments from the same manufacturer. They try to sell you their latest and greatest lab automation software that works perfectly with their devices and only sometimes in rather mediocre ways with other devices through complicated gateways and specially sold and expensive interface solutions. Generally it is a lot of marketing hype and sunshine, until you try to combine two or more systems from different vendors together.