Processing a 1D double array handle using a DLL

[lespingouin]

Hi everyone,

I'm new using LabView and I'm stuck on a problem that I'm unable to solve.

My final objective is to process custom labview structures through a DLL method which will do the job.

For now, I'm trying to manipulate a simple 1d array using 'Array Handle' Labview type.

According to LabView samples and what I understood, I wrote a simple cpp source to do some easy tasks:

Code of the DLL

I created a VI which uses all these methods declared:

Blcok diagramFront panel

Problem: the sum result is incorrect.

My first guess was to check the correcti size of the array    done

So I also checked the first element of the array and found the result displayed in top.

I tried to change the configuration of the called method using 'Array Data Pointer' instead of 'Array Handle' and it worked.

The configuration is below:

Using 'Array Handle'Using 'Array Data Pointer'

 I have no explanation for that case. Does someone have an idea for this ?

Thank a lot.

Best regards.

[zou]

Your declaration in C doesn't match the declaration in LabVIEW.

Try this:

in LabVIEW, after you configured the dll call, right click the CLFN, and choose Create C File.

Then open the C file, and implement your code.

[MaSta]

LV has an example VI for DLL call that explains a bit about 1d array handle use. The actual example ARRAY1DHandle. vi reads the array size and passes it to the DLL for memory allocation. Yours doesn't do that.

[rolfk · Accepted solution]

Let me guess. You use 64-bit LabVIEW?

LabVIEW 64- bit does not ever pack data. In fact the only platform that is still currently packing data is LabVIEW for Windows 32-bit.

You could create your own define to handle that but it is easier to do an

#include “lv_prolog.h”

before the handle datatype declaration and

#include “lv_epilog.h”

afterwards. You need to add the LabVIEW cintools directory as include path to your project.

Or do the right click trick as mentioned already. The resulting C code template contains the correct datatype and the correct includes around the declaration.

[MaSta]

Being one who never used own C code directly in LV or made a DLL from it to call in LV I wonder very much, why this so complicated to use.

Sure, there is a direct C node VI where you can put C code into the block diagram, for whatever reason. I see no benefit.

Calling a DLL that was not made for LV is something else. 

[rolfk]

---

@MaSta wrote:

Being one who never used own C code directly in LV or made a DLL from it to call in LV I wonder very much, why this so complicated to use.

---

Well, for one because the typical LabVIEW programmer is NOT a C programmer. Some would go as far as to say that they are not even programmers but simply clicking an application together, but that is IMHO wrong.

However, LabVIEW is not unique in this. If you program in C# and want to call a DLL you have to worry about .Net Interop too, and sometimes things simply can't be done in C# efficiently or elegantly.

Same about Python. There the magic tool is called ctypes. And it is a pitta to use for more complex DLL interfaces but it can get the job done once you worked through all the crashes, datatype trouble and what else.

Basically LabVIEW is a high level language, at least as high as C# or Python for instance and in my opinion probably even above it. And while these exercises may seem arcane and pretty useless (everything presented in his example could be done with a build in function in LabVIEW too), it is the first step in trying to get familiar with these datatypes and being maybe, eventually, after a lot of trial and error, tons of coffee and torn out hairs and cursing like a sailor able to write real code that makes things that may be impossible or at least inefficient and very involved to do in LabVIEW. And don't forget the IP argument, some people feel that code written in C/C++ and put in a DLL is much much more safe from stealing than a LabVIEW VI. That's somewhat true up to some point in C++ but a C routine can be disassembled very very easily with nowadays tools and is for all practical purposes not much safer than putting the source out there into the open.

[lespingouin]

Hello,

Exactly, I'm using a 64-bit Labview version to build and test those DLL.

I modified my code using your feedback and it works. Thank you very much.

I heard about packing data in memory helps Labview to handle in an efficient way the memory allocation. That is the reason why I used #pragma ; I didn't know Labview created libraries for that.

To develop DLL, my purpose is to provide functional blocks to my coworker that could be easily instanced in his Labview program. That is why we have to use them.

Thanks a lot for your advices.

lespingouin

[rolfk]

---

@lespingouin wrote:

I heard about packaging data in memory helps Labview to handle in an efficient way the memory allocation. That is the reason why I used #pragma ; I didn't know Labview created libraries for that.

---

Well LabVIEW 32-bit for Windows 3.1 was introduced in September 1992. At that time most office computers had 2-4MB memory (yes that is a Mega not a Giga) and 8MB was considered a high end machine. LabVIEW had a minimum requirement of 4MB to install and work, and many users were moaning that that is exhibitive. 😁 And then they were moaning that LabVIEW was pretty slow with that amount of memory. 😁

So memory consumption was a real concern back then and the Intel CPUs contained a lot of extra transistors to make unaligned data access not a major penalty (to be backwards compatible with the 8086 architecture). So packing data on the Windows version was an easy way to buy a few extra bytes without making memory access very slow. Other platforms like the Sun Spark and HP PA Risc that came out later were not as easy on unaligned memory access and NI didn't choose to pack data structures on them for that reason. Also those Unix workstations typically had a bit more memory available to start with, so the memory "wasting" by having data elements aligned correctly in memory wasn't as much of a concern.

The LabVIEW for Windows 95/98/NT versions later on did keep using the same packed memory layout for compatibility reason, as in that way they could for instance keep using the old Watcom REX CIN resources (the predecessor to DLLs) withouth needing to recompile them.