LabVIEW
Can a LabVIEW dll be run by other SW tools?
Solved!
It should work with other software packages. You will need at least the LabVIEW Runtime Engine installed to use the DLL.
Use of a LabVIEW DLL from within LabVIEW is a pretty roundabout way to go about it. Better is to directly use the according VI libraries as it strips out several potential performance bottlenecks.
What you have to watch out when creating a DLL from LabVIEW code for use in other environments is that you do not use LabVIEW native datatypes such as String and Array handles, and preferably also no clusters in the API interface. String and Array handles are LabVIEW specific datatypes that not only are difficult to interpret and use correctly by other environments but also only can be managed by the correct LabVIEW memory manager functions which are not really possible to teach Matlab and other environments to use, and even pretty hard to get right in C, since the calling application needs to locate the correct LabVIEW runtime the DLL is loaded into and running it.
Clusters are usually problematic since different environments have different constraints in how they like to align elements in their equivalent collection datatype (and their is no way to configure a cluster in LabVIEW to use anything but LabVIEW handles for strings and arrays inside the cluster.
So avoid clusters and configure the DLL interface to use C pointers for arrays and strings!!
If you watch out about these it is definitely possible, although interfacing DLLs is serious low level C programming no matter how you go about it and accordingly requires some good understanding of how DLL functions are called by a C compiler in order to really make that work reliable. In addition to that you also need to understand the specific intricacies of the environment you are using about calling DLL functions, be it Matlab, Visual Basic or Python, etc. Each of them has its very own specific methods to create an import definition for a DLL function, which is both very specific to that environment as well as very much low level defined by the nature of a DLL function interface. It's all located very close to the bare metal assembly code level of what executes directly on the CPU without any Active X type libraries or .Net managed code environment. One single wrong definition usually means directly some access violation with protection fault error if you are lucky, or obscure memory corruptions if you happen to be unlucky.
Well the DLL interface was developed about 30 years ago, not with ease of use for non programmers in mind, but with what the CPUs at that time could reasonably handle. That did not include complicated type library descriptions of the interface, nor any managed code interface like in .Net. With such technologies involved Windows 3.0 would have been unable to load on a 33MHz 80386 CPU in any reasonable time.
If you wanted to do any advanced things you had more often than not anyhow to get down to assembly programming, so the difficulties of calling a C interface was not even considered a disadvantage in comparison to the rest but in fact a steep improvement to doing your own assembly programming.
Backwards compatibility concerns has prevented anyone from significantly enhancing the interface specification in any way and new technologies like ActiveX and .Net on Windows or Objectve C on Mac have further marginalized the need for such improvements. But any of these techniques is platform specific and with its own complications so the traditional C based DLL interface is still the "least common denominator" for all programming environments. But it comes with its trouble.
Add to that that Mathworks Inc and NI are in many ways competitors. NI choose from early on to show how to use Matlab from within LabVIEW as they recognized that there are certain things that Matlab simply does better but Mathworks always showed a pretty hesitant way to support the other side around, maybe because they felt their Matlab environment could do everything that LabVIEW can do at least as good, or maybe they felt to threatened by LabVIEW. You may have to decide about that.
As to integrating a simple DLL which only uses standard numeric types you could probably circumvent the issues about the various missing header files by completely eliminating the #include "extcode.h" line from the generated LabVIEW header file for your DLL. If you use a current LabVIEW version the resulting datatypes used in the header file should be all C99 compatible inttypes.h types and provided the Matlab importer understands C99 you should be pretty much fine without any LabVIEW specific imports and could probably get away with removing extcode.h completely and inserting an include for inttypes.h instead. If you start to use clusters (C structs) in the interface things get a lot more complicated (the lv_prolog.h and lv_epilog.h get quite important on Windows to get the struct definitions properly aligned).
All in all calling DLLs through exported functions is a C programming problem on several levels. It requires some understanding about what a C compiler does when calling functions. But it also requires knowledge about how to provide proper memory buffers for parameters to those functions, and specific knowledge about each function how it exactly expects these buffers to be prepared. There is simply no point and click only wizard like solution that can work reliably for this interface!
It should be easy enough to make a LV executable that takes the image and analyse it through Matlab.
