TCP Bridge with Landis and Gyr


2019-05-02 13:48

I've never managed to get the TCP Bridge thing working in the past. How can I - through the setup as is with the L+G meter and internal modem - get access with MAP110?

Tags: landis & gyr

2012-03-08 04:13

Yes, the TCP Bridge is very useful for accessing meters that would otherwise be inaccessible, e.g. some clients are using it to program their meters installed in other African countries from South Africa, where the countries in question does not support CSD on their GSM networks (so you can't dial the meter); and without using a GPRS APN (in other words, the meter connects to the server internationally through GPRS).
It is also handy in many other situations, e.g. when the meters are behind a firewall, connecting out to the pnpscada server on the internet, or if you don't have a modem with you and you need to program a meter which the server can connect to, or if the meters have been programmed to only answer the caller ID of the modem on the server if the server dials it through CSD. (just to name a few situations)
But to get back to your question.
I'm not 100% familiar with MAP110, but I assume that it can connect to a Landis and Gyr meter with a static IP. If that is not correct, then you cannot use TCP Bridge in conjunction with MAP110, but if it is, you should be able to use it as follows:
The way it works from your application (MAP110/MAP120 in your case) is in the same way it works with reading/configuring a meter that has a static IP on your LAN. In other words, you connect to it over TCP/IP.
The pitfall to watch out for is the connection timing out while you are busy in the other application, so follow these instructions carefully right through without stopping or delaying.
So, basically:

  1. Start your application (MAP110/120); configure it to connect to the correct IP and port - the IP is the IP of your server and can be found by pinging your server's domain, e.g. is; the port is specified dynamically on the TCP Bridge screen, e.g. 10001 (or whatever port you've decided on e.g. 10002 etc - if 10001 is already in use).
  2. In your application, go up to 1 click away from where it will try to connect.
  3. Without closing that application, open your web browser and log in to pnpscada, and select the modem/etherpad entity.
  4. Go to the TCP Bridge menu item, and enter a port number (default is 10001)
  5. Click the start button: the screen will update every few seconds and tell you whether it is busy connecting, the connection is closed, or the connection is open (running). Wait for the connection to be open (running).
  6. Switch back to your application immediately, and perform the one last thing to make it connect. It is vital that this must be as quickly as possible after the connection was opened as reported by the TCP Bridge screen on pnpscada, since the connection can timeout. (The timeout is different depending on your specific connection's parameters - it is an artifact of your network topology - some connections don't time out quickly, but some closes if they remain inactive for e.g. a minute)
  7. Your application should now be happily connected to and communicating with your device, as though it was connected to it over a LAN.
  8. Depending on your type of connection, you may have to increase your timeout settings on your application, e.g. I know the Landis and Gyr ZMD can have timeout issues: the meter itself also has timeout settings (for getting profile on IEC instead of the IEC readout - if on GPRS you have to set the timeout setting in the meter between the first and second transaction longer, otherwise it times out and give you the IEC readout before it has a chance to ask for the profile); but if you can read the meter with pnpscada normally, at least you can know that your meter is set up ok, then it is just your application's timeout settings you have to worry about. There are sometimes more than one timeout setting to worry about, e.g. generally between transactions, between specific transactions (e.g. IEC readout timeout); and inter byte delay, just to name the most common few.

Please log in to post a comment