gazroobari
Member
Hi,
I have a driver which reads tags from SLC 500 & ML 1400 devices.
I've been asked to put the ML 1400 under load, not so much to assess speed but more to see how stable the comms is.
Accordingly, we've set up a host running my driver (basically, an embedded Java controller) talking across the local network to the ML 1400. The driver loops round, reading about 200 tags in the N7 integer data file.
Everything seems to start well. My driver counts and displays total read requests and I can see this figure going up at about 2000 tag reads per minute. No errors are seen.
Then, after maybe a range of 15 to 30 minutes, the driver starts to report that the socket between itself and the PLC has been terminated. In a sense, I 'm handling this and recovering: comms is re-established including management of session ids, forward open, connection ids, and so on, and the read requests appear to resume -- for a while.....
However, as time goes on, the comms stutters more and more, and by far the majority of the driver's time is spent recovering comms rather than reading tag values.
Is there any way of analysing why the socket might be going down, but why it can take upto half an hour of normal activity before this failure pattern starts to emerge ? I'm not suggesting my code is foolproof -- it probably isn't -- but just wondering how to narrow this problem down.
Any thoughts, clues, tips gratefully appreciated.
I have a driver which reads tags from SLC 500 & ML 1400 devices.
I've been asked to put the ML 1400 under load, not so much to assess speed but more to see how stable the comms is.
Accordingly, we've set up a host running my driver (basically, an embedded Java controller) talking across the local network to the ML 1400. The driver loops round, reading about 200 tags in the N7 integer data file.
Everything seems to start well. My driver counts and displays total read requests and I can see this figure going up at about 2000 tag reads per minute. No errors are seen.
Then, after maybe a range of 15 to 30 minutes, the driver starts to report that the socket between itself and the PLC has been terminated. In a sense, I 'm handling this and recovering: comms is re-established including management of session ids, forward open, connection ids, and so on, and the read requests appear to resume -- for a while.....
However, as time goes on, the comms stutters more and more, and by far the majority of the driver's time is spent recovering comms rather than reading tag values.
Is there any way of analysing why the socket might be going down, but why it can take upto half an hour of normal activity before this failure pattern starts to emerge ? I'm not suggesting my code is foolproof -- it probably isn't -- but just wondering how to narrow this problem down.
Any thoughts, clues, tips gratefully appreciated.
