# Generic TCP IP Driver

**URL:** <https://forum.inductiveautomation.com/t/generic-tcp-ip-driver/11497>\
**Category:** General Discussion\
**Created:** [April 13, 2016, 4:19am UTC](https://forum.inductiveautomation.com/t/generic-tcp-ip-driver/11497 "2016-04-13T04:19:48Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![ian](https://avatars.discourse-cdn.com/v4/letter/i/bb73d2/32.png) [@ian](https://forum.inductiveautomation.com/u/ian)\
**Post date:** [April 13, 2016, 4:19am UTC](https://forum.inductiveautomation.com/t/generic-tcp-ip-driver/11497/1 "2016-04-13T04:19:48Z")

</div>

I am using [Generic TCP IP Driver](https://github.com/chi-Ignition/generic-tcp-driver/releases) on [Github](https://github.com/chi-Ignition), created by [chi](https://inductiveautomation.com/forum/memberlist.php?mode=viewprofile&u=6393).

In my project, I have server-PLC (Siemens S7-300) communication with the following connections:

> [@](#):
>
> Server \<--A--\> Network Switch/Router \<--B--\> PLC

Now, let say we call the connection between Server and Network Switch/Router as A, and connection between Network Switch/Router and the PLC as B

I am doing some tests on the system, and one of them is to physically disconnect connection B and monitor the result from the Ignition Gateway and Ignition Designer.

> [@](#):
>
> Server \<--A--\> Network Switch/Router \<-XXX-\> PLC - disconnected physically, the cable plugged

Now, usually, the Generic TCP/IP driver shows the number of connected device on certain connection like this in the Gateway -\> OPC-UA -\> Devices -\> Status Column:

> [@](#):
>
> 3 devices connected

Throughout my testing, I notice that when I disconnect and reconnect connection B five possible things may occur:

1. The number of device connected shown in the Gateway -\> OPC-UA -\> Devices -\> Status Column, sometimes - and not always, is increased by 1 upon re-connection, though there is no actual new device connected:

> [@](#):
>
> 3 devices connected -\> 4 devices connected

1. Likewise, when a device is disconnected, it, sometimes and not always, does not reduce the number of connected devices:

> [@](#):
>
> 3 devices connected -\> 3 devices connected (no change)

1. When the device is disconnected, the tag in the Ignition Designer still shows DataQuality as good (!) though the actual connectivity is missing.

2. When connection B is reconnected, if case 1 does **not** occur (that is, the number of connected device does **not** increase), then we cannot get updates from the device anymore!

3. When I use multiple ports to refer to the exact same devices (for the device could configure multiple connection ports) which originally show the same number of connected devices (say, 3), and then if I test the connection and re-connection, the increment/decrement behaviors are **not consistent** among the ports. That is, one port may have incremented connection:

> [@](#):
>
> 3 devices connected -\> 4 devices connected

While the other port remains:

> [@](#):
>
> 3 devices connected -\> 3 devices connected (no change)

And when that occurs, the port which does not increase the number of device connected can no longer communicate with the device.

* * *

I did not seem to encounter those issues when I tested without using direct connection

> [@](#):
>
> Server \<--C--\> PLC

What could be the reason and how to solve it? Admittedly, the Network Switch/Router are connected to more than one devices. Could that cause those issues? How to solve them?

---

<div class="post-metadata">

**Author:** ![chi](https://avatars.discourse-cdn.com/v4/letter/c/0ea827/32.png) [@chi](https://forum.inductiveautomation.com/u/chi)\
**Post date:** [April 13, 2016, 6:07am UTC](https://forum.inductiveautomation.com/t/generic-tcp-ip-driver/11497/2 "2016-04-13T06:07:25Z")

</div>

Hi Ian,

did you set a ‘Connection Timeout’ in the device settings? A timeout in conjunction with periodical arriving data is the only way the driver can detect a broken connection.

Regards,  
Carsten

---

<div class="post-metadata">

**Author:** ![ian](https://avatars.discourse-cdn.com/v4/letter/i/bb73d2/32.png) [@ian](https://forum.inductiveautomation.com/u/ian)\
**Post date:** [April 13, 2016, 8:29am UTC](https://forum.inductiveautomation.com/t/generic-tcp-ip-driver/11497/3 "2016-04-13T08:29:07Z")

</div>

If we configure the Generic TCP IP Driver as server (listener), could we set the timeout?

---

<div class="post-metadata">

**Author:** ![chi](https://avatars.discourse-cdn.com/v4/letter/c/0ea827/32.png) [@chi](https://forum.inductiveautomation.com/u/chi)\
**Post date:** [April 14, 2016, 7:51am UTC](https://forum.inductiveautomation.com/t/generic-tcp-ip-driver/11497/4 "2016-04-14T07:51:24Z")

</div>

No, you are right. For the listener there is no timeout setting. In this mode the driver simply waits for incoming packages, there is no further connection monitoring. In fact this mode was intended to be used with simple devices like barcode scanners that do not use a permanent connection.  
Maybe i can add something in an upcoming version. In the meantime i suggest to use something like a heartbeat counter in a tag change script.

---

<div class="post-metadata">

**Author:** ![ian](https://avatars.discourse-cdn.com/v4/letter/i/bb73d2/32.png) [@ian](https://forum.inductiveautomation.com/u/ian)\
**Post date:** [April 15, 2016, 3:28am UTC](https://forum.inductiveautomation.com/t/generic-tcp-ip-driver/11497/5 "2016-04-15T03:28:51Z")

</div>

OK, thanks for your clarification - there isn’t really better clarification source than you!

I am looking forward for the upcoming version. In the mean time, I would just try to implement a workaround (such as heartbeat) like you suggested.

Thanks again!

---

<div class="post-metadata">

**Author:** ![chi](https://avatars.discourse-cdn.com/v4/letter/c/0ea827/32.png) [@chi](https://forum.inductiveautomation.com/u/chi)\
**Post date:** [August 28, 2016, 7:25pm UTC](https://forum.inductiveautomation.com/t/generic-tcp-ip-driver/11497/6 "2016-08-28T19:25:57Z")

</div>

I just uploaded a new release on [GitHub](https://github.com/chi-Ignition/generic-tcp-driver). There is now a timeout setting in server mode and a new UDP mode. Some bugs that affected multiple connections in server mode have also been fixed.  
Let me know if there are any problems with this release.
