LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Problem with serial port and external DLL

Solved!
Go to solution
Highlighted

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():

 

test.png

 

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.

0 Kudos
Message 11 of 26
(984 Views)
Highlighted

@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.

 


@flowsen21 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?

Rolf Kalbermatter
Averna BV
0 Kudos
Message 12 of 26
(964 Views)
Highlighted

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.

0 Kudos
Message 13 of 26
(951 Views)
Highlighted

Hello flowsen,

 

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

Greets, Dave
0 Kudos
Message 14 of 26
(943 Views)
Highlighted

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

0 Kudos
Message 15 of 26
(936 Views)
Highlighted

@flowsen21 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.

Rolf Kalbermatter
Averna BV
0 Kudos
Message 16 of 26
(916 Views)
Highlighted

So did you try it on an 32 bit system?

Greets, Dave
0 Kudos
Message 17 of 26
(912 Views)
Highlighted

@daveTW wrote:

So did you try it on an 32 bit system?


Tht shouldn't really matter for user applications.

Rolf Kalbermatter
Averna BV
0 Kudos
Message 18 of 26
(908 Views)
Highlighted

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); }
0 Kudos
Message 19 of 26
(893 Views)
Highlighted

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.

Rolf Kalbermatter
Averna BV
0 Kudos
Message 20 of 26
(881 Views)