LabVIEW RT calling external code

[Eric Griwicki]

Has anyone had any luck calling external code (DLL) in LabVIEW RT?

I have an application that requires the use of an external library written in C++ which makes use of the STL and some Win32 API calls (wsock32.dll). I am exploring the idea of creating a C wrapper DLL for the library which would enable it to be called by LabVIEW, but I'm not sure that the DLL would run under LabVIEW RT.

I know NI has a DLL checker on their website that verifies the DLL as capable of running in LabVIEW RT but they still don't guarantee that it will work. I haven't built a DLL that wraps the code yet to test it out. (still not sure if I want to go this route)

Does anyone have a list of the supported or unsupported libraries in the Ardence Phar Lap ETS (RTOS)? And has anyone been able to call a DLL from LabVIEW RT that makes a call to the WIN32 API? It may also be possible to strip out the Win32 stuff. Has anyone had any experience just calling pure code in a DLL from LabVIEW RT?

Thanks in advance for your help.

Eric

[Khalid]

has anyone been able to call a DLL from LabVIEW RT that makes a call to the WIN32 API?

Hi Eric,

You should be able to make Win32 API calls on Phar Lap RT. Here's a quote from their website:

"Because ETS was designed as a Win32 API compliant operating system, all the standard Windows conventions are maintained. This includes APIs, memory management, mutexes and semaphores that Windows developers are accustomed to using." [Link]

To confirm this, I just successfully ran -- targeted to my cFP -- VIs with the following Win32 calls:

GetLogicalDriveStringsA

GetSystemDirectoryA

GetSystemTime

GetTimeZoneInformation

GetEnvironmentVariableA

Coincidentally, all are from the kernel32.dll.

Regards,

-Khalid

[VDB]

Hi all,

is it also possible to directly access the serial port from a DLL without using VISA or Serial?

VDB

[crelf]

is it also possible to directly access the serial port from a DLL without using VISA or Serial?

I've had great sucess with Port Controller in the past, but never tried it on an RT system...

[VDB]

I've had great sucess with Port Controller in the past, but never tried it on an RT system...

hmm.. guess .NET and ActiveX will not work on RT... too bad...

VDB

[crelf]

hmm.. guess .NET and ActiveX will not work on RT... too bad...

I don't know - it's just a DLL...

[i2dx]

I don't know - it's just a DLL...

I don't know, too, but I guess there is a reason, why you have do download and install megabytes of data to get the .NET framework running on your PC ... and I disbelieve that you will get it running without the registry.

OK, you could maybe use some .NET controls, but what sould that be good for?

[crelf]

I don't know, too, but I guess there is a reason, why you have do download and install megabytes of data to get the .NET framework running on your PC ... and I disbelieve that you will get it running without the registry.

OK, you could maybe use some .NET controls, but what sould that be good for?

.NET and ActiveX are far more than just controls - my question is: if we can do Win32 DLL calls, can we do cusom ActiveX DLL calls under RT? I'm thinking that the answer is most probably going to be "no"...

[i2dx]

.NET and ActiveX are far more than just controls - my question is: if we can do Win32 DLL calls, can we do cusom ActiveX DLL calls under RT? I'm thinking that the answer is most probably going to be "no"...

whatever ... even if it is possible, what it is good for? I don't know how PharLab handles this calls and how it influences the determinism?

[Eric Griwicki]

Hello All,

I found this quote on the Ardence website concerning calling DLLs:

http://www.ardence.com/uploadedFiles/Embed...cts/ETS_FAQ.pdf

Q. Are all WIN32 API Function calls supported in ETS?

A. ETS supports a large subset of the WIN32 API, however function calls

that fall into following categories are typically not supported by ETS:

- OLE/ActiveX/COM/COM+/DCOM Functions

- MFC or ATL related calls

- GDI APIs

- .NET framework, managed C++

- Common Language Runtime (CLR)

It looks like they are calling the subset of the Win32 API by a different name, which is RtWinAPI (try googling it). There are some white papers that provide a little more details on what is and isn't supported.

Thanks for all the help

Eric

[Rolf Kalbermatter]

.NET and ActiveX are far more than just controls - my question is: if we can do Win32 DLL calls, can we do cusom ActiveX DLL calls under RT? I'm thinking that the answer is most probably going to be "no"...

No, it won't be possible. ActiveX is entirely based on COM/DCOM and that is one huge subsystem that has not yet been implemented by anyone outside of Micrososft. Wine as a project is trying to do that but they are still quite a stretch from a near full implementation. The only implementation of COM/DCOM I know of that has existed at least in the past outside of MS, was a DCOM implementation for Unix systems from Software AG. They had licensed the relevant code from MS and ported it to Unix and sold it for quite big bucks as a solution for big integrators doing banking applications and such. Not sure this is still maintained or sold.

.Net is yet another rather huge subsystem that is probably build in parts on technology from ActiveX too. Trying to integrate both COM/DCOM and/or .Net in a RT system is IMO a rather useless exercise. Many things would interfere with the RT nature of the underlying OS and render it more or less to a "normal" OS. Also the foot print of the OS itself would get bloated extremely and would increase the cost for additional system resources.

I think that if you do need COM/DCOM and/or .Net for something, an RT system simply is not the right choice for you.

Rolf Kalbermatter

[crelf]

I found this quote on the Ardence website concerning calling DLLs:

http://www.ardence.com/uploadedFiles/Embed...cts/ETS_FAQ.pdf

Very very interesting - thanks for doing the research!

[wallyabcd]

Hi Eric;

DLL do work under labview RT 7.0, 7.1, 8.0...

I have compiled some fitting routines with Labwindows CVI and have them running now for two

years under the various versions above without a problem.

However, what I had trouble with was the fact that my C & C++ routines had some very complex function type definitions,

therefore I had to write a wrapper to call them.

I built some function panels, and exported functions of interest and abview directly

generated the DLL . I then used the function panels to automatically generate a labview import library

by treating my DLL as a driver.

When building the cvi install, use the embedded laview runime libray(very small dll)

This will save space otherwise thebig one will work also.

With some tweaking you can get an activeX packaged as a dll to run also...

For your particular situation if wsock32.dll is standalone and doesn't make a calls to

to other system files, then it may work( it probably is an activeX and will be trouble)

Best option is to compiled your code and build a distribution, ask the compiler to include

all the dependent libraries; the copy them to labview for trials.

Walters

SpinX Technologies

Has anyone had any luck calling external code (DLL) in LabVIEW RT?

I have an application that requires the use of an external library written in C++ which makes use of the STL and some Win32 API calls (wsock32.dll). I am exploring the idea of creating a C wrapper DLL for the library which would enable it to be called by LabVIEW, but I'm not sure that the DLL would run under LabVIEW RT.

I know NI has a DLL checker on their website that verifies the DLL as capable of running in LabVIEW RT but they still don't guarantee that it will work. I haven't built a DLL that wraps the code yet to test it out. (still not sure if I want to go this route)

Does anyone have a list of the supported or unsupported libraries in the Ardence Phar Lap ETS (RTOS)? And has anyone been able to call a DLL from LabVIEW RT that makes a call to the WIN32 API? It may also be possible to strip out the Win32 stuff. Has anyone had any experience just calling pure code in a DLL from LabVIEW RT?

Thanks in advance for your help.

Eric

[crelf]

...when building the cvi install, use the embedded laview runime libray(very small dll)...

Now if only the LabVIEW Runtime Engine was small... :laugh:

[Khalid]

Found this nice utility on NI's website which checks if a DLL is kosher for RT:

http://digital.ni.com/public.nsf/allkb/0BF...6256EDB00015230

Regards,

-Khalid

[Rolf Kalbermatter]

For your particular situation if wsock32.dll is standalone and doesn't make a calls to

to other system files, then it may work( it probably is an activeX and will be trouble)

Best option is to compiled your code and build a distribution, ask the compiler to include

all the dependent libraries; the copy them to labview for trials.

wsock32.dll is the 32 bit implementation of winsock and that is the major provider for all network related protocols other than netBIOS. As such last time I checked it is just a normal DLL without any ActiveX involvement. In fact Winsock used to be a Microsoft port of the Berkeley network socket library, but according to Microsoft sources they have in the meantime developed their own code since they had an issue or two about not mentioning that they did use the Berkeley library in the first place, which is just about the only requirement you have to follow if you are using that source code in your own product.

The Pharlap OS should come with its own implementation of wsock32.dll since this is THE interface to use under the 32 bit Windows environment to do any TCP/IP or related network access and LabVIEW will link to that library too for its TCP/IP and UDP functionality.

Rolf Kalbermatter