Using LabView with C++/Cli Wrapper

[SensorNut]

I'm trying to control a DVR (CORE 2) from IO Industries with LabVIEW. They provided a 64-bit sdk written in native c++. I wrote a 64-bit c++/cli wrapper (in VS 2015) to call the functions of the sdk. I run the wrapper in debug mode which opens LabView, However I receive the following output from VS (I think this is the main problem😞

 "Exception thrown at 0x00007FFACE3150D8 in LabVIEW.exe: Microsoft C++ exception: ni::dsc::exception::BadGuidString at memory location 0x000000E9893FCD78."
This program still runs, which I then select the VI to use the .net constructor node-> invoke node -> close ref node, then it proceeds to run through the wrapper code. However I receive  the following output from debug variables in VS.Null pointer in VSThis will cause the rest of the code to fail since g_hApi is a shared pointer (handle) to the native c++ class, and my catch block in enacted which returns a 3 to LabVIEW. An example of my code can be found on stack overflow at :

https://stackoverflow.com/questions/51675297/c-cli-dll-wrapper-for-native-c-to-be-used-in-labview.

I would appreciate any feedback to this problem, as well as a possible different approach to interface LabView with the DVR.

Thanks

NOTES:

• Labview 2017 (64-bit)
• VS 2015
• IO Industires DVR/Software
• No direct-x possibility

[rolfk · Accepted solution]

If that SDK is really written in C++, rather than C# and using .Net, I don't think it is a good idea to try to interface this to LabVIEW as a .Net assembly. You may have more success by creating instead an old style (unmanaged) DLL that exports your functions and interfaces to LabVIEW through the Call Library Node.

Obviously it would seem that your first call Instance::initialize() already fails for some reasons. There might be a myriad of reasons for this but most likely somehow somewhere your SDK API that you are calling somehow doesn't get auto initialized properly or it can't find specific dependencies that it might or might not try to located dynamically. In either case the problem at that point is not the code in your wrapper but something you might have forgotten to call first (despite the note that this function call needs to be the first to call from this API), or the way the DLL and its possible dependent DLLs are located, or a clash with the C runtime initialization from your wrapper and the SDK API. By eliminating .Net from the equation you at least avoid one extra monster in the cage that could try to fight the other monsters (a C++ library containing the boost library can be an ugly beast to tame when trying to interface it to non-boost environments).

The boost developers are doubtless geniuses in what they did with this library but geniuses sometimes tend to create a solution to problems that causes rather more problems than they actually solve.

[SensorNut]

I took your advice and just wrote it in a c++ dll wrapper that exports the functions. Everything works as expected. Thanks

[natasftw]

I'd be curious what those calls into LV are trying to do.  You're working with a Camera Link camera and the error throws "dsc"

Typically, I'd associate that with the DSC module but I can't figure out what you'd need it for. 

I'm also a tad confused.  You're opening LV from your wrapper or you're wanting to run this in LV?  Are you trying to run all of this with the LV CLI?

[rolfk]

---

@natasftw wrote:

I'm also a tad confused.  You're opening LV from your wrapper or you're wanting to run this in LV?  Are you trying to run all of this with the LV CLI?

---

No, as far as the code on StackExchange is concerned it is a fairly "simple" situation. The Core2 library is written in C++ and uses internally boost (which in itself can't be called simple at all). In order to call this C++ API from LabVIEW he needs to create a wrapper, which he also writes in C++.

In his first approach he tried to create this wrapper as a .Net assembly (you can create .Net assemblies in C++ too, although 99% of the programmers in the world use C# nowadays for that). Something in the interaction between Core2 library, possibly boost, the .Net runtime, and the LabVIEW environment doesn't quite work out the way the Core2 librry developers had planned. This could be a missing DLL in the (probably) myriads of DLL dependencies this hybrid monster must consist of.

By removing the .Net runtime from this ugly cocktail, you reduce the complexity of the setup considerably and that can be obviously enough to simply make it work.

As to trying to go back to the .Net assembly, don't! There is no advantage in a C++ created .Net assembly above a native C++ DLL. But you create a very complex and fragile hybrid monster that can rear its ugly heads anytime it likes and debugging that is a nightmare. You may feel that the "convenient" configuration like style of the .Net property and method nodes is superior to the manual and intimidating Call Library Node configuration. But you seem to know more than enough C(++) to be able to create a working wrapper and therefore also handle the Call Library Node configuration properly and if done correct it is way superior to the .Net interface in terms of performance.

[SensorNut]

I'm only opening LabVIEW from the DLL for debugging purposes. Such that as LabVIEW was running the .net nodes I could see it actively step through my .dll. The main goal is to get LabVIEW to set some parameters for the DVR and camera, such as Region of interest, record length, frames per second, ect...

I have switched to a native c++ class and got it to work by exporting the functions I write individually, now I just need to get used to LabVIEW call library node. I'll investigate the c++/CLI wrapper next week per the earlier suggestions.