Tescom ER5000 communication

[dacad · Accepted solution]

Ron,  Got your message.  Just happen to be working with one of my test systems this week and working with the Tescom ER's is part of that.

First, a disclaimer. I am working with the ER3000's and have not worked with the ER5000's so all may not be equal but I will share what I can and have a couple questions as well.

I actually have two versions of the Tescom VI library with different versions of the core vi's (startup, shutdown, etc)  I am using one version that 'looks' similar as far as the icons but the actual call's to the dll are a bit different.  The other set of vi's I am using look totally different but perform the same functions.  The procedure for using is the same either way however (at least for me) so what follows, I consider generic.

First, can you post some screen shots of the ERTune window(s).  I am wanting to see if it matches my tuning utility from Tescom called simply ER3000. I actually use this to set my com port. The utility will not run unless it can connect so if the port is not set correctly a screen pops up allowing you to change ports. One this is done and my tuning app can talk to the ER's, I never have to worry about the com port again so having it as a control in the Startup.vi is different than what I have.

I never use the tescom vi return values to tell me whether it worked or not, I found them to be inconsistent in the return value so just ignore them.  The best way to set this up is to create an Action Engine, otherwise known as a functional global variable.  The thing with controlling talking to the tescom is that once you run Startup, you have to maintain an active LV instance to maintain communication and the AE will do this. I have attached my AE though it will  be broken as the tescom lvlib vi's that I use will not be included but there are four cases in the core of the state machine. Startup, Shutdown, Read, Write.  That is all you need to work with the ER's in Labview. If you are running the vi's in another top level app then you only need the 'root driver vi' that I have included too.

I won't lie, I have had major issues on getting LV to talk to the ER's, even recently.  They are very particular and it can be finicky to get resolved. That being said, once you are able to talk with them in LV, it seems to stay very stable.  For this last round, I actually ended up recreating the vi's from the dll file.  You will need the dll and the (.h) header file.  Goto Tools>Import>Shared Library(dll) and it will start a wizard, select new and on the next screen, select tescom.dll and in my case at least I used PROTOCOL.H (there are several others and if you try them, it will simply tell you that it di not find the info it needed and then let you choose another) for the header file. You can then go through the rest of the wizard, I just used the defaults for everything else except I did add simple error handling, though you can change some things if you wish. If you allow it to go to the user.lib then the vi's will show up under the user heading on the vi popup menu.  When I did this, and used these newly crreated vi's it worked first time out of the gate.

Now, note that in my case and not sure about the ER5000 case, when you install the tuning utility it also installs the LV driver so this should be in place but make sure you don't have a separate install for this.  Start out by creating the AE and run Startup and then see if you can Read something. I created a typedef for the variables I typically use and have attached it as well. Note you have to feed the variable ID, not the name. And when you write data, you have to convert it to the value the the ER understands. For instance, if you want to change the Offset value, 0% is 2048, 1% is 2015 and so on. You get these values by opening a Read/Write window in the tuning utility (you can have 4-5 open at a time) and select that variable by name from the list and it will display the ER value for the common value that is presently set in the tuning windows. I also have a typedef for the four commands but that should be easy enough to replicate on your end.

Make sure to run the Close or Shutdown command before stopping the VI. Not sure about the ER5000 but if you end the vi abrubtly the dll does no let go and you will get an error next time you try to open it. At least I do with the ER3000's.

I also agree that this dll may not work on a 64 bit machine. I would try it on a 32 bit machine if you have one available. Lots of drivers out there that don't like 64 bits. You can creat the code on a 64 bit machine but liekly not run it.

If you get this far, post back to indicate if you had success or not.

[ron.jacak]

There's so much awesome in this post, dacad.  Thank you so much!  I will get started on these suggestions right away.

[nyc_(is_out_of_here)]

I fired up C# 2010 Express and used Platform Invoke to call Tescom DLL's Startup function.

I know from NI-MAX that COM6 is available.

When I set ComPort to 6, then a 1 is returned.

When I set ComPort to 7, then a 0 is returned.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Runtime.InteropServices;

namespace ConsoleApplication1
{
	class Program
	{

		[DllImport("C:\\Users\\ieguest.Lab_Laptop_3\\Downloads\\ER5000DLL.dll")] static extern int Startup(int ComPort, int retries);

		static void Main(string[] args)
		{
			Console.WriteLine(Startup(6, 2));
			Console.ReadLine();
		}
	}
}

[nyc_(is_out_of_here)]

In addition, I ran StartUp.vi on LabVIEW 2013 SP1 (32-bit), and it returned 1 on COM6 and returned 0 on COM7.

[ron.jacak]

I've accepted the comments Doug posted as the solution.  I rewrapped the manufacturer supplied DLL into new Labview instruments like Doug suggested, and upon running it, I finally got a success return value from the Startup.vi.  That implies that the manufacturer supplied LV code wasn't finding the DLL properly, but I know I set the path correctly so it doesn't make sense.  I think a couple other important things to mention are that it is critical to run the Shutdown.vi to free some resource the Tescom grabs hold off after a run of Startup.  For example, if you run Startup and get the success return value, and then run Startup again (without a Shutdown), you will get an error.  Similarly, you will only see errors if you execute Startup.vi via "Run Continuously".  If you run Startup and initiate a connection to the Tescom, abort your instrument, restart it, and try to do another Startup followed by reads or writes to the Tescom, you will freeze Labview and it requires a hard reset of Labview.  I don't know how this is all implemented, but it seems that the Tescom code does not free resources after an instrument is aborted nor does it allow more than one connection at at time.  It also cannot figure out when a Startup call has been made from the same computer and invalidate an old reference to create a new one.

ERTune.exe (distributed with the ER5000) and ER3000.exe must be pretty similar from how Doug described them.  One difference though is that you can't set the COM port in ERTune.  I was doing that through the Windows Device Manager though, so it wasn't an issue.

Thanks all for your comments.  Hopefully somebody else will find this discussion useful.

[dacad]

Glad that worked out for you.  The behavior of the dll is frustrating as you have seen.  If you startup the com link but don't shut it down, another startup sequence kills the whole system.

I have found that if I stop labview before the shutdown is peformed, I can open that particular vi and run the shutdown to close the com link.   For whatever reason, this dll in particular is not released by LV unless done explicitly with the shutdown funtion or LV itself is completely closed. Not just the vi, all of LV.

When I had worked with Tescom previously, they had said their next generation ER's would address this issue. Apparently it did not.  I have found out just this week that the ER3000's are now obsolete.  I tried to return a couple to get reconfigured on the external signal type and they want to charge more that the cost of a new ER5000.     Go Figure.

[tfranzwa]

I know this post is a few months old but I thought this would help others who have come across the same issue and who are reading this. I work for TESCOM as a controls designer. I am also a certified LabView associate developer. This post was brought to my attention by a co worker. After reading the post I downloaded the attached files (ER5000.llb and ER5000DLL.dll.gz). The ER5000DLL.dll does not have the .gz extension attached to the end of the file name so I deleted it (I think the.gz was added so the dll could be attached to the post). I opened the ER5000.llb file with LabView 2013. I ran the ER5000 Test vi and as stated I could not communicate with ER controller. I verified that the example code that is distributed with the ER controller works. That pointed us to the ER5000DLL.dll. Copied the ER5000DLL.dll from the CD and replaced the ER5000DLL.dll.gz that was attached, ran the ER5000 Test vi and was able to communicate to the ER controller with no issues. It appears that the dll that was used with the ER5000.llb was corrupt. If have any issues with the ER5000/3000 please call us at TESCOM, we are here to help.

[Dweibel]

Hey tfranzwa, 

You may no longer be at Tescom, but I thought I may reach out in the event you are. 

We have successfully gotten the ER5000DLL.dll to run from USB. What I am trying to figure out is if we can run the DLL on a crio (with windows-embedded chipset) directly from an RS485 port. We have a NI-9871 c-series RS485 communication module, and I am trying to see if we can bypass the usb commnuication and go directly to RS485. 

I am talking to emerson support and to this point I understand that the DLL is communicating with a virtual USB com port set up by the ERtune software installation. But I am still unclear if the DLL compiled code is conducting communication in an RS485 protocol, or a USB serial protocol. 

For our applicaiton, if it is indeed in RS485, we should be able to augment and recompile a new DLL that will allow us to communicate directly with one of the NI-9871 RS485 ports, rather than going to USB. 

Do you (or anyone else) have any insight here? I admit that I was reading through some of the C-code, but dont understand it well enough to answer this quesiton.

Thank you in advance.

Drew

[rolfk]

---

@tfranzwa wrote:

I know this post is a few months old but I thought this would help others who have come across the same issue and who are reading this. I work for TESCOM as a controls designer. I am also a certified LabView associate developer. This post was brought to my attention by a co worker. After reading the post I downloaded the attached files (ER5000.llb and ER5000DLL.dll.gz). The ER5000DLL.dll does not have the .gz extension attached to the end of the file name so I deleted it (I think the.gz was added so the dll could be attached to the post). I opened the ER5000.llb file with LabView 2013. I ran the ER5000 Test vi and as stated I could not communicate with ER controller. I verified that the example code that is distributed with the ER controller works. That pointed us to the ER5000DLL.dll. Copied the ER5000DLL.dll from the CD and replaced the ER5000DLL.dll.gz that was attached, ran the ER5000 Test vi and was able to communicate to the ER controller with no issues. It appears that the dll that was used with the ER5000.llb was corrupt. If have any issues with the ER5000/3000 please call us at TESCOM, we are here to help.

---

The ER5000DLL.dll.gz is not corrupt but a gnu zipped file of the DLL. You need to unpack it with a gz capable archiver, such as 7-ZIP.