Interface dll function with struct in LabVIEW

[WG-]

I'm really sorry but what do you mean with 

"But you will have to configure one CLN Parameter per Cluster element."

I have to put 9 CLN's behind each other and give each parameter one by one? How do I do that :? I'm not that familiar with CLN's. Maybe you have an example?

[rolfk · Accepted solution]

No no! You have one CLN with all the parameters as now, but instead of one parametercfor the struct you have one parameter for every element in that struct. Have a nice weekend.

[Intaris]

Rolf,

Seriously?  That works?  Cool.  I'll have to remember that one for future use.

Psst.  Any chance of a nugget on some of the intricacies of windows-programming from LabVIEW.  You're always popping up with real gems like this that I really wish we could steal benefit from your expertise a bit more....

Shane

[WG-]

Omg that is just awesome, Rolf, it worked just like you said. Thank you very much!

[rolfk]

---

@Intaris wrote:

Psst.  Any chance of a nugget on some of the intricacies of windows-programming from LabVIEW.  You're always popping up with real gems like this that I really wish we could steal benefit from your expertise a bit more....

---

Well I guess I could write a nugget about it but then it's always also a question of thinking of something to write about.

As to most of the Call Library Nodes details, they are not really Windows specific. It's a multiplatform LabVIEW feature and most of the things that go with it apply for all LabVIEW platforms. It's one of the reasons why I specialize on it, and not on Active X or .Net or Silverlight or whatever new Windows hype comes along

As to Call Library Node trivia and more in depth details, for those who haven't come across it yet, a good start might be a blog I did some time ago. I always intended to add one or two more parts to it detailing the thoughts, ideas and solutions I came up with based on the experience with the OpenG ZLIB library but never managed to get to it.

[K1200LT_rider]

It would be nice if NI would publish a comprehensive tutorial on how to pass parameters between DLLs and LabVIEW.  I remember reading something from NI many years ago on this subject, but it wasn't exactly comprehensive.  NI pretty much has an obligation to do this, right?  NI?

[WG-]

@K1200LT rider when I was looking for an answer to my question I indeed find some examples at the NI site. But they were all written in LabVIEW 5.5 and any of the examples that comes with LabVIEW weren't relevant for my question.

[rolfk]

---

@K1200LT rider wrote:

It would be nice if NI would publish a comprehensive tutorial on how to pass parameters between DLLs and LabVIEW.  I remember reading something from NI many years ago on this subject, but it wasn't exactly comprehensive.  NI pretty much has an obligation to do this, right?  NI?

---

There are examples about that, one specific about parameter passing, shipping with every LabVIEW version. Check out your Example Finder!

Reality is, no matter how comprehensive, extensive, elaborate and whatever they would do something like this, people will keep posting questions. Partly because who the f... reads User manuals anyhow , partly because there is so much information already available in the online documentation, shipped examples, NI and 3rd party communities, forums and whatever that nobody, not even Google, can remember them all.

And has NI any obligation to do anything? I would say they are free to decide what information they provide and what products they decide to develop. Do I like it all the time? Sure not, but obligation, come on!!! Maybe the obligation to provide a reasonable service for the money I pay. Yes but that is as everything subjective anyhow, and if I don't like it I'll have to find someone who suits me better.

This particular case is a real corner case anyhow. Nobody in his right mind passes clusters by value, eventhough it is possible. And even less people know what a C compiler does when you decide to do it in this way. It's definitly not NI's obligation to educate you about all and every C programming quirk that is out there. Study compiler design if you want to know all those details, or partake in an open source project where this is a thema.

[majoris]

I'm alittle uncertain whether this problem was solved how I think everyone would normally solve it: By using the adapt to type and using the pointer to struct you recieve from Labview in your C code. I've attached a VC++ 2010 Express project (with 32-bit DLL) and a Labview 2010 32-bit vi as an example of how this is normally solved using your specific struct/cluster. I hope this makes it easier in the future for you.

1) Generate the struct in labview by manually building the cluster (see DLL_Example\Example 32-bit.vi).

2) Wire the cluster and select adapt to type. If you look up the Call Library Function help, it states explicitly that this will cause a cluster to be 'passed by reference'. In this context, and based on the fact that it's passed as a 'void *', we know we are to receive a pointer to the struct that we can read and write to (i.e. by derefencing the variable).

3) Generate .c code by right clicking the Call Library Function (see DLL_Example\DLL_Example\Labview Output.c). If we had used your original struct, this is where we would have noticed that labview uses a different data representation for a string than we might be used to, and would have had to rethink how we wanted to import/export that data. I chose to simply use a U8, as suggested.

4) Opening the Labview Output.c, we note several interestig things; specifically that Labview includes 3 different files to our project. You can handle these files in two ways: first, you could simply add the cintools directory in Labview to your header path in your compiler. Alternatively, you can do what I did: just write out the important parts and ditch the headers. What do the important parts do? As mentioned earlier in this thread, you need to work out the alignment of the structs so that they are aligned the same as they are in Labview, instead of how Windows would normally do them. Hence the  #pragma statements in my DLL_Example.cpp. I also have to define the types manually as a result. Normally, you would just update the header path in the project, but I wanted to show the reason why they are included.

5) Export your symbols and test out the DLL. In my DLL, I take a constant structure, pass it into C++, add one to each parameter. My final project is a VC++ project DLL_Example\DLL_example.sln. DLL is in DLL_Example\Release\DLL_Example.dll. You will likely need to update the path of the Call Library Node to point to the DLL.

Also note that this is an entirely 32-bit example. It will need to be recompiled to run with 64-bit Labview.

I hope this clears up some of the confusion.

[K1200LT_rider]

The problem that I have run into several times is when I get a non-NI card of some kind, and I get a DLL with it along with a handful of C code examples.  A call to the maker tells me they have no example LabVIEW code and have no interest at the moment of looking into making LabVIEW work with it.  OK... so I look at the parameters needed for this DLL, and I see that it takes in a pointer to an INT32.  The example VI "Call DLL.vi" shows 32 examples of passing all possible numeric types by value, but there isn't a single example of how to pass one by pointer.  Another time I had a DLL from another company that needed a pointer to a callback function.  I had to give up on the idea of using LV for that one (after doing lots of searching), and I wrote the app in Visual C++. 

The examples that are in "Call DLL.vi" are great and should be used as examples for writing the DLLs as well as LV code.  However, getting DLLs from outside companies can put you in a pickle for parameter-passing when they give you unusual data types.  The Help topic "Configuring the Call Library Function Node" contains far more information than what is demonstrated in the example VIs, and it gives a quick mention about how to select if a numeric is passed in by value or pointer (if you don't read carefully and thoroughly, you'll miss it).  "Call DLL.vi" should probably have at least one example of passing a numeric by pointer (along with an explanatory note saying how to set it) so customers don't get the wrong idea that something so basic as this can't be done.  I'm sure there are a few other parameter types that should be added as well.  I would also like to see a few more example VIs added on the use of the Call Library Function Node.

I'd still be interested in seeing how to pass a cluster by value.