Register    Login
 
Professional OPC Development Tools
And Services
 
 
SupportOnline Forums
 
Links: Related Pages
 
Links: Related Services
 
Links: Related Support
 
Links: Related Resources
 
Online Forums

Technical support is provided through Support Forums below. Anybody can view them; you need to Register/Login to our site (see link in upper right corner) in order to Post questions. You do not have to be a licensed user.

OPC Labs team is actively monitoring the forums, and provides answers as soon as possible. For your convenience, we have also assembled a Frequently Asked Questions page.

Please do not use the Contact page for technical support.

HINT: You may use the Search feature (magnifier icon below) in the forums to locate the information you need. You can also search our entire Web site (the search box in the upper right corner of every page).

 
 
SupportSupportDiscussions (re...Discussions (re...QuickOPC-ClassicQuickOPC-ClassicQuickOPC-COM  QuickOPC-COM PHP CLI hangs on Ctl+BreakPHP CLI hangs on Ctl+Break
Previous Previous
 
Next Next
New Post
 9/9/2010 5:14 AM
 

I am evaluating QuickOPC-COM in a PHP environment. Generally it looks very good and I want to use it in anger - but:

I have a PHP script running as a CLI instance in a XP command shell. The script is happily reading and displaying a dozen values as a ReadMultipleItems call every half second in an infinite loop.

Unfortunately, when I stop the script with a Ctrl+Break or a Ctrl+C the shell just hangs indefinitely and does not return to the prompt.

Many other scripts I have used in PHP CLI do exit in a controlled manner with a Ctrl+Break. This is the first time I have had this problem, and it is the first time I have used QuickOPC.

Can you think of any reason why a Ctrl+Break would hang the shell? Perhaps something in the runtime closure?

Hope you can help. This is the last hurdle before a purchase.

New Post
 9/9/2010 7:53 AM
 

Thanks for your post.

This precise problem is new to me, but there is a known issue that is very similar and has very likely the same root cause. It happens when Ctrl+Break or Ctrl+C is pressed from within a Windows Script Host running e.g. VBScript or JScript that is using QuickOPC-COM, AND the component is registered as COM in-process server. This situation is a "deadly mix" that creates a requirement that is very difficult, if possible at all, to resolve, because the component has background-running threads that can be in ANY state when this asynchronous signal is sent - and they all need to gracefully shut down in a coordinated manner. I have been trying to resolve it for some time without success.

There may be a workaround, though. Simply use the out-of-process option (Local Server). To do so, run the EasyOPC-DA Options utility, and on the System Parameters tab, uncheck the "COM Registration: In-process server" box, and make sure that the "Local server" box is checked, as on the attached picture.

If for some reason this does not help, I may have another try at resolving the core reason, but as I explained, there is a great deal of complexity in it.

New Post
 9/9/2010 4:39 PM
 

Thanks for the quick response. Always a good sign.

Running as a Local Server seems to have solved the problem. I can now Ctrl+Break and the prompt returns. Very good.

Can you point me please to some words on the real differences between running in-process, as a local server, and as a service? When I use this software in anger it will be operating in an environment where the calling application is running as a service, with nobody logged on to the computer. My original thought was that I should run the EasyOPC runtime as a service, but that option was greyed when I started playing. Is it possible to test it as a service?

New Post
 9/10/2010 12:25 AM
 

Regarding the differences in types of COM servers, this is covered in the Concepts document (http://www.opclabs.com/LinkClick.aspx...) under "COM Registration and Server Types", and the specific chapter is also online here: http://www.opclabs.com/onlinedocs/Con....

The In-process server options runs the component inside calling application's process, as a DLL. The Local server and Service options run in a process separate from the calling app. The Local server's process lifetime is controlled by the DCOM infrastructure only (it is started or stopped depending on whether any objects are needed from the component), whereas with the Service you also get the usual control capabilities available for Windows services, including various startup types: Automatic, Manual, Disabled, etc.).

When your calling application is a service, I recommend to register EasyOPC-DA component either as In-process server , or as a Service. The reason why the Service is greyd out initially is explained in the article I referred to; you basically need to run

eopcdal /Service

Previous Previous
 
Next Next
SupportSupportDiscussions (re...Discussions (re...QuickOPC-ClassicQuickOPC-ClassicQuickOPC-COM  QuickOPC-COM PHP CLI hangs on Ctl+BreakPHP CLI hangs on Ctl+Break

 
 
 
 
 

 
 
 
 
Home|Services|Products|Purchase|Downloads|Support|Resources|Company|Contact
Copyright 2007-2012 by OPC Labs Terms Of Use Privacy Statement May 20, 2012