Using OPC

R

Thread Starter

Rakesh

I am aware of OPC details as I had read lots of stuffs abt it on OPC foundation site & also magazines but now I want to work on it. can anybody explain me how to start on it if I had downloaded opc server from matrikon site. Pls explain me how it works & communicates with client.

Thanks in advance.

Rakesh

 
Hi,

First, you will notice that there is a lot of white noise on the OPC subject out there. I guess this can be attributed to the Automation Industry incertitude on the standard. Is OPC a blessing or a headache?

OPC is first and foremost an automation system communication solution for the Microsoft™ operating system. This implies that you should get very familiar with COM, DCOM, ActiveX, OLE-Automation, and Microsoft-API before you can do anything with OPC.

You should get the OPC Foundation standard CD and please remember these points: The standard is still in evolution. Most of it was written for MS-Visual C++ and very little for MS-Visual Basic.

Are you interested in developing server side or the client side OPC solution?

You will notice that most of the free servers out there do not support the entire OPC interface. This is why server testing is very important before using it in your project. Use a server that is well documented or buy the support contract. Watch out for these OPC server restrictive licensing, they can a be serious drag.

There is some OPC developer tool available on the market. We have evaluated 2 packages for our project and unfortunately they were a disappointment. Actually one of the package was so full of bugs that it was a bigger challenge than the project itself. There is a serious vacuum here and I hope this will change soon.

On the client side you need to learn about COM interface and all this shebang. Don’t rush to an OPC DCOM (Distributed Common Object Model) interface to quick. You must consider how secure is your network before using OPC DCOM.

And finally, OPC is cool standard that is major improvement over DDE but…. It is much more complex than it is advertise and get ready to do some serious coding.

Good Luck.

P.S. It is still not clear how the OPC standard will face the new Microsoft COM+ technology and rules. I guess we should stay tune ; <)

Luc
 
D

D. C. Pittendrigh

Hi All

I would suggest a slightly different approach to your problem, decide what you want to acheive with the OPC server, then you will find it much easier to get appropriate assistance in your quest for knowledge.

I have used OPC servers for SCADA and in order to implement a SCADA system as a front end for a simulation package I use for testing PLC code. The
reason why I got involved with the second venture is because the results of the first on were so successful.

If you intend to create your own OPC server or write code intended to use OPC then I can't help you much, but to evaluate OPC there is a website
called technsoftware where you can download a trial server, client and browser, they are easy enough to install on a PC and you will be able to
change variables in the server and see the reaction in the client, you can use the browser to better understand the mechanism of OPC and if this isn't enough to whet your appetite then it isn't whettable.

Contrary to most urban legend the OPC client/server is easy to deal with but
there are a number of settings to be made to get most of them to work and you must be precise and make notes as you go along so that you can refer
back if you have problems later.

My first OPC client took 3 days to get set up and put through its paces. The first 2 1/2 days were trial and error which is due to personal
stubbornness, then I sat down, read the book and did it all again, right first time.

I set up an Intouch wonderware client and a Siemens CP1613 OPC server on industrial ehternet yesterday, it took about 3/4 of an hour from the
beginning to the end.

I have not spent to much time on COM and DCOM studying as I did not need to to get the applications running. DCOM is not neccessary for starters as you should run the client and server on the same PC to make the learning curve easier. DCOM is difficult to set up due to the security settings that are required on the server PC, this will require a set of MCSE books to deal with and I personally would not undertake it on any operating system other than WIN2K, I have tried unsuccessfully with NT and have succeeded with relative ease to get it working on 2K, primarily due to the availability of Applets for DCOM management in 2K

Good luck, it should be a fun voyage of discovery and well worth the effort.

Regard
Donald Pittendrigh

 
D
Luc wrote:
"Don't rush to an OPC DCOM (Distributed Common Object Model) interface to quick. You must consider how secure is your network before
using OPC DCOM. "

Luc,
I agree with the caution on DCOM, but for other reasons than security. I have 3 automated cells with multiple HMI clients accessing PLC's through a remote OPC Server. (which thus relies on DCOM) This has proven to be unreliable and once every couple of weeks the OPC server and HMI clients
lockup. We even had a heavyweight (trust me, I'm being polite and will spare his name and the names of the software vendors) from the OPC
foundation come to check it out. When he came to my site, one of his introductory comments was "anyone who tells you the problem is DCOM should be shot." Then 3 weeks later he decided it is probably DCOM and arranged for an engineer to come to our facility to set up some logging to isolate the source of the problem.

A few weeks ago we had an interesting scenario. Supposedly breaking the Ethernet connection between the clients and OPC server is a great test and one of the most difficult events to program applications to handle. When all the applications locked up though, all were very surprised to learn that breaking the Ethernet connection to the Server unlocked the applications. This connection is handled entirely by DCOM.

This technology is trying too much to be all things to all people and is neither properly designed nor mature enough for controls applications. An example of why I have this opinion is DCOM's timeout period after an error:
SIX MINUTES !!! That will supposedly NEVER change because it needs to be that long to allow for querying large remote databases. Also, apparently applications do not need to use the current version of the standard to be compliant, thus two compliant packages from two vendors may be using different versions of the standard. I can't prove that this is the problem, but the developer adhering to the latest version 2.x is frustrated that the much larger vendor is using the version 1x. If you're doing non-critical data collection, have fun.

Very soon I will spend over $4000 (part cost only) on just one cell to try a hardware/firmware solution to eliminate the need to use "remote" OPC. (and thus DCOM) I have not had problems with local OPC. If it works I'll end up spending a total of between $10,000 and $15,000 bypassing the need for DCOM. I believe Ford spent a huge sum of money paying to have a product by Intrisyn (sp?) developed to bypass DCOM. I don't know if it works but it's available and much pricier than my plan.

In fairness, I must add that I would not need to spend so much money if I were using more modern PLC's. (Omron C1000H) They are 13 years old (and
running like new) and need special adapters for protocol conversion. I compare it to putting fuel injection and electronic ignition on a '69
Mustang -- It's just not pretty. It will cost hundreds of thousands to upgrade so I can't justify it yet. They're still supported, still meeting our needs, and VERY reliable.

Dale

Honda Eq Staff
 
D

Dobrowolski, Jacek

Hi Rakesh,
To make use of OPC server you need :
1) any HMI/SCADA soft using OPC comms - the easiest way, all the comms programming work is already done for you;
2) office soft which is COM "aware" (like MSOffice) ;-) and supports any programming language (like VBA) - you can make use of OPC Automation component - as I recall it's for free at OPC Foundation site;
3) any programming language soft + or OPC Automation component or DLL wrapper.

How to communicate you can learn from the OPC specifications (there're examples inVB/C++).

Regards

Jacek Dobrowolski
Software Eng.

Automation Department
Secondary Division
ITM Poland Ltd.
26-600 Radom
ul. Warsztatowa 19a
POLAND
direct line: +48(48)3686341
fax: +48(48)3686101
 
Dale,

I can feel some battlefield experience in your reply and yes, I do suffer of the “programmer over-optimism syndrome” (POOS) ;<) .

>Dale wrote:
“This technology is trying too much to be all things to all people and is neither properly designed nor mature enough for controls applications. An example of why I have this opinion is DCOM's timeout period after an error:
SIX MINUTES !!! That will supposedly NEVER change because it needs to be that long to allow for querying large remote databases. Also, apparently applications do not need to use the current version of the standard to be compliant, thus two compliant packages from two vendors may be using different versions of the standard. I can't prove that this is the problem, but the developer adhering to the latest version 2.x is frustrated that the much larger vendor is using the version 1x. If you're doing non-critical data collection, have fun.”

Good point. Your are right, DCOM was not originally design for process automation application. It has a long history that started with IBM (RPC), then took a turn with the Microsoft DNA philosophy and so on. Microsoft push this technology for the middleware, ERP, and business logic community and not for the roughneck automation engineering crowd (this include your humble servant).

The “6 minutes” DCOM kill process instance is a very important point. It is a good feature in the world of distributed component, it avoid memory leak, and these awkward “dual instance of the same server object talking to the same client” moments. Although, in the world of process control, DCOM objects behavior can be considered as a lightweight technology.

We are in the business of high-energy accelerator and x-rays source. We use DCOM and OPC technology for operator HMI and part of database connection scheme. We write our own clients but lately we have purchased some commercial client component to speed up our design completion. We use an array of PLC systems like Allen-Bradley, Siemens, Modicon and Koyo (this is a long story). This situation gave us quite a challenge.

OPC/DCOM was for us a great solution but we have quickly realized that there is a big difference between a standard and its implementation.

First, we have notice that DCOM is very sensitive to network configuration. The topology of hubs, bridges, and switches is very critical. A good coordination between the automation I&C group and the network IT division is crucial. Beware of the well meaning IT manager that changes the DCOM configuration setup on a Domain server for some unknown reason…. ;<)…

A good network installation help us speed-up the initial DCOM/OPC connection and recovery after temporary link drop-off.

Then come the OPC server issue. Well… that is were thing get strange. In theory, OPC server are create by programmers that have a close relationship with PLC hardware manufacturers, understand the various communication buses protocols, and try to adhere as close a possible to the COM/DCOM and OPC standard. In reality things are different. OPC servers are not created equal.

Some of these servers create memory leak of the whazoo !. Even with the 6 minutes timeout. We have tested OPC servers with solid Microsoft approved development tools (memory leak checker and all) and found some surprise. Some of these servers don’t support (or poorly support) standard OPC interfaces and their methods.

On the bright side there are some of these pearl of OPC servers. They are well design and solid.

In general we had more problem with the OPC servers themselves than the OPC/DCOM technologies.

Finally, my biggest issue with OPC is the Custom Interface/ActiveX handler free for all. I hope the OPC Foundation will expand the standard to all Microsoft Program development tools. It shouldn’t matter that you use MS-J++, Delphi, MS-VB or Metrowerk CodeWarior. A Standard is concept that implies uniformity across the board.

In the end, OPC is way better than DDE in my humble opinion. OPC open doors to what you could not consider possible just few years ago with automation system communication.

I do agree with you, there is room for improvement with OPC and DCOM.

Thanks for your patience.

Luc Lessard
System Engineer
SLAC/SSRL
Stanford
 
D
Luc wrote:
>First, we have notice that DCOM is very sensitive to network
>configuration. The topology of hubs, bridges, and switches is very
>critical. A good coordination between the automation I&C
>group and the network IT division is crucial. Beware of the well meaning
>IT manager that changes the DCOM configuration setup on a Domain server
>for some unknown reason... ;<)

Nobody has mentioned the Domain Server (do you mean controller?) with regards to DCOM configuration to me yet. Not the Giant, not the little guys, not even the God of OPC himself. How does this play into the picture? From my standpoint, the most annoying thing about OPC is that it is so simple but leaves the integrator to configure DCOM with no instructions. DCOM is far from simple and it seems nobody want to touch it.

>Then come the OPC server issue. Well... that is were thing get strange. In
>theory, OPC server are create by programmers that have a close
>relationship with PLC hardware manufacturers, understand the various
>communication buses protocols, and try to adhere as close a possible to
>the COM/DCOM and OPC standard. In reality things are different. OPC
>servers are not created equal.

I agree. I haven't found an ideal one yet either. I have chosen Cimquest, not because it has no problems, but because the developer tends
to fix the problems soon after I find them. It's a tradeoff but by now I believe I have a broader, more refined product than other vendors have on
the market for my PLC. Other developers tell you to wait until their next build and then your bug still isn't fixed.

>Some of these servers create memory leak of the whazoo !. Even with the 6
>minutes timeout. We have tested OPC servers with solid Microsoft approved
>development tools (memory leak checker and all) and found some surprise.
>Some of these servers don't support (or poorly support) standard OPC
>interfaces and their methods.

I don't have personal experience with this, but it is my understanding from those who do have such experience that Microsoft development tools
are not ansii compliant and have a greater tendancy towards memory leaks than others like Borland. I'm sure the Microsoft lovers will ravage me for this and I can't defend it. I respect the guy who explained it to me though.

>In the end, OPC is way better than DDE in my humble opinion. OPC open
>doors to what you could not consider possible just few years ago with
>automation system communication.

If you have to compare it to DDE, then yes, it's a Godsend. I like to set standards higher and prefer to compare it to Modbus.

Dale
 
A

Alexander Lokotkov

> Nobody has mentioned the Domain Server (do you mean controller?) with
> regards to DCOM configuration to me yet. Not the Giant, not the little
> guys, not even the God of OPC himself. How does this play into the
> picture? From my standpoint, the most annoying thing about OPC is that it
> is so simple but leaves the integrator to configure DCOM with no
> instructions. DCOM is far from simple and it seems nobody want to touch
it.

The only reason for having any interactions with the Domain Server is to resolve the node names which are about to be used as a client or a server
station. There are lots of materials about tuning the DCOM. You might check out these:
http://www.iconics.com/Support/Whitepapers/Dcom whitepaper.pdfhttp://www.iconics.com/Support/Whitepapers/DCOM QuickStart.pdfThere are also some specific tools out there:
http://www.iconics.com/Support/AppNotes/DrDCOM.htm
> I don't have personal experience with this, but it is my understanding
> from those who do have such experience that Microsoft development tools
> are not ansii compliant and have a greater tendancy towards memory leaks
> than others like Borland. I'm sure the Microsoft lovers will ravage me
> for this and I can't defend it. I respect the guy who explained it to me
> though.

I am the Sun/Java lover, but our experience with the MS development tools for OPC development indicates no problem with memory leaks which have been induced by those tools. I think that C++ programming language forces developers to make bugs leading to a memory leakage.

Best Regards,

Alexander Lokotkov
Software Development Dept. Head
Fastwel, Inc., Russia
 
Top