Device Connection / Inactivity Timeout

We are running Ignition V7.7.4. I have a project where I am interfacing with a Denso RC7 controller. The controller is setup up as two TCP Devices. I am communicating to two ports, 5002 and 5003. The read and write tags of both ports are CRLF terminated and the data they contain are ASCII strings.

The first issue I have is that whenever I download a user program change to the Denso controller it will lose communications with Ignition. The “Is Connected” tag for the ports show connected, however, there will be no reading or writing of the ports taking place. This concerns me as there is no “visual” clue that there is any communication problem. To re-establish the ports I had to go to Configure/OPC-UA/Devices/Device Setup on the gateway, disable and then re-enable the device. This was a very cumbersome process. I have since created buttons on my screen and use system.device.setDeviceEnabled(device,boolean) to cycle the device enabled and re-establish the port connections. A question, is there a way to see the status of the device enabled such as a “system.device.getTagValue()”? What I did works just fine but I would like to be able to look at the Device Enabled status.

The second issue I have is is with the Configure/OPC-UA/Devices/My Device/Inactivity Timeout. The first thing I tried in response to the loss of communications after downloading a program change to the Denso controller was to put a value (10000) in the Inactivity Timeout field. This worked as far as Ignition disconnecting and reconnecting the ports autonomously after I did a program change, but it created another issue. After re-establishing the port connection, Ignition randomly, every ten minutes to an hour, executes the disconnect/reconnect. Whenever Ignition disconnects the ports it does something that the Denso controller does not like. I get a fatal error in the controller. The fatal error is one that is issued if a port is sent a “null” string or some type of data and no termination character. This is bad as the Denso controller has to be rebooted. In the Denso I even programmed a “port tickler” that writes the ports and “flip-flops” data bits every few seconds to try to keep the Inactivity Timeout happy. I can see the time stamp of the port read tag and the data updating, but I still randomly get the fatal error. If I put a 0 in the Inactivity Timeout to disable it this problem goes away and I am left with my first one.

Ports disconnecting because I have download a program change are one thing. The real world scenario that I have a concern with is this:
Ignition is the machines HMI. The Inactivity Timeout is disabled as described above. For whatever reason (sunspots :laughing: ) the ports get disconnected. Ignition does not know, the “Is Connected” is still true. The Denso controller has a Port Watchdog Timer Fault because it has not received an answer from a data pack it sent. The Denso stops its operation and goes Home. The operator walks up to the machine and sees the robot is sitting there doing nothing, and the HMI says “RUNNING”.

Hi! Welcome to the forums!

Can you use something that is always changing? Sending a ramping integer, or turning a boolean on and off. These “Heartbeat” methods can be monitored for comms health.


As I mentioned, I have a “port tickler” programmed in the Denso that writes to both ports approximately every 3 seconds. Inside the data that is sent is a “bit” that is toggled at each send just to make sure there is a change in the actual data. I have a watchdog timer in the Denso for a response to the sent data. The Denso programmatically knows there is a problem if it doesn’t get a response back. I guess I could program a watchdog timer inside of Ignition for receiving data too.

If I monitor the Ignition port read tag and the time stamp is changing and I see the toggling of the “bit” every time the Denso sends, why is the Inactivity Timeout even occurring? Either I’m missing something or there is a problem with Ignitions Inactivity Timeout.


As I mentioned, I have a “port tickler” programmed in the Denso…[/quote]

Gaah! Sorry 'bout that. Didn’t fully read the second issue. Or maybe I did and things started to fall out of my head… :blush:

But my thinking may still apply, unless IA has any better info. I would try watchdogging the data, setting the Inactivity Timer back to 0 , and reset the connection that way. May be an ok workaround until IA can chime in.