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).
QUOTE(Automated Solutions @ Jan 1 2008, 09:27 PM) [snapback]63270[/snapback]
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 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.