Tescom ER5000 communication

[ron.jacak]

Hi experts,

I'm having trouble interfacing with a pressure regulator and am hoping somebody here can give me some ideas on things to try.  I'm running Labview 13 on a Windows 7 64-bit computer.  The pressure controller/regulator I'm trying to connect to is a Tescom ER5000, and I'm trying to do this with a (on the computer side) USB to serial port adapter cable, connected to an ADAM-4520 RS232 to RS485 adapter, which is wired directly to the Tescom regulator.  We believe that the cabling from the computer to the Tescom (USB all the way out to the Tescom wires) is fine as we are able to see/control the regulator using the Tescom supplied program ERTune (though, I'm not ruling anything out).

The problem I am having is I am unable to communicate with the regulator using Labview.  I am trying to use the Emerson supplied DLL file (attached to this post) in Labview to communicate out over the USB-to-serial port with the Tescom.  Emerson also supplies a small Labview library (also attached) which can be used to test connecting to the Tescom and demonstrate how to read and write values to the device.  If I run the Startup.vi instrument in the library, I do not get the proper return value and the program just cycles.  If I try to run the ER5000Test.vi, it freezes Labview.  It looks as though it starts running, and then shortly thereafter Labview stops responding and I have to kill the program using the Task Manager.  If you open the Block Diagram of the ER5000Test.vi, you can see that it calls the Startup.vi instrument.  If you open the Block Diagram of Startup.vi, it only has two parameters.  I've changed the COM port parameter to the one on my system, and basically double-check this (with what's found in the Windows Device Manager) every time I try to run the VI.  Not once have I run the Startup.vi and succeeded in getting a proper return value.  My hunch is that the Labview is freezing (when I run the ER5000Test VI) because it's dropping down into the DLL call and that call never returns.  That implies to me that data is getting sent out on the USB port but never coming back.  

I think I've read through every single other post containing the word "Tescom" on this forum, and did find one post in which RobCole uploaded a LV library (http://forums.ni.com/t5/LabVIEW/Example-code-for-tescoms-er3000/td-p/536548) that uses VISA to connect to a Tescom ER3000 (which is just an older version of the model I'm using).  I'd really prefer to just use the DLL that was supplied with the device rather than having to use his VISA-based approach.  I have talked to Tescom tech support and they have told me that the supplied DLL is all that is needed to interface with the Tescom using Labview.  They have also assured me that the DLL works fine on Windows 7.  

I think it's very strange that I can see and control the regulator using the manufacture supplied program ERTune, but can't even connect to it using Labview.  Are there drivers that I might be missing for USB-to-serial port comm?  Is there some way I can monitor the state of the ports to see if signals are going out/coming in properly?  Any other ideas on how to debug this?  Any help is appreciated.

[nyc_(is_out_of_here)]

You should be able to communicate with the instrument with a terminal program such as TeraTerm.

Forget about LabVIEW at the moment.

[ron.jacak]

I downloaded TeraTerm and opened up a connection on the serial port.  I tried sending some commands out over the wire but I'm not sure if they were received.  I don't really understand the communication protocol well enough to send properly formatted messages that will trigger a response back from the device.  I'm assuming improper messages are just ignored.

I definitely can communicate with the device using the manufacturer supplied program, which rules out any bad cables or wiring.  It's definitely a problem somewhere within my Labview setup.

If the manufacturer supplied DLL was 32-bit, and I'm running this on 64-bit Windows 7, is it possible Windows doesn't use the DLL properly?

[nyc_(is_out_of_here)]

---

@ron.jacak wrote:

I downloaded TeraTerm and opened up a connection on the serial port.  I tried sending some commands out over the wire but I'm not sure if they were received.  I don't really understand the communication protocol well enough to send properly formatted messages that will trigger a response back from the device.  I'm assuming improper messages are just ignored.

I definitely can communicate with the device using the manufacturer supplied program, which rules out any bad cables or wiring.  It's definitely a problem somewhere within my Labview setup.

If the manufacturer supplied DLL was 32-bit, and I'm running this on 64-bit Windows 7, is it possible Windows doesn't use the DLL properly?

---

If you don't understand the serial port protocol, how do you expect to get it working with LabVIEW?

Contact the manufacturer and get this information.

You are just adding complexity when calling DLL from LabVIEW.

If you can't get communication with the instrument to work with TeraTerm then you have no business doing anything else.

 Edit:  Their datasheet claims that they have software samples for LabVIEW, VB.NET, C and C#.

[ron.jacak]

---

@nyc_(is_out_of_here) wrote:

---

If you don't understand the serial port protocol, how do you expect to get it working with LabVIEW?

You are just adding complexity when calling DLL from LabVIEW.

---

Simple: The manufacturer supplied Labview VIs and a DLL that convert human-parseable commands into bits.  I know the commands I want to issue - I shouldn't have to convert these long strings of commands into binary to do that.  That's why there is a DLL distributed with the device.  Your comment is akin to saying "if you don't understand machine language, how can you ever expect to get a C program to work?" 

How is using a DLL within Labview adding complexity?  I have Call Library Function Nodes for other DLLs all throughout my VI.  No problems with those.

[ron.jacak]

Yes, they do distribute a Labview example.  That's exactly what I can't get to run.  I explained this in detail in my original post.

[nyc_(is_out_of_here)]

---

@ron.jacak wrote:

Yes, they do distribute a Labview example.  That's exactly what I can't get to run.  I explained this in detail in my original post.

---

Edit: If they are not willing to help you troubleshoot their sample LabVIEW program, I am not sure what we can do from a distance.

[ron.jacak]

---

@nyc_(is_out_of_here) wrote:

They also have their own software that you can download.

Try that. You need to verify that your entire setup is correct.

---

ERTune, yes I know.  We can use the device as intended using the manufacturers supplied software.  We need to be able to control it from Labview though.  I included this in my original post, as well.  I guess it was not clear.

[nyc_(is_out_of_here)]

---

@ron.jacak wrote:

---

@nyc_(is_out_of_here) wrote:

They also have their own software that you can download.

Try that. You need to verify that your entire setup is correct.

---

ERTune, yes I know.  We can use the device as intended using the manufacturers supplied software.  We need to be able to control it from Labview though.  I included this in my original post, as well.  I guess it was not clear.

---

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

[ron.jacak]

---

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.