TCP periodic polling and data handling

Module Development
1

I am new to Ignition. Just trying to write a custom driver to use TCP connection, periodically poll for new data, and handle new data updates.

I have already used the TCP driver that is part of ignition to connect to my TCP Server. I can connect, write to it and receive data back.

In the Message Tag associated with the TCP driver I can see my data. How do I access this programmatically?

I can write to my TCP server using the Writeable Tag through the Ignition GUI. How do I programmatically do this periodically?

From what I can tell I should be able to use the TCP module then make my own Custom handler module? Or should I write a completely custom TCP module that can access all these Tags and do the polling?

2

Use a 'value changed' script on the message tag. Make a script library and call the function in that change script.

for example:

def valueChanged(tag, tagPath, previousValue, currentValue, initialChange, missedEvents):
	TCPdriver.newMessageRecieved(currentValue.value)

On sending requests, it will be best to use Gateway Scripts to send data to that TCP device. You can make it event based or just periodic.

1 Like
3

Thanks for the reply. Where do you find these driver methods? such as TCPdriver.newMessageRecieved

I am looking and do not see this documented anywhere. I am guessing there is also a similar method for TCPdriver.newMessageSend?

4

The TCP driver is not an open source item. You won't find its classes and methods documented because IA doesn't expect/want anyone to drill inside it.

You would start from the OPC UA device sample in the github examples repo and write all the java comms you need from scratch.

5

Ok so from my first post "From what I can tell I should be able to use the TCP module then make my own Custom handler module? Or should I write a completely custom TCP module that can access all these Tags and do the polling?"...

You are saying I should just write my own TCP driver? I should just be able to make an OPC UA device that can setup TCP connection and then handle the sending and receiving however I want?

6

You have two practical options:

  1. Work from the existing TCP driver and what you have access to inside the standard Ignition environment via scripting.
  2. Start totally from scratch and implement your own TCP communication stack and integrate it into Ignition as a module.

You're describing an option 3 that's sort of in the middle of the two in theory, using a module to dive deeper in the internals of an existing module. In practice, this is actually going to be substantially more complicated than either of the other two options.

1 Like
7

Yes. Leave the tag part to the platform. Provide OPC data items that a user can connect to tags.

1 Like
8

I am setting up my own TCP Client driver using the OPC UA device example. I added a new class and call it to connect to my TCP server.

This may seem like a silly question but how do I know what is going on in my class? like how do I print or log and where do I see those logs? I do not see any logging in the OPC UA device example.

I tried this System.out.println("Just connected to " + socket.getRemoteSocketAddress()); but if it does print somewhere I do not know where it is printing. I looked at the console in the design studio.

I just can not seem to find easily accessibly information on the ignition platform.

9

Writing to standard output goes to the wrapper log files on the Ignition Gateway. Using a Logger instance will go to both wrapper log files and the logs in the gateway web interface.

You’re in over your head being new to Ignition and diving into the under-documented module SDK at the same time.

1 Like
10

This line shows how to create a Logger you can log with: ignition-sdk-examples/GatewayHook.java at 4c4552578fec89082a207cca68f36d27e920c7d1 · inductiveautomation/ignition-sdk-examples · GitHub

11

I am realizing that. I would of much rather wrote our own App from scratch than ever use Ignition but was not my decision.

thanks for feedback. I check out the example you linked.

12

I wonder why. :man_shrugging:

{ I hope you weren't expecting affirmation for that comment on IA's own forum. }

13

How did you go from new Ignition user to deciding you need to write a custom module? Was this advice from support?

14

We have a software department at our company that usually writes our GUIs. We go into high security level places so none of our stuff can be connected to the internet. SO our GUIs are not web based. We had a customer want a web based application. I can throw one up in react in no time but we had a person with almost zero software background pick this so he could implement it.

Now that we need the Ignition web app to interact with our system they brought in the Software team. So we need to make a driver that allows that interaction. So I have never used Ignition until developing this driver. I am not sure anyone advised it from your side.

15

Ok, I'm just trying to go back to step 0 here and make sure this is the right thing to be doing. Developing a module is not part of the standard Ignition user experience, so it's pretty unusual right from the start.

It's possible the standard TCP driver could be made to work, but without knowing more about the protocol it's hard to say. The most common thing for Ignition to communicate with are PLCs via some native protocol we support or by OPC UA; the capabilities of the TCP driver are fairly limited. It's not meant to be build-your-own generic protocol thing, it's mostly meant for receiving periodic data from barcode scanners or scales.

Is there anything you can share about this protocol? Maybe a custom driver is the right move, or maybe it can be done via the existing driver, or maybe just from Ignition's scripting.

1 Like
16

So we are not interacting with PLCs at all in this scenario. We have a Server that runs all of our software. It has has a TCP server on it that can handle and commands needed for the system. It is a Get/Set Control that we custom made. So the data has to be pulled (Get) from it and then parsed or sent to it (Set). It is different variable to Get and Set every time so we need a handler that can interpret what has come in or is going out and update the relevant Tags.

17

Is it truly bare TCP, or a higher level protocol like HTTP or REST? Do you need a persistent connection, or can you just retrieve data at an interval and push data to it event-driven?

18

Yes it is bare TCP. We can retrieve on interval and push data event-driven, Correct.

19

We had a long discussion on connecting Ignition with external application thru TCP/IP sockets. Perhaps this link may be of some use !

2 Likes
20

I have created my own TCP driver starting with the OPC UA device example and modifying it. So thanks to your help and guidance on where to start. It seems to do everything I need of it.

I have now run into what may be an issue. I have been making and testing the driver with 20 Tags. Now that I am connecting it to our system we have many more Tags than that. When the UI starts it reaches out to our system for a list of the Tags and their data. It then creates and initializes the Tags.

Over a certain number of Tags and my periodic function I use for polling just stops firing. I can use the OPC Quick Client to write to my Tags and send that change over TCP to our system. So that continues to work. If I change something on my system side however I never get the update because the periodic polling stops being called.

Here is how a start my period in the onStartup function..
try {
deviceContext.getGatewayContext().getExecutionManager().register(getClass().getName(), TASK_NAME, this::poller, 2000);
logger.info("TCP module started.");
} catch (Exception e) {
logger.error("Error starting up TCP poller.", e);
}

I have been messing with it but so far not understanding why my period is stopping. Somewhere around 100/200 Tags this starts happening. We have many more Tags than that.