How does cRIO use 3rd party dynamic link libraries to control instruments?

[汉卿]

I need to use the cRIO to control the signal source of Holzworth, according to the instrument instructions, I can already use the computer to control. According to the cRIO control instructions, the dynamic link library HolzworthHS1001.dll is placed in the cRIO\file\usr\local\lib directory, but when running the program, it appears: Failed to load the shared library HolzworthHS1001.dll. Make sure the library exists on the RT target. Install NI software using MAX, or deliver custom libraries to RT targets via FTP.

[AndreiR]

Hi!
I also have two Holzworth synthesizers (HS1001A) I bought on ebay and am trying to find documentation, software and the DLL file for controlling them.

Do you perhaps have any of these you could share with me?
Thanks,
Andrei.

[汉卿]

Unfortunately, they are two different control languages that are not compatible and cannot use the original code control.

[rolfk]

cRIO can come in several flavors. The first versions were based on an Intel x86 compatible CPU running Pharlap ETS. Pharlap ETS is in principle Win32 compatible and can theoretically load Windows DLLs. The problem is that Pharlap ETS only supports roughly the Win32 API as was present with Windows 2000. Most modern DLLs have long started using APIs that were introduced by Windows XP, 7, 8, or 10. Such a DLL can not be loaded on Pharlap ETS. In addition a DLL generally makes use of a so called C Runtime library and that is dependent on the C Compiler version used to compile the DLL. Only DLLs compiled with Visual Studio 6 are using the generic Visual C Runtime API that every Windows version (and Pharlap ETS) has supported since about Windows 95. All other Visual Studio Compilers require a specific runtime to be installed. And the standard C Runtime Library from Microsoft can not be installed on a Pharlap ETS system since it always expects newer (sometimes not officially documented) APIs for process initialization that were not part of the Windows kernel as Pharlap ETS tried to emulate. NI ported a few Microsoft C runtime libraries to Pharlap ETS and made them available for install, but the latest was for Visual Studio 2010. Any DLL compiled with a later Visual Studio version is by definition impossible to load on a Pharlap ETS cRIO.

Then NI released a few cRIO that were based on PowerPC hardware and that used VxWorks as OS. For VxWorks, Windows DLLs are just a bunch of bits and bytes and make no sense whatsoever to the OS.

Around 2013 NI started releasing cRIOs that use either an Intel x64 compatible or ARM CPU and use NI Linux RT as OS. For Linux a Windows DLL is an equally useless bunch of bits and bytes (well yes you can install Wine to let Wine deal with the DLL, but getting Wine installed on a cRIO is an exercise in system engineering that I would not recommend anyone to attempt. And even if you get it working it makes that DLL only available to a Windows (or specific Wine) process running under Wine, not to normal Linux processes. And even that may fail as Wine does only provide a Windows API compatible interface, not full support for accessing every hardware resource on the system through Wine.

Basically:

- cRIO running Pharlap ETS: A Windows DLL "may" be usable but it depends heavily with which Visual Studio version it was compiled, MUST be 32-bit and MUST not use any Windows API introduced after Windows 2000 (and also no features that Pharlap ETS does not support such as user account and access management, OLE/ActiveX, .Net, Unicode, etc.)

- cRIO running VxWorks: external code needs to be specifically compiled as an .out shared object library using the VxWorks compile toolchain (mostly a GCC based toolchain with VxWorks specific additions)

- cRIO running NI Linux RT: external code needs to be specifically compiled as an ELF .so shared object library using a GCC based toolchain. You need to make sure to either create x64 or ARM softeabi object code depending on the hardware target you want to use (906x, 96x7 and 9651 uses ARM, 903x, 904x, 905x, 96x8 and 96x9 uses x64)