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 
) 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”.
