That would be a "no", then. If you are using just time, then you aren't holding the trigger until Ignition responds. How do you know the "writing" part of your action doesn't occassionally take more than five seconds?
How many channels are you using in Kepware? I use Kepware for the Fanuc Focas protocol on some CNC machines. I originally had all of my devices under one channel, and I experienced heavy latency on several of the tags. I reconfigured it to use one device per channel and the lag disappeared. I haven't had any trouble since.
Might want to move the "Done" clearing to Ignition like pturmel said, it'll make it easier to avoid possible race conditions where the PLC keeps wanting to clear it and Ignition thinks it should still be on.
first for all, thx for all responses. I've checked the "done" signal and it turned out that only Ignition writes to this variable though, so sorry for the confusion. I've changed the poll rate to 1000 ms and it significantly improved the connection. So far we have not had any cases of communication suspension.
As you can see, xOK is set by PLC 90 ms earlier than WriteRequest. As I have no experience in programming PLC, I have some questions for you:
Is this 90 ms time constant? Or is it possible that, for example, the PLC processor will be overloaded and will send xOK later by several hundred milliseconds, so it will be later than WriteRequest?
Are the variables that go to the SCADA system through OPC Kepware queued in any way? We have set the cycle time in Ignition to 1000 ms and even though these variables are close to each other, in 99.9% of cases, xOK comes earlier than WriteRequest. But once in a while, it's the other way around, and isn't this related to my question number 1?