Problem with serial port and external DLL

[User002]

Thanks for your help. I attached the dll and the header file.

Getting rid of the VISA resource name control didn't help. I replaced it with a normal numeric control where I chose the number of the COM-Port (in my case a "6", because the USB-RS232 converter is connected to COM6). And the "6" seems to be the right number because the turntable connects correctly in the test software. I pass a "6" and get back a "0" (for no error) and a "1" (for the internal number which is required for the other functions) from the function ConnectTurntable():

It is strange that in the function prototype at the preferences of the node there is a

int32_t _ConnectTurntable@8(int32_t *hTurntable, int8_t Port);

but when I right-click on the node and select "Create C File" LabVIEW creates a C file with the following code:

/* Call Library source file */

#include "extcode.h"

int32_t _ConnectTurntable8(int32_t *hTurntable, int8_t Port);

int32_t _ConnectTurntable8(int32_t *hTurntable, int8_t Port)
{

	/* Insert code here */

}

Since there is no "@" character in C LabVIEW just deleted it but retained the "8" (which is the number of bytes to be removed by the stdcall). And the function ConnectTurntable8() doesn't exist. Maybe that is the error.

[rolfk]

@IT's unusual that the symbols in a DLL do have an underscore prepended AND the @ postfix but that is something the developer can influence in the compiler settings when building the DLL, so don't get hung up about these decorations. They are most likely not the reason that it doesn't seem to work.

---

@User002 wrote:

Thanks for your help. I attached the dll and the header file.

Getting rid of the VISA resource name control didn't help. I replaced it with a normal numeric control where I chose the number of the COM-Port (in my case a "6", because the USB-RS232 converter is connected to COM6). And the "6" seems to be the right number because the turntable connects correctly in the test software. I pass a "6" and get back a "0" (for no error) and a "1" (for the internal number which is required for the other functions) from the function ConnectTurntable():

---

So you say you get back 0 from the function and the number 1 in the hTurntable variable and that this is what is expected when no error occures. What is the problem then?

[User002]

You misread my post. I get back the correct values when i use the software from the manufacturer/vendor. When I create the function in LabVIEW I get back the wrong values.

[daveTW]

Hello flowsen,

what OS are you using? Perhaps this has an influence...

[User002]

I'm running Windows 7 Professional 64-bit (with SP1) and LabVIEW 2014 32-bit (with SP1).

[rolfk]

---

@User002 wrote:

You misread my post. I get back the correct values when i use the software from the manufacturer/vendor. When I create the function in LabVIEW I get back the wrong values.

---

And you don't get the source code of that test application? Innco on their website seems to claim they deliver both C(++) and LabVIEW code with their smaller turntables when bought with the PC connectivity option.

[daveTW]

So did you try it on an 32 bit system?

[rolfk]

---

@daveTW wrote:

So did you try it on an 32 bit system?

---

Tht shouldn't really matter for user applications.

[User002]

Yes, I've got the cpp source file of the test application.

m_1_connect_turntable = _T("");

//...

void CDllTestExeDlg::OnBTNconnectturntable() 
{	
	UpdateData(true);
	m_h_connect_turntable=0;
 	m_ret_connect_turntabele =0; 
	UpdateData(false);
	UpdateData(true);
	char port ;
	strcpy(&port,(LPCTSTR)m_1_connect_turntable);
 	m_ret_connect_turntabele = ConnectTurntable(   &m_h_connect_turntable,port );
	UpdateData(false);	
}

[rolfk]

How about the LabVIEW VIs?

What error code do you get back and what does the documentation say about its meaning? The header file does not show any error codes so it should be documented somewhere else. I still think that the port is somehow kept open by the test application and then LabVIEW can't open it.

From the look of the header file and the VI you uploaded there is no obvious reason why it shouldn't work, so the problem must be in the DLL itself and that is something you need to take up with the support of the manufacturer.