Professional OPC
Development Tools

logos

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.

high CPU usage in PHP, using ReadMultipleItems, ToString

More
12 Oct 2010 12:14 #111 by steveh
I leave this note to close the thread from my perspective. The approach of moving to event based processing has been wholly successful. With more than two hundred separate tags being monitored as events, there is no significant CPU usage, even when the change rate is quite high.My application using QuickOPC to interface into real world OPC servers is now operating in a production implementation, and I am about to roll it out over all the OPC interface machines in our portfolio.Thanks for your help.

Please Log in or Create an account to join the conversation.

More
01 Oct 2010 14:39 #107 by support
The $sinkinterface parameter should be a string "DEasyDAClientEvents", and nothing else. PHP will look up this interface in the type library - that's why it has to be a specific name. The documentation still refers to this as _IEasyDAClientEvents; some tweaks had to be done for it recently to work within PHP.
The actual name of the class passed in the $sinkobject parameter should not matter, as long as it implements the right event handler function(s) with the right parameters.

Please Log in or Create an account to join the conversation.

More
01 Oct 2010 14:04 #106 by steveh
Yes, The OPC connector is the server equivalent.I have implemented subscriptions in my real world environment and they seem to be working well. No sign of high CPU usage so far. I will monitor it in periods of high event rates to see if there is any trace of CPU usage rising.Whilst adapting the events handling code into my existing structures, I noticed something that doesnt seem quite right. In your example, you use "DEasyDAClientEvents" as a class name and use that name to define the $sinkinterface in com_event_sink(). If I change that class name to say "MyEvents" it stops working, until I change only the $sinkinterface parameter of com_event_sink() back to "DEasyDAClientEvents", when it starts to work again.Is this an anomaly, or am I misunderstanding the purpose of the $sinkinterface value?

Please Log in or Create an account to join the conversation.

More
01 Oct 2010 09:36 #104 by support
Yes, if you have long-living CLI code that can use the subscription, and you are only interested in value changes and the values do not change rapidly, then using the subscription is generally the best way to go - and the amount of value accesses will be lower, hopefully getting rid of the CPU usage problem.
I assume that "OPC connector" is the OPC server your application is connecting to. I cannot really imagine how it could impact the CPU usage of your PHP application in the way described, besides things like maybe some special data types may cause PHP to do more work? - but that doesn't seem to be the case either. This is not to say that it is not happening - one just needs to have a reproducible case to figure things out. If we are dealing with values such as floats, integers, strings, the code parts in question actually get their own copies - and those should be the same no matter whether they come from your OPC server, or let's say from our test/simulation server.

Please Log in or Create an account to join the conversation.

More
01 Oct 2010 00:39 #102 by steveh
Thank you very much for your event handling example. You are doing a lot of work on this for me (initially) and I do appreciate it.I will attempt to get your example running in my scenario and let you know if I am successful. My PHP implementation is non-traditional, and there is quite a lot of CLI activity that is not directly web request related. My "application" allows a permanently open web page with continuously changing content.In my scenario, using item change triggering to read values should result in a couple of orders of magnitude drop in the amout of $X->Vtq->Value method calls, so may reduce the abberant CPU usage to a level where it does not accumulate.Can you help me understand if it is possible for the real world OPC connector to impact PHP reported CPU usage through your QuickOPC-COM? I have checked and the OPC connector is not using much CPU or Ethernet bandwidth. Is it likely that calls to Vtq->Value are promulgating through QuickOPC-COM into code within the third party OPC connector?

Please Log in or Create an account to join the conversation.

More
30 Sep 2010 15:50 #101 by support
As to the subscriptions, I have verified that they are possible with PHP & QuickOPC-COM combination in principle, see www.opclabs.com/Support/Online... . I would not go that way now, however, because 1) one cannot directly make a useful web request handling code with it, and 2) if the CPU problem has to do with obtaining values from the objects passed, it's probably not going to be any better with the subscription.
I have attempted to reproduce your CPU load problem, but I was not successful. If you could provide an information that would help in this respect, I would resume the investigation, but otherwise I have to leave it as it is for now.

Please Log in or Create an account to join the conversation.

More
30 Sep 2010 06:21 #94 by support
It appears that you are right. What you pointed to now is what I was looking for in my research - and could not find it! I have to thank you. I will verify whether this indeed works between QuickOPC-COM and PHP, and prepare an example for you.
The interfaces in QuickOPC-COM were designed so that they are usable from wide range of hosting languages and environemnts - which is good, but on the other hand, it increases the amount of examples and support knowledge needed to cover all these hosts - I hope you understand.

Please Log in or Create an account to join the conversation.

More
30 Sep 2010 06:13 #93 by steveh
That is disappointing. I was hoping that was whathttp://php.net/manual/en/function.com-event-sink.phpwas for.I am in the process of setting up another real world OPC server interface using a server from a different source. It will take some time. I will report back on whether the CPU usage problem occurs when connected to the new server.

Please Log in or Create an account to join the conversation.

More
29 Sep 2010 19:15 #92 by support
I have done some research just recently, and my conclusion is that PHP as a host for QuickOPC-COM does not allow subscriptions natively. This is because in order to consume COM events (IConnectionPoint/IConnectionPointContainer), the host has to expose some COM object with the callback interfaces, and to my knowledge PHP is not capable of this. One would have to "simulate" the events by polling for them, which is not going to help performance-wise, it's more or less a coding style thing.
[EDITED: THE ABOVE STATEMENT IS NOT CORRECT, SEE LATER POSTS. PHP CAN CONSUME COM EVENTS, AND QUICKOPC-COM DOES WORK IN SUCH SCENARIO]
I will still have a look at what could be causing the high CPU usage.

Please Log in or Create an account to join the conversation.

More
29 Sep 2010 14:49 #89 by steveh
I have tried the Vtq->Value method. The CPU usage increases at a slower rate (~30%) for the same number of tags and request frequency, but it still rises to the same order of usage.Perhaps I should try subscriptions. Can you give me some sample code to make this happen in PHP?

Please Log in or Create an account to join the conversation.

Moderators: support
Time to create page: 0.055 seconds