Calling a DLL

[alfa]

In this VI, the DLL doesn't have the 'size of the array' as separate parameter.

What are the 'problems' using this VI in a while loop?

Download File:post-1855-1111436965.vi

[aledain]

In this VI, the DLL doesn't have the 'size of the array' as separate parameter.

What are the 'problems' using this VI in a while loop?

4281[/snapback]

Cannot view your code because I don't have 7.1. If you post the DLL function call someone may be able to suggest more relevant information. I don't think in general there' any issues with calling a DLL function within a loop, provided your inputs and outputs are setup correctly.

Otherwise with DLL's you must (usually) preallocate your array before passing it to the DLL (if it takes an array as input). Use the array initialisation tool for this (see attached).

If the DLL returns a single value then use a replace array element after the call and a shift register the store the array (see attached).

[alfa]

Cannot view your code because I don't have 7.1. If you post the DLL  function call someone may be able to suggest more relevant information. I don't think in general there' any issues with calling a DLL function within a loop, provided your inputs and outputs are setup correctly.

Otherwise with DLL's you must (usually) preallocate your array before passing it to the DLL (if it takes an array as input). Use the array initialisation tool for this (see attached).

If the DLL returns a single value then use a replace array element after the call and a shift register the store the array (see attached).

4288[/snapback]

Thank you for the answer.

I have this problem:

I'm reading for example messages( each message has 8 words), first word has the label FF, the rest label 8.

When I'm reading a new message the FIRST word with label FF is from the last message and the words with the label 8 are from the new message; only the third message is correct, the new word with the label FF and the new words with the label 8 are from the new message.

Calling the DLL:

Input parameters: handle, channel=0, num_data_words=number of 32-bit words to read

Output parameters: msgptr=data returned; overwritten: old data overwritten by new data.

The msgptr is an array of 16-bit words, and from 5 X 16-bit words I'll have 1 num_data_word(32-bit); that's why they did x5.

[alfa]

Thank you for the answer.

I have this problem:

I'm reading for example messages( each message has 8 words), first word has the label FF, the rest label 8.

When I'm reading a new message the FIRST word with label FF is from the last message and the words with the label 8 are from the new message; only the third message is correct, the new word with the label FF and the new words with the label 8 are from the new message.

Calling the DLL:

Input parameters: handle, channel=0, num_data_words=number of 32-bit words to read

Output parameters: msgptr=data returned; overwritten: old data overwritten by new data.

The msgptr is an array of 16-bit words, and from 5 X 16-bit words I'll have 1 num_data_word(32-bit); that's why they did x5.

4291[/snapback]

Here is a better view.

Download File:post-1855-1111498288.doc

[Jorge Perez]

i have been workling with an Altera Ciclone FPGA, to develop a USB core and i want to make a VI to control that interface (bulk in/out transfers)

i develop a usb driver that had one DLL, so i write an application on VB to write data to the usb and it works, that function is on the DLL.

the problem cames up when i try to call the same function from Labview, i work with the function call node, and i can add all the parameters of the function, but i need to use pointers, as far i know labview doesn't work with pointers, how i can solve this issue ?

inside the vb code, before calling the function i use the varptr (HEX) to get a pointer value, and then that goes directly to the function.

:headbang:

please help me

or im going to die

this proyect is for the development of the mexican nuclear bomb

[Irene_he]

Treat the pointers in LabVIEW as interger U32. Then pass that interger as pointer to next function you want to call, I think it's similar like how you do it in VB. But if your parameter is **(pointer to pointer) you may have some trouble in LabVIEW, hope you only have one *.

Irene

[delbertson]

Hi

I'm currently trying to interface with a Can bus driver dll. I have used the DLL succesfully with C# but I'm having a problem in Labview that I just can't catch. I've interfaced a number of the functions using the 'Call Library Function' Block' without a problem, but it all goes wrong for me when I try and input a Cluster to one of the functions i.e....

C#

// CAN message

[StructLayout(LayoutKind.Sequential, Pack = 1)]

public struct TPCANMsg

{

public uint ID; // 11/29 bit identifier

public byte MSGTYPE; // Bits from MSGTYPE_*

public byte LEN; // Data Length Code of the Msg (0..8)

[ MarshalAs( UnmanagedType.ByValArray, SizeConst = 8 )]

public byte[] DATA ; //Data 0 .. 7

}

///////////////////////////////////////////////////////////////////////////////

// Write()

// This function Place a CAN message into the Transmit Queue of the CAN Hardware

//

// Possible Errors: NOVXD RESOURCE BUSOFF QXMTFULL

//

[DllImport("PCAN_USB.dll", EntryPoint="CAN_Write")]

public static extern uint Write(ref TPCANMsg msg);

So In labView....

So I've created a Cluster with a U16(ID), U8 (MSGTYPE),U8(LEND) and an Array of 8 U8s (DATA), I then connect that to the DLL using a 'Call Library Function' block, it all runs ok except the Data part on the Can bus doesn't seem to be getting passed correctly and is doesn't change. The Help says a cluster will get passed as a referance so that looks right. I have my 'Call Library Function' configured to handle the cluster as 'Adapt to Type' and 'Handles by Value'.

Any help on this would be appreciated.

Derek

[derhalt]

C#

// CAN message

[StructLayout(LayoutKind.Sequential, Pack = 1)]

public struct TPCANMsg

{

public uint ID; // 11/29 bit identifier

public byte MSGTYPE; // Bits from MSGTYPE_*

public byte LEN; // Data Length Code of the Msg (0..8)

[ MarshalAs( UnmanagedType.ByValArray, SizeConst = 8 )]

public byte[] DATA ; //Data 0 .. 7

}

So In labView....

So I've created a Cluster with a U16(ID), U8 (MSGTYPE),U8(LEND) and an Array of 8 U8s (DATA),

It is not possible to create an equivalent to your C# structure in Labview.

What Labview creates will be something like this:

(C++-Syntax)

struct TPCANMsg{

unsigned int ID;

char MSGTYPE;

char LEN;

LVArray** Data;

}

struct LVArray{

int Length;

char Data[1];

}

You also have to check that your dll uses 1byte struct member alignment. This is what LabView expects.

[Rolf Kalbermatter]

It is not possible to create an equivalent to your C# structure in Labview.

What Labview creates will be something like this:

(C++-Syntax)

struct TPCANMsg{

unsigned int ID;

char MSGTYPE;

char LEN;

LVArray** Data;

}

struct LVArray{

int Length;

char Data[1];

}

You also have to check that your dll uses 1byte struct member alignment. This is what LabView expects.

Well it is possible. But instead of an array place 8 uint8 elements at the end that will correspond to the 8 bytes of your data array. This array being fixed size is not treated as an array anymore really in C but really corresponds more to a cluster in LabVIEW containing the exact number of elements in it.

And byte alignment is not a problem for this structure. See other posts for all about byte alignment but basically LabVIEW always uses 1 byte alignment while most C libraries use some other alignment such as 4, 8 or 16 byte. The alignment only says that the start address of a data element in a cluster is always set to a multiple of the lower of the two values being either the size of the element itself or the byte alignment. So LabVIEW uses really so called packed memory structures while most DLLs would place an int32 on a multiple of 4 for instance adding 0 to 3 filler bytes if the previous element would not end on this memory address.

The alignment of data elements in structures can be set the by the DLL developer at compile time but for normal 32 bit DLLs nowadays under Windows you can assume 8 bytes if the library documentation or header file (look for #pragma pack(x) lines in there) doesn't show otherwise.

Rolf Kalbermatter