Online Forums
Technical support is provided through Support Forums below. Anybody can view them; you need to Register/Login to our site (see links in upper right corner) in order to Post questions. You do not have to be a licensed user of our product.
Please read Rules for forum posts before reporting your issue or asking a question. OPC Labs team is actively monitoring the forums, and replies as soon as possible. Various technical information can also be found in our Knowledge Base. For your convenience, we have also assembled a Frequently Asked Questions page.
Do not use the Contact page for technical issues.
- Forum
- Discussions
- QuickOPC-Classic in COM
- General Issues, Building
- OPC Read/Write issues in VS2005 C++
OPC Read/Write issues in VS2005 C++
What is taking the most time (2.5 seconds) are basically process context switches and data marshalling between your application and EasyOPC process. This happens every time you access objects from EasyOPC. For example, obtaining a properly-typed interface from a VARIANT, accessing a property (such as Exception or Vtq or Value) etc. There is nothing wrong with your code - it was our conscious decision to design the interfaces in this way. In COM automation, about the only more effective way would be to return directly arrays of the actual things you need, so that would make an array of values, array of timestamps, array of qualities, array of error codes, array of message texts etc. That is possible but gives a terribly looking code.
Fortunately, you can eliminate the above process context switches by using to in-process EasyOPC. To do so, open the EasyOPC Options Utility, and on the System Parameters tab, uncheck "Local server" and check "In-process server".
The downside of the in-process component is that in some environments and situations, it is difficult to achieve a shutdown that is properly coordinated with the host. Hopefully, since you are in C++, this should not be a blocking problem.
Regards
Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.
I understand that you are looking for better performance, so I plan to do more tests in order to see whether this can be improved further, in a hope that if they help with my test, they may be beneficial to your situation, too.
I know that your network is fast; have you, however, made a test where the OPC server and OPC client are both on the same machine, so that we have trusted information about whether the bottleneck has to do with the communication, or something else (performance of the client or the server)?
Can you please tell me which OPC server are you connecting to? I find it hard to believe that it does not support subscriptions. It would be very unusual (and clearly not compliant with OPC); in addition, I think that the server must at least "pretend" that it does support them, because we are calling functions that are related to subscriptions, and if they were failing, you would be getting error messages.
As you know, repeated reads are inefficient, so I am trying to figure out why we cannot go "the right way". The expected sustained throughput with subscriptions (locally) can be 4000 changes per second or more.
Instantiating unnecessary objects inside the loop is not particularly good, but I do not think it has a substantial influence in this case. I still suggest that you move the creation of EasyDAClient object outside the loop. I suppose that the times you are giving are just for the read method call (these other things should not be significant anyway, but should be ruled out in the timing nevertheless).
Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.
Ad 1. I am assuming that those 4.2 seconds are for 2nd and subsequent invocations of the method (the first invocation causes various startup tasks and can take longer than subsequent ones). If all invocations take so long, there might be various reasons for this. I do not want to enumerate them all here, so let's start with one, and if that is not the reason, we will continue investigating deeper. Please start by doing this experiment: Run the EasyOPC Utility, and on the OPC-DA Globals tab, under Client Parameters, change "Trocessing interval timeouts" from 50 to 150, and change "Topic processing total timeout" from 1000 to 5000. These are tunings that could help the performance with larger number of items. After making this change, press OK, and make sure that the EasyOPC process is not running (easyopcl.exe in Task Manager), so that when you start your application, it gets a chance to pick up the new values. Please repeat your measurements then and let me know the results.
Ad 2. The code in ReadMultipleItems example is not complete with regard to error handling. The proper approach would be to test the DAVtqResultPtr->Exception for null-ness. Only if it is NULL, the DAVtqResultPtr->Vtq is valid and can be accessed. If the Exception is not null, obtain IComException interface from it, and handle it, using fields such as Message and HResult. You will see an example of it in the example I will send for point 3 below. I will need to know the details of that exception (Message, HResult, ...) in order to tell you more about what is happening.
Ad 3. Please see this thread: www.opclabs.com/Support/Online... for example that writes multiple values and works.
Best regards
Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.
- Forum
- Discussions
- QuickOPC-Classic in COM
- General Issues, Building
- OPC Read/Write issues in VS2005 C++