initializing an outdated .dll for TCP/IP connection

[TimVanDriessche]

Dear all, 

For my thesis, I'm trying to build a control VI for a Trumpf Laser with TCP/IP. The problem is the control software of this laser, its over 10 years old (it runs on windows xp, the controlling software even dates back to 2003 I believe). When I try to initialize the .dll some of the datatypes are not recognized, such as BSTR and HWND. I do need these datatypes because on the server side of the TCP connection, the software expects a BSTR or a HWND. The specific structure of the commands for laser control are in TLV structure. 

I can open a connection to the laser and when I send over a command it even shows up on the interface on the server side, but it doesn't recognized it as a command. More like a comment line or something. 

I know this is very vague but I can find answers anywhere else. Does anybody have any experience controlling Trumpf Lasers with LabVIEW or something similar? Or a VI lying around perhaps? 

The control software of the laser is TruTops Mark and the laser itself is a VectorMark Compact, both from Trumpf. 

Thanks in advance, hope to hear from you guys soon, 

Tim 

[rolfk]

A BSTR is a special OLE string format. It is ABSOLUTELY NOT the same as a LabVIEW string in any way!

For one it contains 16-bit UNICODE characters. LabVIEW strings are 8-bit Extended ASCII characters with the code page of whatever your Windows system is currently configured.

Second they contain extra length information prepended to the actual string data (and invisible to the casual viewer as it is located before the memory location that the BSTR pointer points too).

They can only be created (and deallocated afterwards) with Windows API calls 

// Create a BSTR buffer
BSTR bstr = SysAllocString(L"I am a happy BSTR"); // Contained in OleAut32.DLL

// Don't forget to explicitely deallocate the string after use
SysFreeString(bstr);

Extra complication is that the SysAllocString() function needs an Unicode string as input too, so you first have to call MultiByteToWideChar() to turn the LabVIEW 8-bit string into a Windows 16-bit Unicode string, then pass that to SysAllocString() to get the correct BSTR pointer.

And no, although a BSTR contains the Unicode data returned from the MultiByteToWideChar() function it is not safe to call an API that expects BSTRs directly with the converted Unicode string. It may work depending on what the function does with the string but it is not safe to do so as the normal Unicode string does not have the embedded length information that a BSTR has and if any function inside the function tries to interpret that length, for instance for performance reasons rather than calling wcslen() on the string to find out how many code points it contains, it will fail badly as it will interpret garbage as the desired length information.

A HWND is simply a pointer sized integer. It is a window handle but many functions allow to pass in such a parameter a NULL value (in LabVIEW simply a 0 integer) and then work with a default window such as the desktop. If it requires a valid window handle you will have to figure out a way to get that from somewhere.

[TimVanDriessche]

Hey Rolf,

Thank you for the reply.

The BSTR would define the IP adress used to start the TCP connection, I'll try to make the correct structure to send to the .dll. I found a program online to determine the HWND. But judging from you're post, I'm thinking of trying to work around these special datatypes. As these types could potentially harm the reliability of the VI. 

Kind regards,

Tim