- Posts: 30
- Thank you received: 0
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
- Connections, Reconnections, COM/DCOM
- State that causes the ReadItem to block indefinitely
State that causes the ReadItem to block indefinitely
17 Apr 2014 15:08 #1859
by dlbrown06
Replied by dlbrown06 on topic State that causes the ReadItem to block indefinitely
I noticed now that if I just end the server_runtime.exe process the application begins to work again.
Please Log in or Create an account to join the conversation.
17 Apr 2014 12:34 #1858
by dlbrown06
Replied by dlbrown06 on topic State that causes the ReadItem to block indefinitely
Well, this is a web application without a service running so it's stateless so it wouldn't allow a subscription option. So everything is being done with read/writes.
Please Log in or Create an account to join the conversation.
17 Apr 2014 10:49 #1857
by support
Replied by support on topic State that causes the ReadItem to block indefinitely
Sorry, one more question: Are you also using subscriptions in your code (SubscribeItem, SubscribeMultipleItems), or just reads and writes?
Thank you
Thank you
Please Log in or Create an account to join the conversation.
16 Apr 2014 12:54 #1852
by dlbrown06
Replied by dlbrown06 on topic State that causes the ReadItem to block indefinitely
1. Restarting the EasyOPC service works as expected. It stops and starts back up quickly.
2. Service is the only checkbox checked
3. The Kepware OPC Server includes a 'Quick Client' that allows you to read/write to the kepware opc tags.
4. In order to get the application running again I need to end the Kepware opc server exe from task manager (server_runtime.exe). I've turned off the apache service, (which in turn disableds the PHP interpreter process) and the easyopc services and the kepware service is still locked to a point that I need to kill the process.
The EasyOpc process actually appears to be running well, however I'm concerned that the COM object could be doing something to the Kepware process that could be causing it to lock up.
The web application would load a page and use AJAX calls to a php file that creates the COM and reads the tags then calls unset(COM) to destroy the object. This AJAX call is occurring nearly every second. Scaling this out further, there are 24 stations that could all be doing this at the same time. The COM object isn't setup as Isolated so it should be sharing the connect as I understand it.
Would you like more explanation of the implementation or is that enough to understand what is being done? Would there be a better way to implement using the COM object?
If the application and the implementation of the COM object is at fault, are there any steps I can take to diagnose the root issue?
2. Service is the only checkbox checked
3. The Kepware OPC Server includes a 'Quick Client' that allows you to read/write to the kepware opc tags.
4. In order to get the application running again I need to end the Kepware opc server exe from task manager (server_runtime.exe). I've turned off the apache service, (which in turn disableds the PHP interpreter process) and the easyopc services and the kepware service is still locked to a point that I need to kill the process.
The EasyOpc process actually appears to be running well, however I'm concerned that the COM object could be doing something to the Kepware process that could be causing it to lock up.
The web application would load a page and use AJAX calls to a php file that creates the COM and reads the tags then calls unset(COM) to destroy the object. This AJAX call is occurring nearly every second. Scaling this out further, there are 24 stations that could all be doing this at the same time. The COM object isn't setup as Isolated so it should be sharing the connect as I understand it.
Would you like more explanation of the implementation or is that enough to understand what is being done? Would there be a better way to implement using the COM object?
If the application and the implementation of the COM object is at fault, are there any steps I can take to diagnose the root issue?
Please Log in or Create an account to join the conversation.
16 Apr 2014 07:30 - 16 Apr 2014 07:30 #1848
by support
Replied by support on topic State that causes the ReadItem to block indefinitely
The symptoms actually point towards a problem within COM implementation on the application side - in this case, the PHP implementation(?). Here is why:
When any COM server (in this case, the QuickOPC) runs out-of-process locally (either configured as Local Service, or a Service), the COM/DCOM infrastructure watches its process. If the process terminates, any pending COM calls to that process (in your case, the EasyDAClient.ReadItem) return immediately, with an HRESULT (error=exception code) that indicates something like "RPC server unavailable". This works very reliably. So, if you say that you have restarted the EasyOPC service (which means it has to stop first), AND the ReadItem call does not unblock at that moment, there is something very bad going on - but outside the component itself.
BUT, there are other things that seem to contradict or weaken what I wrote above:
- You said that restarting apache doesn't fix it. I do not know precisely how this works - is restarting apache basically supposed to restart the PHP interpreter process that runs your code and uses QuickOPC? If so, does it mean that the after restarting the apache, the NEXT call to ReadItem blocks again?
- Of course restarting the Kepware runtime should normally work. The fact that it does not means that either there is something wrong with it, or (but I can only speculate) the callback from the server may be blocked inside the client.
In order to move us a bit forward, can you please answer the following:
Thank you
When any COM server (in this case, the QuickOPC) runs out-of-process locally (either configured as Local Service, or a Service), the COM/DCOM infrastructure watches its process. If the process terminates, any pending COM calls to that process (in your case, the EasyDAClient.ReadItem) return immediately, with an HRESULT (error=exception code) that indicates something like "RPC server unavailable". This works very reliably. So, if you say that you have restarted the EasyOPC service (which means it has to stop first), AND the ReadItem call does not unblock at that moment, there is something very bad going on - but outside the component itself.
BUT, there are other things that seem to contradict or weaken what I wrote above:
- You said that restarting apache doesn't fix it. I do not know precisely how this works - is restarting apache basically supposed to restart the PHP interpreter process that runs your code and uses QuickOPC? If so, does it mean that the after restarting the apache, the NEXT call to ReadItem blocks again?
- Of course restarting the Kepware runtime should normally work. The fact that it does not means that either there is something wrong with it, or (but I can only speculate) the callback from the server may be blocked inside the client.
In order to move us a bit forward, can you please answer the following:
- Restarting the EasyOPC service - does it work as expected, i.e. does it restart itself without problems from the Service Manager, or do you have to somehow terminate it by force?
- Are you absolutely sure that the PHP code is actually using the EasyOPC as a service? Cannot it be registered as in-process server at the same time? Please run the EasyOPCOptions app, select the "System Parameters" tab, and verify how the settings in the "COM Registration" group look like.
- What do you mean by "The OPC Client connects and reads tags fine"? Is it referring to a use of some other OPC client, connecting to the Kepware server at the time the problem occurs?
- (the questions to the effects of restarting apache - above)
Thank you
Last edit: 16 Apr 2014 07:30 by support.
Please Log in or Create an account to join the conversation.
15 Apr 2014 20:13 #1846
by dlbrown06
State that causes the ReadItem to block indefinitely was created by dlbrown06
We have an application that we are communicating to a torque controller via Kepware OPC. It is a web application and there are 24 different torquing stations in which there are computers with firefox accessing the web server built with apache and php.
After a few hours (sometimes more or less) of running without issues, the web server becomes unresponsive. I've tracked this down to the line of code that is blocking the application:
When if I try to restart the Kepware server runtime service, it won't stop. To get them back going I have to end the server_runtime.exe process and then start the runtime again. Then everyone works again for another couple ours.
I have that line of code wrapped in a try/catch, but it just blocks there until the browser times out and there aren't any errors in the windows logs.
It's also important to note that everything seems fine in Kepware. The OPC Client connects and reads tags fine and the Kepware Configuration application seems responsive. That is wh yI'm starting to think there might be something going on in QuickOPC.
Any ideas what might be going on or what I can do to diagnose / fix? I've been unsuccessful in my attempts to be replicate this locally.
After a few hours (sometimes more or less) of running without issues, the web server becomes unresponsive. I've tracked this down to the line of code that is blocking the application:
$item = $conn->ReadItem('', 'Kepware.KEPServerEX.V5', $tag);- Restarting apache doesn't fix it.
- Restarting easyopc service (yes, installed as a service) doesn't fix it
When if I try to restart the Kepware server runtime service, it won't stop. To get them back going I have to end the server_runtime.exe process and then start the runtime again. Then everyone works again for another couple ours.
I have that line of code wrapped in a try/catch, but it just blocks there until the browser times out and there aren't any errors in the windows logs.
It's also important to note that everything seems fine in Kepware. The OPC Client connects and reads tags fine and the Kepware Configuration application seems responsive. That is wh yI'm starting to think there might be something going on in QuickOPC.
Any ideas what might be going on or what I can do to diagnose / fix? I've been unsuccessful in my attempts to be replicate this locally.
Please Log in or Create an account to join the conversation.
Moderators: support
- Forum
- Discussions
- QuickOPC-Classic in COM
- Connections, Reconnections, COM/DCOM
- State that causes the ReadItem to block indefinitely
Time to create page: 0.066 seconds