Clearly, their OPC communication must use DCOM. Consider two OPC applications that are installed on two PCs on two different Domains. Unfortunately, OPC developers have no programmatic control over DCOM, and are thus bound by DCOM’s limitations. But, when installed on 2 separate PCs, they use DCOM (Distributed COM) for the data exchange. When OPC applications are installed on the same computer, they use Microsoft’s COM (Component Object Model) technology to exchange data. Of course, standards-based communication is only half the task - the other half deals with the actual method by which the data moves across the network. No matter what the device is, data is always shared with an application in a standardized format.
#MONEYWELL APP SOFTWARE#
OPC (OLE for Process Control) standardizes data sharing between plant floor devices (DCSs, PLCs, analyzers, etc - OPC compliant are preferred) and software applications (such as HMIs, Process Historians, trenders, etc). It is in these setups that OPC can make use of new “tunneling” technology, which eliminates the biggest OPC headache for integrators: setting up DCOM.) Still, other designs call for the use of low-bandwidth or unreliable networks.
#MONEYWELL APP WINDOWS#
(The most common situation occurs when applications on different Windows domains must communicate with each other. But as OPC pours into mainstream acceptance, integrators like you may find configurations where OPC can be a hindrance to the panacea of plug-and-play application interconnectivity. OPC (OLE for process control) is the preferred communication standard for sharing process control data at all levels of the enterprise. OPC Tunneling may eliminate your Setup Headaches. I am again assumming that each server must be setup for its own list and human error might grow in this respect if work is not careful. Also, I know that there is a limit of about 800 items per OPC Server, thus we have to run multiple instances of the software if we have a requirement to push and pull more that this. I assume this because you state "stop start and change configuration." This tells me that the Honeywell does not serve up all its internal items and must be explicitly configured to serve up any entities that we might want to control via the OPC gateway. With the Honeywell OPC server, it seems that not only must we set the client up, but we must also set the server up as well. Am I wrong in this assumption? I know that with my back ground in Emerson's DeltaV, when the Software is installed it is simply a matter of connecting a Client to the system and moving forward. Once this is done then it seems that it must be configured and explicitly told what to serve out thru the OPC interface.
#MONEYWELL APP PATCH#
What I meant was that the OPC server seems to be a software solution that was developed sort of like a patch work interface and must be installed as another software on top of the DCS control software. What problems were faced when this solution was attempted?
Am I right to think that Honeywell developemnt is like this? Has anyone had to set this server up on an APP node and utilize the APP as a 3rd party OPC gateway?Īlso, looking at the OPC Foundation I see that the Honeywell OPC server has past our chosen OPC Client Interoperability Test, but I am wondering about actual implementations and a possible set of Lessons Learned from those projects. In my working with other OPC complient DCS system, namely the Emerson's DeltaV System, this server side development is fully ingrained in the software upon install. to map to the server variables, as well as from the Server side itself, i.e. It appears that thier OPC server is a Software solution that is not ingrained into the Control Software itself, thus it must have several levels of development, i.e.
Talking with Honeywell they state that this should be no problem and they have even taken the assignment to setup the OPC Server Side themselves. The question develops from our need to connect a third party Advanced Process Control system to the LCN. I have several questions concerning Honeywell's OPC Server and its functional successes in allowing 3rd party OPC clients to interface the LCN via Honeywell's APP Node.
0 kommentar(er)
