08-21-2014 09:48 AM - edited 08-21-2014 09:49 AM
@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?
08-21-2014 10:07 AM
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.
08-21-2014 10:11 AM
@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?
08-21-2014 10:19 AM
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?
08-21-2014 10:35 AM
@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.
08-21-2014 10:54 AM
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
08-21-2014 11:06 AM
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.
08-21-2014 11:08 AM
This tip is great. I will download this utility and investigate.
08-21-2014 11:12 AM
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.
08-21-2014 12:08 PM