I wondered if anyone has experienced timing issues/delays when writing data out continually?
I have a multithreaded app that has a separate thread for each OpenOPC.client object. Each object talks to the same RSLinx OPC Server but handles data for different topics (e.g, a thread for TOPIC1, a thread for TOPIC2 and a third thread for TOPIC3).
I'm experiencing random delays when calling the write function continually (calling it every half second currently, but even dropping down to every second doesn't seem to help). It sometimes takes 3-4 seconds to return which is an issue because nothing else is being written for that topic in the meantime. Because OpenOPC wraps all the send/recv stuff it's hard to see where/why the delay is occuring.
The delays are also sporadic. Sometimes the app can sit there continually sending out data for 5 minutes before it gets held up. Other times, it might happen after only ten seconds. Infact, it often happens on the first write call too.
I've tried many different application structures to try and get around this behaviour but ultimately it doesn't matter what I do, I still get calls to client.write that block for 3-4 seconds, randomly.
I noticed in the RSLinx gets some random errors in the Communication Events window, but I can't relate them to the delays. Looking at the logs, they appear at different times so it's hard to say whether they are related.
I should also add that I get this issue on both a large network (where my previous posts indicate the timing issues / failures I've had in relation to the network size) and on a small network (which hasn't ever suffered from the timing issues I've had previously).
I'm a little unsure where to go next in trying to solve this.
Any help would be greatly appreciated :)
Cheers.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
i dont think the opc protocol itself was ever meant to push data that frequently to the same device. pulling data is a different story.
anyway - this could have something to do with how you have your topics setup on the server. topics where the write command is set to be synchronized with the read command (on RSLinx this is called "optomize write packets"), you'll wind up with occasionally a write being held up because a read is scheduled for a half second later, so it'll do both bi-directionally at the same time rather than one after another.
irregardless, i always found it good practice to assume a +/- 1 second "slop" when writing.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I wondered if anyone has experienced timing issues/delays when writing data out continually?
I have a multithreaded app that has a separate thread for each OpenOPC.client object. Each object talks to the same RSLinx OPC Server but handles data for different topics (e.g, a thread for TOPIC1, a thread for TOPIC2 and a third thread for TOPIC3).
I'm experiencing random delays when calling the write function continually (calling it every half second currently, but even dropping down to every second doesn't seem to help). It sometimes takes 3-4 seconds to return which is an issue because nothing else is being written for that topic in the meantime. Because OpenOPC wraps all the send/recv stuff it's hard to see where/why the delay is occuring.
The delays are also sporadic. Sometimes the app can sit there continually sending out data for 5 minutes before it gets held up. Other times, it might happen after only ten seconds. Infact, it often happens on the first write call too.
I've tried many different application structures to try and get around this behaviour but ultimately it doesn't matter what I do, I still get calls to client.write that block for 3-4 seconds, randomly.
I noticed in the RSLinx gets some random errors in the Communication Events window, but I can't relate them to the delays. Looking at the logs, they appear at different times so it's hard to say whether they are related.
I should also add that I get this issue on both a large network (where my previous posts indicate the timing issues / failures I've had in relation to the network size) and on a small network (which hasn't ever suffered from the timing issues I've had previously).
I'm a little unsure where to go next in trying to solve this.
Any help would be greatly appreciated :)
Cheers.
Bump :)
i dont think the opc protocol itself was ever meant to push data that frequently to the same device. pulling data is a different story.
anyway - this could have something to do with how you have your topics setup on the server. topics where the write command is set to be synchronized with the read command (on RSLinx this is called "optomize write packets"), you'll wind up with occasionally a write being held up because a read is scheduled for a half second later, so it'll do both bi-directionally at the same time rather than one after another.
irregardless, i always found it good practice to assume a +/- 1 second "slop" when writing.
Thanks vspinelli, that's good to know. I'll have a look at splitting the topics and getting rid of the packet optimization.