LabVIEW 2018, 2 years experience
I am hoping someone is able to point me in the right direction.
I am working with a MicroGate Serial Adapter and am trying to put together a data acquisition application. The MicroGate adapter comes with an API, which is written in C\C++. I am utilizing the Call Library Function Nodes (CLFN) to open, initialize, and close the adapter (all without errors), but calling the receive functions to read the serial data is giving me some problems. The receive function utilizes a structure called OVERLAPPED, which I found in WinBase.h (figure 1) which is what I am having problems figuring out.
When calling the other functions I was able to use clusters as the required structures (figure 2), but for some reason the receive function is giving me errors, and I am thinking that it is the way I setup the cluster or the CLFN (figures 3 - 5).
I have tried changing the calling convention to C instead of the stdcall, but that did not help.
I have also included the API documentation portion for the receive function (figure 6) and the VI.
At this point I am open to any suggestions.
Solved! Go to Solution.
While it can be done theoretically (with a LOT of pain and hurting) to interface to this API with LabVIEW directly it is definitely not worth the effort. The OVERLAPPED structure is difficult to represent as a LabVIEW cluster due to its pointer sized elements AND the fact that it contains an union element. LabVIEW does not know anything that can be used like an union aside from possibly Variants but they are not suited at all to represent a C union in a binary compatible way.
Also the asynchronous nature of any API that uses the OVERLAPPED structure is definitely an extra problem that even many C programmers struggle greatly to get right.
Basically you should consider to write a wrapper DLL in C which does the nitty gritty low level details of handling this asynchronous API if you really want to use it asynchronously. Most of these APIs also allow to use it synchronously which is indicated to the API by passing a NULL pointer to this parameter. If that is an option for your API you should definitely use that instead. In that case you would configure this parameter as Pointer sized integer passed as value and wire a 0 constant to it.
If you feel you need to use the asynchronous functionality of this API and feel not confident about writing a wrapper DLL yourself you definitely lack the knowledge to make this work in pure LabVIEW. The knowledge needed to make this work without wrapper DLL is in fact at least one magnitude more complex than writing the wrapper DLL in C.
Thank you for your insight. Unfortunately, the asynchronous option is a requirement I cannot avoid.
Thank you again for your help.
Is this requirement because the API doesn't support synchronous operation or because you feel you have to use asynchronous operation for some reason?
In the first case the simplest method would be to create a synchronous function in the DLL wrapper that you can call from LabVIEW and which implements internally the asynchronous call to the API. In the second case you should try to explain why you think so. Implementing an asynchronous function API is always cumbersome and trying to get that across to the LabVIEW level is adding some complexity to it that you really want to avoid if possible at all.
The API does have functions that are able to handle synchronous operation. However, in the past my group have been utilizing the functions that operate with the asynchronous options and I am required to do the same. As a part of the project, I was asked to look into the possibility of creating a library of VIs to handle function calls to the API directly (instead of using a wrapper DLL). Your earlier explanation made me realize that I can create a library of VIs that handle the calls to a wrapper DLL, which will produce the desired result, and will be far less time consuming than trying to figure out how to handle the complex structures in LabVIEW directly.
I should also add that I have access to a wrapper DLL that someone else had created a few years back, and I will be diving into that to see if it will work for what I need. Or I may create one myself, if needed.
Thank you again for your help.