Hello,
I am using a PUSR rs232 serial TCIP Server. I have the data formatted within the ignition device, and am not having any problems with this, but the device stops receiving data after a certain amount of time.
The ignition device remains connected but only works again after I restart the device or resave changes. I have tried to set the inactivity timeout, but it will lose data if a signal is received while it is restarting due to inactivity.
If your device can send more than one message in the poll rate for the tag group, then the TCP device will not be suitable for your application. You would need to use java sockets instead, with a long-lived listening thread. (Which has complications--search for that here on this forum.)
Get a Wireshark capture that includes comms leading up to, and including when it stops receiving, and then including an edit/save of the device to force it to reconnect.
I have a HMI with a serial output that plugs into the tcp rs232 device. The HMI does not receive any data. The device allows me to send a number of strings without going to sleep. I wait a while and it no longer sends data. Do you still think that I need a wireshark?
I'm just trying to determine if you're not getting data because it's no longer being sent, and you need to be looking outside of Ignition to figure out what the problem is, or if it's because at some point you receive some unexpected data outside of the TCP driver's message framing configuration, so it just starts accumulating or something.
without resetting the device, I used RealTerm software. this is what the data looks like:
28845,0,start ,16494261,13:39:48,02/02/26
28845,0,end ,16509368,13:40:14,02/02/26
28845,0,start ,16524381,13:40:40,02/02/26
28845,0,start ,16545594,13:41:16,02/02/26
There is definitely nothing wrong with my tcp server, this must be ignition.
Cool, let's see that Wireshark capture.
this is when i am sending data
since earlier I am sending a heartbeat script every 20 seconds, writing back to the device. We shall see if this works.
Post the capture file, not just a picture.
tab_inserter.zip (2.5 MB)
That's a text file with no useful information. Supply the .pcap or .pcapng file.
okay, I have now figured out how to do this after some trial and error.
Before I had restarted the device you could see nothing in wireshark. Once I restarted ignition tcp device, the data started to flow. I waited until it stabilized and recorded it in first file.
capture after restarting device 1.pcapng (3.5 KB)
Once I triggered the input to the TCP server that feeds the tcp device, you see data. I triggered it 4 times. Len= 44
capture during data trigger.pcapng (5.2 KB)
I see constant TCP duplicates acknowledgements. It seems to be stuck on seq=1.
Could this be part of the problem?
Probably not.
Your actual messages are terminated with carriage returns. Be sure you use that in your device configuration.
However, you have a bigger problem: you can get two messages in a single packet. This will cause the driver to lose all but the last message.
More than likely, your source device is not setting low-latency mode (aka disabling the Nagle algorithm) and buffering multiple messages.
You won't be able to process multiple messages per packet with the TCP device. You will need custom scripting with a java socket and a long-lived thread.
Okay, do you suggest I create an ignition support ticket to assist with this. I am not familiar yet with this?
Support != training. Search the forum, have a try, ask here when stuck.
You can open a support ticket to get a more thorough confirmation of my diagnosis, or perhaps help manipulate the device to make it behave better. But they aren't going to write custom socket code for you. You'll find a bunch of material here on the forum, though.
You need to leave the capture running until this happens...
The capture you posted just has 4 successful TCP packets from the device.
The point of the capture is to prove that the device is sending data and Ignition is ignoring it.
When it ignores it, I see no communication whatsoever
So... Ignition isn't ignoring it... the device isn't sending anything.
