LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Tescom ER5000 communication

Solved!
Go to solution

@ron.jacak wrote:

nyc wrote:
Since they supplied a sample LabVIEW program, I would try to get them to help you with getting it to work.

I completely agree.  I've already spent a couple hours on the phone with their tech support.  They have assured me their DLL and sample LV code is all I need to run.  They further added that because their software is able to control the device, it has to be a Labview setup issue.  They told me to contact "LV tech support" which is how I got here.


EDIT:  Did they say for which version of LabVIEW their sample and DLL was originally developed?

0 Kudos
Message 11 of 28
(1,850 Views)

EDIT:  Did they say for which version of LabVIEW their sample and DLL was originally developed?

They distribute sample code for LV versions 8.5, 8.6, 9, 10, 11, 12 and 13.  (I'm assuming they mean 2009, 2010...)  The DLL appears to be a VC++ project.  I don't know what version or architecture it was compiled with.

 

Is there some way to test a DLL (without a VC++ installation)?  Do I need to make it executable (ala Linux chmod) to run?  I feel like the problem is something simple like this. 

0 Kudos
Message 12 of 28
(1,840 Views)

@ron.jacak wrote:

EDIT:  Did they say for which version of LabVIEW their sample and DLL was originally developed?

They distribute sample code for LV versions 8.5, 8.6, 9, 10, 11, 12 and 13.  (I'm assuming they mean 2009, 2010...)  The DLL appears to be a VC++ project.  I don't know what version or architecture it was compiled with.

 

Is there some way to test a DLL (without a VC++ installation)?  Do I need to make it executable (ala Linux chmod) to run?  I feel like the problem is something simple like this. 


According to their User Guide, the DLL is 32-bit. You will need to be running LabVIEW 32-bit.

 

No, a DLL does not need to be made "executable". It is used as-is.

 

You need to ask them why the Startup.VI is calling their DLL with CommPort set to 6. Why 6?

 

 

0 Kudos
Message 13 of 28
(1,838 Views)

According to their User Guide, the DLL is 32-bit. You will need to be running LabVIEW 32-bit.

 

You need to ask them why the Startup.VI is calling their DLL with CommPort set to 6. Why 6?

 


I am running the 32-bit version LV 2013. 

 

I don't know why they put a default value of 6 for the COM port, but I have changed this to the port I'm connected to.  I check the port thru the Device Manager right before I run Startup.vi every time.  The Startup.vi runs but it never returns a value of success.  The function it's calling in the DLL is supposed to return true upon success, and false otherwise.  It seems as though LV is unable to open up a connection on the COM port?  Is there some other way I can test serial port I/O from within LV?

0 Kudos
Message 14 of 28
(1,835 Views)

@ron.jacak wrote:

Is there some other way I can test serial port I/O from within LV?

See if you have an instrument with a serial port.

0 Kudos
Message 15 of 28
(1,827 Views)

I am on Windows 8.1 laptop. Running Dependency Walker on their DLL shows that it is dependent on 3 DLLs which are missing on my system.

I would not be able to use their DLL on my laptop

 

You might want to see what Dependency Walker shows on your PC.  http://www.dependencywalker.com

 

 

0 Kudos
Message 16 of 28
(1,817 Views)

Yet another observation about their Startup.vi

 

They are using Application Directory VI.

According to LabVIEW help: 

If you call this VI from the development environment and the VI is loaded in a LabVIEW project file (.lvproj), this VI returns the path to the folder containing the project file. If the project is not saved, this VI returns <Not a Path>.

If the top-level VI is not loaded in a project, the VI returns the path to the directory containing the top level VI. If the VI is not saved to disk, this VI returns <Not a Path>.

 

You may want to double-check that the path that is being passed to their DLL is correct.

0 Kudos
Message 17 of 28
(1,813 Views)

This tip is great.  I will download this utility and investigate. 

0 Kudos
Message 18 of 28
(1,810 Views)

I have actually changed the VI so that the Call Library Function Node has the path to the DLL hardcoded to make sure it's found properly.

 

Reading about serial port communication, I just read that COM ports are zero-based numbered in Labview.  I thought I had found my problem.  I changed the CommPort parameter to 3 (since I'm using COM4) but that didn't help.  That means the DLL code must use whatever value is passed to it for the COM port.

 

 

0 Kudos
Message 19 of 28
(1,805 Views)
Com ports are not zero based since LabVIEW 6 and only for the obsolete serpdrv. It would be irrelevant in any case since you are not using the LabVIEW serial port functions.
0 Kudos
Message 20 of 28
(1,785 Views)