01 July 2004
Massaging OPC is necessary sometimes
Jonas Berge (SMAR) addressed Greg Potter's (Azimuth-Solutions) problems in developing OLE for process control (OPC) over a wide-area network to consolidate operations of two pipeline terminals.
Potter said there was almost no information returned to the application (in this case, the operator interface) by the application program interface; hence the diagnostic information presented to the operator interface application was extremely limited, and third-party tools were necessary to observe what was going on within the communication system.
Said Berge, OPC reports several error codes for problems with the OPC server as a whole, as well as a different status for each item (tag). It is also possible to check the overall OPC server state.
Truth be told, not every OPC server out there is well implemented, and some of them may not propagate the diagnostics information. Different OPC clients have different abilities when it comes to displaying this information; some simply do not show you this information even if it is available in the OPC server.
When it comes to human-machine interface (HMI) software, his choice is Iconics Genesis, because it has the best implementation of OPC he has seen in an OPC client. If a value is bad, an invalid character automatically indicates this. The indication can be in a different color too. One doesn't have to write scripts to make it happen. When one hovers with the mouse above the faulty tag, the tool tip bubble will show the detailed OPC status. In the past he used another HMI that did not do this, and it was indeed frustrating.
There are more than twenty different error codes defined for an OPC server to indicate problems with the server to an OPC client, plus more than half a dozen distributed component object model (DCOM) error codes.
A good OPC client will show the error messages to the user, so the user knows something is wrong with the OPC server, rather than leaving the user in the dark.
Similarly the OPC client must show *** or some other invalid character instead of the value, so the user does not mistake the value as valid. The technology is good, but many implementations are less than satisfactory.
OPC also includes capabilities to propagate error messages from the underlying application process in the monitored device. For example, it does not just catch communication errors, it also nails application errors that might involve a range check or mode check having failed in the programmable logic controller.
Nicholas Sheble edits the Networking & Communications department. Write him at nsheble@isa.org. Write Jonas Berge at jberge@smar.com.sg. Write Greg Potter at greg.potter@azimuth-solutions.ab.ca.
Contribute to or monitor the Controls Manufacturing Community List from whence this discussion came at controls@isa-online.org.
Return to Previous Page
Read questions answered by our experts or join the email list.
