Rolf Kalbermatter

For this type of functionality it is absolutely not Booh. 😀 It is OOP in the sense that it uses LabVIEW classes as an easy means of instantiating different driver implementations at runtime. One interface (or a thin interface class in pre LabVIEW 2020) and then a child implementation to call the DLL, one to call VISA USB Raw and possibly others. On top of that one driver as a class to do MPSSE I2C and another for MPSSE SPI. That way it is very easy to plugin a different low level driver depending what interface you want to use. D2XX DLL interface on Windows, D2XX so interface or D2XX VISA USB Raw on Linux and LabVIEW RT. With a little extra effort in the Base Class implementation for a proper factory pattern implementation, the choice which actual driver to load can be easily done at runtime. I did the same with other interfaces such as Beckhoff ADS, one driver using LabVIEW native TCP, another interfacing the Beckhoff ADS DLL, one for Beckhoff ADS .Net and one for Beckhoff ADS ActiveX, although the ActiveX one has a bug in the type library that tells LabVIEW to use a single reference byte as data buffer for the read function and there is no way to overwrite the type lib information except patching the ActiveX DLL itself. The Typelib should declare that as an array datatype but instead simply declares it as a byte passed by reference. The same thing for a C compiler but two very different things for a high level type description. The base class implements the runtime instantiation of the desired driver and the common higher level functionality to enumerate resources and read and write data IO elements using the low level driver implementation. For platforms that don't support a specific "plugin" you simply don't install that class.

USB Raw will of course require your LabVIEW code to use the right USB control endpoints, pipes and binary bit patterns and if the new chip is not 100% upwards compatible with the old, that means a different driver (or one with conditional code based on the chip as detected at communication initialization). Without a detailed specification of the low level USB protocol for the new chip that is not gonna work. Using the FTDI provided D2XX driver should fix that as that driver somehow makes sure to talk to each chip as needed, as long as FTDI supports that chip with this driver. Some of the FTDI chips need a different driver such as D3XX. It's definitely easier than trying to do USB Raw communication but requires a bit of C programming knowledge to be able to figure out the proper Call Library Node configuration for each function. The existing LabVIEW wrapper as provided from FTDI is outdated and only supports 32-bit, possibly even with a bug or two even in 32-bit, but it is a starting point.With a little love it can definitely be made to work for modern LabVIEW in 32-bit and 64-bit and for Windows and Linux. I may revisit my earlier attempts of writing a fully LabVIEW OOP based solution for this with pluggable low level driver using USB Raw or FTDI D2XX and a pluggable high level driver for the I2C and SPI MPSSEE modes of the chips that have such an engine build in, but I haven't currently a use case for this and that tends to push this project always towards the end of the "projects that are nice to develop" queue.

It may be possible, but a few 100 subpanels somehow makes my alarm nerve tingle quite strongly! Sub Panels are not the light weight thing like Windows windows, where they made each control in a classic Win32 application its own sub-window. And they moved away from that idea with more modern UI frameworks too, and likely for some reason. You really may be stressing LabVIEW's window management capabilities beyond reasonable borders with so many subpanels present at the same time.

Not just for Linux. In Windows it is the same. But I'm not sure, I never used the D2XX driver on Linux until now. My understanding is that as long as you do not open a VCP interface for a device, the hardware is not really in use and should be accessible by the D2XX driver. In the worst case you may have to configure udev or whatever is used on your system to manage automatic mounting of USB devices, to not install a particular device as tty device, for instance based on the serial number or similar. By default most Linux systems are nowadays configured to automatically install any device they have a standard driver for as the according device. In the past this was often the opposite where you had to mount the device manually or add an according rule to udev for automatic mounting at boot time.

That's not how those drivers work. The device drivers for the FTDI chips (the RS-232422/485 at least) installs in Linux as a serial port driver. That means that they get installed as serial ports under /dev, usually as /dev/ttyUSB* with increasing number and can be accessed through NI-VISA just as any other serial port. There is no exported API in these drivers that you can interface to with a Call Library Node. If you want to access the MPSSE engine in those chips (to do bit bang, I2C or SPI for instance) instead of the Virtual Comm Port interface the standard Linux driver provides, you'll have to hunt down the D2XX driver for your Linux distribution and install that instead. https://www.ftdichip.com/old2020/Support/Documents/AppNotes/AN_220_FTDI_Drivers_Installation_Guide_for_Linux.pdf This document is from 2017. Your Linux distribution may have changed things considerably in the meantime, so your mileage may vary, but the general distinction between standard VCP and FTDI proprietary interfaces to the chip through the D2XX driver remains. There exists LabVIEW libraries to interface to the D2XX shared library and also to access the two FTDI provided wrapper libraries to do MPSSE SPI and MPSSE I2C but they are heavily Windows minded, meaning that they try to link to the .DLL version instead of the .so and there might be other API specific details that differ between Windows and Linux. Also last time I checked the two MPSSE VI interfaces here on LAVA were not cleanly prepared to handle 64-bit shared libraries as they were developed when 64-bit LabVIEW was still in its early days and nobody bothered to install and use that.

I would actually suggest to implement it properly by extending the File Dialog Node. A double NULL terminated string array that is simply passed to a Windows API function is hardly a safe and proper LabVIEW datatype! 😁 And of course you saw it already coming, add support for that on Linux too 😁

Not really. And this is a very clear case of using an undocumented and unintended side effect of the implementation. It only worked on Windows and not any other platform and only because the person who implemented the file dialog functionality took a shortcut by passing the LabVIEW string directly to the Windows API without trying to sanitize it. Microsoft discourages the use of the GetOpenFileName and GetSaveName APIs which originate from Windows 3.0 times starting with Windows Vista, and recommends to use the Common Item Dialog instead. My guess is that someone did recently listen to that recommendation and changed the file dialog implementation accordingly. Making sure it works the same way as documented for the old function is already hard enough, trying to also implement undocumented functionality and potential security bugs which this API had, is a bit to much asked.

Welcome back in the community! 🤗

Hi Paul I'm aware of this problem. It has to do with different default fonts in modern Windows machines, which changes the entire text format. The main reason I haven't yet updated the installer was that I was on vacation and there is also a problem to install the package under Linux, which has to do with write permissions to certain file directories. Once I figured that out I will release a new package 5.0.1.

One small correction. The Open VI Reference will block on UI Rootloop even in the first (top) one. The Run Asynchronous method will however not incur a rootloop round trip.

Elemental IO is not a public documented feature. The according project provider knows how to do it but it was never intended to have that interface opened as a user accessible feature. And the main reason is not that NI is evil and wants to deprive you of the fun to thinker with this but because they want to prevent customers to create easily crashing projects that require an immense support demand that NI is not able to fulfill.

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.