Problem with serial port and external DLL

[User002]

Hi,

I've got a turntable (innco systems CT 0500) which is connected via an USB-RS232 Converter to a PC. I want to control it with LabVIEW.

The Software CD contains a DLL and a Header-File - I imported them both into LabVIEW.

But I'm unable to get a COM port connection via LabVIEW. There is an error return code from the ConnectTurntable() function saying "Can't open port - port adress is unknown to PC or port is used from another program".

The demo software from the delivered CD is working - the COM port connection is working correctly with it, so there must be an error in my LabVIEW Code.

Thank you in advance

[Chantastic!]

Are you running the included software while you try running the VI? It sounds like something is reserving the port, but not unreserving it. 

[RavensFan]

Why are you using the DLL?

If the DLL is also trying to access the com port, it is going to have problems because you've already had LabVIEW open the com port with your serial configure.

Either use all VISA functions, or use only the .dll and get rid of the VISA functions in LabVIEW.

[Christoph_D]

Hi,

Without any more details I tend to agree with RavenFan with the dual use of the COM port.

If you still have problems with either LabVIEW VISA or the manufacturer DLL then please upload the complete demo project since there where VIs missing the last time.

Best regards,

Christoph

[User002]

Thank you for your answers.

But my problem is still not solved. I am not running any other software that could reserve the port. Getting rid of the internal LabVIEW VISA functions didn't help either. I still get the "Can't open port" error return code.

A new (and a little simpler) version of my VI is attached as well as the missing VI from the manufacturer which was created from the DLL file and header. It is just a Call Library Function Node calling the code

extern "C" __declspec(dllexport)    int __stdcall  ConnectTurntable(   int *hTurntable,   char Port);

to connect the turntable. The manual of the turntable says that connecting is the first step. With the returning hTurntable integer you can adress the other functions like turning the device to x degrees. But these functions don't work without connecting first.

[Christoph_D]

Hi,

here we are at a point where we have to check if this is a LabVIEW problem or just a problem with the venor DLL respectively with the right calls to the DLL.

By the way: Are you really sure that the function you are calling is really called "_ConnectTurntable@8" since the "@" character shoudnt be a valid C function character?!

Best regards,

Christoph

[User002]

Hi,

yes, the function is called "_ConnectTurntable@8". I checked the working exe-file on the delivered manufacturer's CD with a hex editor and it is calling the same function (with the "@8" - I don't know what it stands for).

I also tried to create the Call Library Function Node on my own without the "Import Shared Library Wizard", but still the same problem - I can't open the port with the DLL.

I would like to send and receive the commands with LabVIEW's VISA functions. Is there any possibility to determine the serial data commands, when I just got the DLL? The manual doesn't provide any information at this data level - just the C commands that don't work with the DLL :-/..

[RavensFan]

Do you have any vendor supplied software that does some of the functions you would want?

If so, you could try  using that, and snooping on the communication scheme to see if you can decode it.  At one time, software like Portmon could do it.  You could use some serial adapters that allow you to connect the receive and transmit lines of the serial port to other serial ports that you could open up in LabVIEW to capture the data as it goes back and forth.   Execute commands with the vendor's software, and read the outgoing command and response on the other serial ports that are tapped into the first one.

It could get tricky.  If they use some sort of checksum as a part of their communication, it might be hard to decode what scheme they are using to calculate that.  It could be a lot of work to figure out all the different commands that might exist, but if you only need a few, maybe you can just figure out those.

[User002]

I just realized I have a .lib file from the manufacturer (besides the .dll and .h file on the CD). Can I do anything with it in LabVIEW?

[rolfk]

No, the lib file is necessary when creating a program or DLL in C, to resolve the functions in the DLL you want to call. A Windows executable file needs to know about any function it tries to call, even if the actual function is located in another DLL. The lib file is a precompiled file that the C compiler can link to the final program to get a valid executable file. It contains code that at runtime will locate the actual DLL and load it. It does not do anything else than what the Call Library Node does already so is totally useless in a LabVIEW context.

The @8 decoration after the name is normal name decoration for stdcall functions in a DLL, but LabVIEW should not show that normally and just let you select the name without any decoration (resolving to the decorated name behind the scenes).Not having the DLL available I can't really check why it would do this.

From the prototype and the VI it would seem that the rest of the Call Library Node is configured correctly.

So it must be something about the installation of the DLL, or the parameters you pass to it. Are you sure that the port number you have to pass corresponds to the actual COM number?

I would definitely get rid of the whole VISA resource altogether. Eventhough you are not calling any VISA functions anymore, the existence of a selected VISA resource in that control may still cause the VISA software to somehow reserve that resource.

Another nasty possibility is that a Windows driver somehow thinks that there is something connected to this port that it should use. The mouse driver is known to sometimes believe that it should open a specific serial port and try to use that device as a mouse, despite that it is something different.

Basically you either use VISA all the way and talk to the device directly with VISA functions (which requires for you to know the protocol) or you go with the DLL from the manufacturer and leave VISA out of the picture completely, including the VISA IO Control.