Sign in to follow this  
Followers 0
dcalderonv

.net OPC Client PRIMER

9 posts in this topic

Hello Masters. This time I need to develop a "simple" application that reads some data from a MS SQL DB and then writes some parameters to specific plcs. Fortunately, all the plcs are AB so I have thought the easiest way is to install RSLinx in the application computer and through OPC write the parameters into the plcs. It would be great if any of you could give some advices about the first step or where to start. The application is to be written in .NET C# or VB, so i need some libraries in order to acces RSLinx whether using OPC or DDE. Any help will be appreciated and thanks in advance. CaldeRon Inc.

Share this post


Link to post
Share on other sites
Here's a good thread with a sample at the end to get you started http://forums.mrplc.com/index.php?showtopic=12381

Share this post


Link to post
Share on other sites
Thank you again. There is a lot of information there to get started! best regards. Daniel

Share this post


Link to post
Share on other sites
Not a problem. Be sure to come back and let us know how it turns out

Share this post


Link to post
Share on other sites
Hello. After a few reading at all the information you gave me, I have found that the best way, is to use a library called RSIOPCAUTO.DLL which is installed in the PC with RSLinx. From all the examples seen, I can find some of the classes and methods this library has. But Id rather to get some sdk or document that explained with more detail this library. Does anyone know something about that? Thanks again

Share this post


Link to post
Share on other sites
Hi, TW has already pointed you in the right direction about how to get started with OPC but here are some things to think about. 1. .NET developers should seek to implement and deploy 100% fully managed solutions. COM add-ons should only be used when a 100% managed .NET solution is not available. The OPC Automation solution is not a fully managed .NET solution. It is based on COM and carries the limitations and pitfalls of implementing a COM solution, including using setup utility to package application, ensuring core dlls are installed, avoiding dll conflicts, and installation to Windows\System32 directory. 2. OPC solution requires DCOM and Windows configuration. 3. A lot of people in the A-B PLC world think Linx is the only connectivity solution, when there are numerous other third party solutions available. You mentioned "Fortunately, all the plcs are AB so I have thought the easiest way is to install RSLinx in the application computer and through OPC write the parameters into the plcs." However, just because all PLCs are AB doesn't mean you need to use RsLinx, and OPC is not the 'easiest' solution. Ultimately, you will wind up with a more complicated, expensive, and unmanaged solution using OPC Automation rather than a fully managed .NET solution My company offers a fully managed solution that allows you to bypass using OPC and Linx altogether. The product is called ASComm.NET. Regards, Automated Solutions http://www.automatedsolutions.com

Share this post


Link to post
Share on other sites
Thanks AS. I think for now, I am ok using RSLinx and its opc library. anyway Im going to look your products and I will ask you if I had any further question. Best regards. Daniel.

Share this post


Link to post
Share on other sites
Good luck on that documentation search. The OPC Foundation gives away a reference OPC client implementation. It is "free" but only if you are an OPC Foundation member. This also refers to the documentation for the library...hence your problem. Virtually every OPC server out there usually gives away a compiled version of the same library with their software and the SDK is identical. So collecting documentation for any of them is almost as good as having the original, even if you don't/can't pay for the OPC Foundation membership. Since the OPC Foundation is very tight about releasing any of their documents to the general public (that's how they make their money), needless to say, you aren't going to find anything more than examples of how to use the libraries. It's sort of like dealing with the "documentation" for say the Microsoft ADO libraries and even worse with their older kin. If you follow the example templates, everything works (usually!). There are also several OPC client vendors who claim that their library is much easier and simpler to work with than the reference OPC client. I'm a bit dubious because with everyone I've ever seen, you get a bunch of syntactic sugar coating. The reference OPC library is for the most part, a procedural interface akin to the older Microsoft database libraries. The syntactic coating merely wraps those calls in an object-like interface. You can change "writevalue(name, value)" into "object=OPC.object(name)", then "object.value=X" followed by "object.send". It makes the procedural interface "look" object-like but actually ADDS keystrokes to the project in the end because it replaces a one-step interface with a three-step one. Reading is similar in nature except that it may auto-update the value (no explicit object.read commands necessary). Taking the sales speak out of it and putting it in plain English: At the current time, OPC is only implemented in COM which is the old ActiveX style object model in Windows. It's a major hassle and essentially for all intents and purposes, dotNet is the NEW object model and thus takes several steps to avoid making it easy for you to use the older COM libraries (never mind MFC). The fundamental problem is that within the dotNET world, you have to somehow suck in an object system that is just as big (bigger actually) as dotNET in order to use even the simplest COM object. It isn't easy to do and the results are usually not worth it if you can avoid doing it at all. In fact you'd probably be better off writing a simple server of your own design to interface to the PLC's in say VB or C++ which can freely communicate in a protocol that dotNET can easily understand such as HTTP. That keeps all the dual personality ugliness at bay and provides a simple upgrade path in the future if/when RS-Linx provides the new OPC interface (OPC-UA) which will be much easier to grok directly via dotNET. With PLC-5 and SLC (not sure about Micrologix), you can talk to the PLC via either DF-1 or a modified form called "PCCC". With Contrologix (and with some overlap into SLC & Micrologix), you can communicate via CIP protocol. Whether you use OPC, the Linx "C" interface, or even the old DDE protocol (please don't...there are lots of issues with that one), the underlying protocols are the ones I just mentioned. An OPC server (driver) gives you a single unified programming interface for PLC's of any brand and model. Due to the licensing nature of the OPC standards themselves, anyone writing OPC compliant drivers is almost forced into charging for them. AB sort of "gives away" a hobbled RS-Linx under the assumption that you are buying their other software anyways. You can find copies of software and documentation to directly talk to AB PLC's freely available on the internet. For instance, Ron Gage's library (and many variants of it) works extremely well with PLC-5's and SLC's. On the Contrologix side of things, there are also several libraries. In fact I'm not 100% sure but I think that the ODVA gives away a reference design for Ethernet/IP. I know that at one time I came across it and a couple simple google searches should turn up one. If you are going to be dealing 100% with AB PLC's, I'd also recommend ditching the OPC route and use the direct drivers because troubleshooting OPC in itself is not much fun for the reasons I outlined. In addition, you will have a two-step debugging process (is it an OPC problem? Or a program problem?) Eliminating OPC eliminates an entire extra communication interface from the project.

Share this post


Link to post
Share on other sites
Paul, thanks for your advices. I think Im not good enough to try to develop an application that comunicates directly to the AB. I dont even understand all the facts youre talking about COM, and ADO. (sorry) But certainly I dont understand what is the difficult to use RSLinx OPC Automation Interface. I have found some information in RSLinx Help that explains their SDK and it is not difficult. So, why not to use them? Thank You.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0