LabVIEW

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

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.

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

Staff Applications Engineer
National Instruments
Certified LabVIEW Developer (CLD), Certified LabVIEW Embedded Systems Developer (CLED)


Don't forget Kudos for Good Answers, and Mark a solution if your problem is solved

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

Staff Applications Engineer
National Instruments
Certified LabVIEW Developer (CLD), Certified LabVIEW Embedded Systems Developer (CLED)


Don't forget Kudos for Good Answers, and Mark a solution if your problem is solved

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.

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. 

Rolf Kalbermatter
My Blog