# High Speed TCP Driver **URL:** \ **Category:** Ignition\ **Created:** [October 18, 2021, 4:04pm UTC](https://forum.inductiveautomation.com/t/high-speed-tcp-driver/52062 "2021-10-18T16:04:40Z")\ **Posts on this page:** 16\ **Page:** 1
**Author:** ![nicholas.robinson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nicholas.robinson/32/22188_2.png) [@nicholas.robinson](https://forum.inductiveautomation.com/u/nicholas.robinson)\ **Post date:** [October 18, 2021, 4:04pm UTC](https://forum.inductiveautomation.com/t/high-speed-tcp-driver/52062/1 "2021-10-18T16:04:40Z")
We work with shipping diverters that send out TCP messages that are the disposition for each package. At first we started with the TCP driver available in Ignition but even with 25ms polling, have determined it is not the appropriate driver because message counts always come up short. When testing with the python socket library there is the following call that can specify a buffer size: ```auto socket.recv(1024) ``` This method can capture all messages. Streaming the data this way, we can clearly see the problem is that messages arrive at nearly the same time so polling will not work, the only way to capture the data is to read from a buffer. This then presents the challenge of how to deploy in Ignition because we want the socket instance, once connected to stay alive and project scripts, tag change scripts, etc. are not the place for this. We are imagining a module that once the socket connection is made, it sticks that connection object in a hashmap and makes the receive call available with a script function like this: ```auto data = system.tcp.getData("Instance Name") ``` Such type of module also seems needed to close the socket connection properly. Does anyone else on the forum have a practical example of how they have acquired high speed TCP data? We are looking at this module, if nothing else, to get clues on how to write our own module: > **[GitHub - chi-Ignition/generic-tcp-driver: A universal tcp client/server...](https://github.com/chi-Ignition/generic-tcp-driver)** > > A universal tcp client/server driver for the Ignition(R) OPC-UA server. - GitHub - chi-Ignition/generic-tcp-driver: A universal tcp client/server driver for the Ignition(R) OPC-UA server. Thanks, Nick ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [October 18, 2021, 4:10pm UTC](https://forum.inductiveautomation.com/t/high-speed-tcp-driver/52062/2 "2021-10-18T16:10:38Z")
For high speed TCP data that you want to bring into tags the Managed Tag Provider may be a better fit than a driver for the OPC UA server. > **[ignition-sdk-examples/managed-tag-provider at master ·...](https://github.com/inductiveautomation/ignition-sdk-examples/tree/master/managed-tag-provider)** > > master/managed-tag-provider This is the same thing the MQTT modules use, though they aren’t exactly high speed. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [October 18, 2021, 5:21pm UTC](https://forum.inductiveautomation.com/t/high-speed-tcp-driver/52062/3 "2021-10-18T17:21:06Z")
I open java sockets, monitored with a background thread, spawning additional threads for accepted connections if appropriate. I avoid python sockets like the plague. The listening thread(s) can publish the received data to memory tags or cached jython structures. I keep track of running threads (and caches) in a persistent dictionary, using system.util.getGlobals() for Ignition versions where it is truly persistent, and using system.util.persistent() otherwise (from my LifeCycle module). In particularly demanding cases, I have the listening thread simply parse into messages, which then are stuffed into a LinkedBlockingDeque(). Or converted to runnables in a custom thread pool. ---
**Author:** ![nicholas.robinson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nicholas.robinson/32/22188_2.png) [@nicholas.robinson](https://forum.inductiveautomation.com/u/nicholas.robinson)\ **Post date:** [October 18, 2021, 10:52pm UTC](https://forum.inductiveautomation.com/t/high-speed-tcp-driver/52062/4 "2021-10-18T22:52:48Z")
I suppose when you say java sockets you are referring to this? ```auto import java.net import java.nio ``` If so, does this mean you are doing this in a start up and or shut down script, or a module? ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [October 19, 2021, 12:39am UTC](https://forum.inductiveautomation.com/t/high-speed-tcp-driver/52062/5 "2021-10-19T00:39:15Z")
Yes, `java.net` and/or `java.nio`. No module (unless you count LifeCycle for certain Ignition versions). Just jython. With all of the critical code in one or more project script modules. The beginning of the script module manages persistence of the primary thread(s), interrupting the old version(s) and replacing it (them). Calling into the module from a gateway startup script is sufficient, even if that function is do-nothing. Simply calling it will cause the top level of the script to run, starting/replacing the background. A timer script that pulls statistics out of your cache for monitor purposes would also suffice. ---
**Author:** ![nicholas.robinson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nicholas.robinson/32/22188_2.png) [@nicholas.robinson](https://forum.inductiveautomation.com/u/nicholas.robinson)\ **Post date:** [October 23, 2021, 6:31pm UTC](https://forum.inductiveautomation.com/t/high-speed-tcp-driver/52062/6 "2021-10-23T18:31:48Z")
We ended up going this way: > **[GitHub - Freeno83/buffered-tcp-module: Ignition module that allows for...](https://github.com/Freeno83/buffered-tcp-module)** > > Ignition module that allows for buffering of incoming TCP messages - GitHub - Freeno83/buffered-tcp-module: Ignition module that allows for buffering of incoming TCP messages Having it as a module makes startup, shutdown, and status monitoring quite convenient. When the read call is made, it reads everything from the buffer and returns it as a comma separated string. By doing this we stopped missing messages and there is no need to drive it faster than 1 second, because the incoming messages are buffered. Thanks for all the help and advice. Nick ---
**Author:** ![Joe\_Chlimoun](https://avatars.discourse-cdn.com/v4/letter/j/54ee81/32.png) [@Joe\_Chlimoun](https://forum.inductiveautomation.com/u/Joe_Chlimoun)\ **Post date:** [March 24, 2022, 11:18pm UTC](https://forum.inductiveautomation.com/t/high-speed-tcp-driver/52062/7 "2022-03-24T23:18:43Z")
Hi Kevin, Just curious, why would you say the Managed Tag Provider is better than an OPC driver? I’m trying to find distinctions between the two before I go too far down a rabbit hole, and you seem to indicate that a Managed Tag Provider would perform better. Is that because data is duplicated when making an OPC driver (one OPC tag managed by the driver, then an Ignition tag managed by the standard tag provider)? Or it just that the high speed nature of this use case would needlessly burden the OPC server? I need to pull in a whole lot of UDP data and before reading your post I was leaning towards an OPC driver. ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [March 24, 2022, 11:50pm UTC](https://forum.inductiveautomation.com/t/high-speed-tcp-driver/52062/8 "2022-03-24T23:50:12Z")
Managed Tag Provider is a more direct route into Ignition. So yeah, you have duplication of data, plus you have OPC UA subscriptions “in the way” of getting your data into Ignition. The way they work is not ideal if the thing you care about most is getting values as fast as possible. In OPC UA subscriptions publish at one interval while the monitored items belonging to them sample at their own interval. Those items can have a queue as well, which allows you to sample very quickly and deliver batches of changes at a slower interval. All of this is great for the kind of scale you see with OPC UA connections, but not as great if you just want to ingest a value and display it on your screen in, say… sub-50ms times. ---
**Author:** ![Alex\_Guyer](https://avatars.discourse-cdn.com/v4/letter/a/a4c791/32.png) [@Alex\_Guyer](https://forum.inductiveautomation.com/u/Alex_Guyer)\ **Post date:** [August 18, 2023, 7:20pm UTC](https://forum.inductiveautomation.com/t/high-speed-tcp-driver/52062/9 "2023-08-18T19:20:39Z")
Hello Kevin, I believe the linked drivers from this thread will be a good solution to a problem I'm having. I have been unable to find installation instructions. To install any of the linked modules from Github that are in this thread it does not appear it's as easy as importing the .modl file. Do you have any reference material? ---
**Author:** ![Andy\_Lam](https://avatars.discourse-cdn.com/v4/letter/a/db5fbb/32.png) [@Andy\_Lam](https://forum.inductiveautomation.com/u/Andy_Lam)\ **Post date:** [January 29, 2024, 10:44pm UTC](https://forum.inductiveautomation.com/t/high-speed-tcp-driver/52062/10 "2024-01-29T22:44:32Z")
Hi Nicholas, I'm experiencing the same issue as this forum post you have created. But the buffered TCP module package doesn't have installation instructions. Could you provide some guidance on how did you go about installing this module? Regards, Andy ---
**Author:** ![Matrix\_Engineering](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/matrix_engineering/32/19781_2.png) [@Matrix\_Engineering](https://forum.inductiveautomation.com/u/Matrix_Engineering)\ **Post date:** [January 29, 2024, 10:51pm UTC](https://forum.inductiveautomation.com/t/high-speed-tcp-driver/52062/11 "2024-01-29T22:51:01Z")
I haven't used this myself, however; there is a .modl file in the device-build folder, [https://docs.inductiveautomation.com/display/DOC81/Installing+or+Upgrading+a+Module](https://docs.inductiveautomation.com/display/DOC81/Installing+or+Upgrading+a+Module) > ---
**Author:** ![Andy\_Lam](https://avatars.discourse-cdn.com/v4/letter/a/db5fbb/32.png) [@Andy\_Lam](https://forum.inductiveautomation.com/u/Andy_Lam)\ **Post date:** [January 29, 2024, 10:58pm UTC](https://forum.inductiveautomation.com/t/high-speed-tcp-driver/52062/12 "2024-01-29T22:58:43Z")
Apologies, I should have elaborated previously. I tried to move the .modl files in the respective directory (C:\Program Files\Inductive Automation\Ignition\user-lib\modules), restarted the Ignition service but the module did not appear in OPC Device Connections. I tried interrogating the XML files that are throughout the folders - there are clear linkages to multiple property files and repository callouts. So, I thought I try moving the complete folder package over but that also did not work. ---
**Author:** ![Matrix\_Engineering](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/matrix_engineering/32/19781_2.png) [@Matrix\_Engineering](https://forum.inductiveautomation.com/u/Matrix_Engineering)\ **Post date:** [January 29, 2024, 11:02pm UTC](https://forum.inductiveautomation.com/t/high-speed-tcp-driver/52062/13 "2024-01-29T23:02:52Z")
As per the first link I provided, you don't copy over a module, you install a module: ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/6/f/6f4223e5cc70b9aaf311c8149f4c47e92a0b2ff8.png) ---
**Author:** ![Andy\_Lam](https://avatars.discourse-cdn.com/v4/letter/a/db5fbb/32.png) [@Andy\_Lam](https://forum.inductiveautomation.com/u/Andy_Lam)\ **Post date:** [January 29, 2024, 11:06pm UTC](https://forum.inductiveautomation.com/t/high-speed-tcp-driver/52062/14 "2024-01-29T23:06:50Z")
Apologies, I completely missed the link. Looks like this is the missing piece. Thanks for support! ---
**Author:** ![nicholas.robinson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nicholas.robinson/32/22188_2.png) [@nicholas.robinson](https://forum.inductiveautomation.com/u/nicholas.robinson)\ **Post date:** [January 29, 2024, 11:25pm UTC](https://forum.inductiveautomation.com/t/high-speed-tcp-driver/52062/15 "2024-01-29T23:25:00Z")
Just adding so it's clear and this applies to any module. Whenever you don't have that ".modl" file you do have to build and sign it. I think somehow there are already build modules there so you can probably use them. Typically, a module needs to be signed. If you are using an unsigned module for development purposes, there are some gateway settings needed to make that possible. Many of those things are described below. As alluded to, how to "do modules" is not really fully written down anywhere and once you go through the process a few times it becomes a lot clearer. [How do you create your own MODL file - Module Development - Inductive Automation Forum](https://forum.inductiveautomation.com/t/how-do-you-create-your-own-modl-file/51562/8) Nick ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [January 29, 2024, 11:49pm UTC](https://forum.inductiveautomation.com/t/high-speed-tcp-driver/52062/16 "2024-01-29T23:49:50Z")
> [@nicholas.robinson](#): > > As alluded to, how to "do modules" is not really fully written down anywhere and once you go through the process a few times it becomes a lot clearer. I'll just briefly call out, though it's by no means comprehensive: > **[Module Development with the Ignition SDK Course at Inductive University](https://www.inductiveuniversity.com/courses/elective-studies/module-development-with-the-ignition-sdk)** > > The Ignition SDK opens up Ignition to all kinds of user/organization extensions and customizations. This course will introduce you to the basic foundations of Ignition SDK module development, from ground zero upward. And our documentation team is actively working on improving the SDK docs: [NEW Ignition SDK Programmer's Guide](https://forum.inductiveautomation.com/t/new-ignition-sdk-programmers-guide/81903)