LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Problem with serial port and external DLL

Solved!
Go to solution

No, there is no VI.

 

I don't get, what

 

strcpy(&port,(LPCTSTR)m_1_connect_turntable);

causes. m_1_connect_turntable is _T("").

 

0 Kudos
Message 21 of 26
(1,827 Views)

It's a global variable so one of the calls to UpdateData() most likely copies the number from the UI into this variable.

Rolf Kalbermatter
My Blog
0 Kudos
Message 22 of 26
(1,816 Views)
Solution

I found the solution (some weeks ago):

 

When the turntable is connected to Port COM6, I don't have to pass an integer of "6" but a "54" to the function (the corresponding ACSII character of a "6"). Everything works fine now, thank you all for your help.

 

Regards

Florian

0 Kudos
Message 23 of 26
(1,701 Views)

well I see, it sort of could have been infered from the source, but without the context where it was read from the control and seeing that that control is in fact a string and not an integer, it's pretty hidden.

 

BTW. I took a look at the source code snipped you showed and it is BAAAD!

 


@User002 wrote:

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); }

The red part is potentially causing a memory corruption. There is a one byte variable "port" on the stack which is then copied the string contained in m_1_connect_turntable. This will copy at least the entered number character PLUS one null termination character into a variable that can only really hold one byte. It is likely going ok since the stack is usually aligned to 4 byte bounderies so that that additional null byte is written into unused memory but it is definitely bad. And unless they do some parameter verification when copying the control contents into m_1_connect_turntable, things might get very interesting if the user wants to enter COM port numer 2345. Then the stack truely would get corrupted and the software would crash badly sooner or later.

 

All in all, the fact that the port number is supposed to be the ASCII chracter for the actual number and this rather stupid error doesn't give me a lot of confidence for the rest of the software, both inside the device firmware as in their PC host software.

Rolf Kalbermatter
My Blog
Message 24 of 26
(1,685 Views)

Yes, you are right. I just tried to enter a four digits number in the software and it crashed :-).

0 Kudos
Message 25 of 26
(1,670 Views)

And it only really works for COM ports up to COM9. Probably not a big problem in most situations but definitely a totally unnecessary limitation. And COM10 and higher is not impossible to get when you have added several serial devices to a system.

Rolf Kalbermatter
My Blog
0 Kudos
Message 26 of 26
(1,663 Views)