PLCs and OPC

Join Date
Nov 2007
Location
Illinois
Posts
75
I am looking at a project where the spec reads "The OPC driver must be embedded in the PLC" not as "a driver running on a data collection PC". I'm guessing that they want to have different PLCs talking to each other without using intervening computers.

Other than maybe PC based control, where the PLC is "inside" the PC running OPC, I've never heard of such a thing. Has anyone else heard of this concept? Is there a standard (as opposed to PC-based) PLC that runs OPC?
 
I wonder who's PLC that spec what written about. Must have cost a lot of lunches.
 
Hi,
The RedLion Panelviews and RedLion DataStation+ units have built in OPC servers. Not sure if either qualify as a "PLC" for your customers spec. But they don't seem to be PCs either.
BD
 
I think that maybe they mean OPC UA ("Unified Architecture") which is a network based standard (totally based on ethernet).
http://en.wikipedia.org/wiki/OPC_Unified_Architecture
More specifically it is a standard for communication between devices, not just for communication between Windows software and devices which is the commonly used OPC DA.
In other words two PLCs should be able to exchange data with each other directly via OPC UA, without having to use a Windows PC as a go-between.
The only PLC that I know of that supports OPC UA today is Beckhoff:
http://www.beckhoff.de/english/twincat/twincat_opc_ua_server.htmhttp://www.beckhoff.de/english/press/pr1608.htm

There is also OPC XML which I think can be implemented directly on devices for excghanging data via XML. There are some HMI devices with this option (Siemens panels for example). But the performance should be quite bad.
 
OPCRTX.JPG
 
It is our duty to protect a customer from himself when they let morons write specifications. If they want a particular manufacturer, they should just say so.

Why involve OLE for Process Control if you don't have a PC? That's what OPC is for .... PC's.

I've seen some dumb stuff in specifications... mostly specs from government related projects.


I vote for the RedLion Data Station Plus to be considered a PLC.
 
Last edited:
Jesper,
Thanks for your detailed and precise explenation.

As far as I know Logix 5000 processors have built in OPC server, that's why you are able to pick up tags on line in PanelView Plus without actually creating them.
 
> The RedLion Panelviews and RedLion DataStation+
> units have built in OPC servers.

Well, they kinda do, in that we have a server in there that works with a PC-based proxy to provide an OPC interface. But the "panelviews" (cough!) and DSPs themselves don't provide a DCOM-type OPC server, which is what the OP might actually be looking for.
 
Jiri Toman said:
Jesper,
Thanks for your detailed and precise explenation.

As far as I know Logix 5000 processors have built in OPC server, that's why you are able to pick up tags on line in PanelView Plus without actually creating them.
I think that what you see is the integration that you have between the various RS products.
You have the same "effect" in a Siemens HMI panel - here you can browse the symbols in the S7 PLC, without it having anything to do with OPC edit: bad analogy, it is not the same. The feature is that the tag names are stored on the PLC. However, it it still not OPC.

Put it differently: How can I connect an OPC Client on a PC via DCOM for example to ControlLogix ? I would like to know, because then I could save a bit of money ;)
 
Last edited:
No, I'm pretty sure this isn't the case - a PV+ is pretty much a computer (with respect to this thread) and probably has drivers included. That doesn't necessarily imply that the Logix PLC does.

Jiri Toman said:
As far as I know Logix 5000 processors have built in OPC server, that's why you are able to pick up tags on line in PanelView Plus without actually creating them.

I tend to agree with Killer that this is probably a spec written by a customer who didn't know any better. I guess a Red Lion device qualifies here as much as (or maybe more than) anything else I can think of.

Embedded devices can implement the OPC UA spec to varying degrees. They (OPC UA comms) connect via an exchange that's very similar to SSL, albeit XML based, then can go to different modes to transfer data (binary or XML format). It looks like the link Jesper provided was for an OPC UA driver that goes for a PC to connect to the Beckhoff PLC. I'm not 100% sure, though. In any event, PLCs and other embedded devices will certainly be able to "natively talk OPC UA" in the near future. It's a pretty cool model and thought regardless of vendor choice.
 
surferb said:
It looks like the link Jesper provided was for an OPC UA driver that goes for a PC to connect to the Beckhoff PLC. I'm not 100% sure, though.
It is indeed not clear at all, but I interpret it as that the OPC UA Server connects to the Beckhoff PLC and Serves the data from there to other devices.
The OPC UA Server comes in two versions for Windows and Windows CE, and I think they are intended to be installed on the same Windows or Windows CE device where TwinCat resides.
It was released just recently, so there is not so much information about it, no manual for example.
 
I concur. One nice thing about OPC UA from a migration standpoint is that the OPC Foundation provides a backward compatible wrapper as part of the spec. In other words all of your OPC DA applications should work fine with the new UA servers.

JesperMP said:
It is indeed not clear at all, but I interpret it as that the OPC UA Server connects to the Beckhoff PLC and Serves the data from there to other devices.
The OPC UA Server comes in two versions for Windows and Windows CE, and I think they are intended to be installed on the same Windows or Windows CE device where TwinCat resides.
It was released just recently, so there is not so much information about it, no manual for example.
 
I sat through some Codesys overview training last week.

The statement was made that Codesys has an OPC server embedded in it, so those hardware targets that run a Codesys compiled binary have an OPC server as part of the configuration. The Codesys web site confirms that
http://www.3s-software.com/index.shtml?en_OPC&sitesearchmatch=opc#sitesearchmatch

Note the claim:
The CoDeSys OPC-Server V2.0 is able to communicate with all controllers programmed with CoDeSys. It complies with the requirements of the OPC standard V2.0.

I pressed the issue by asking whether or not an OPC server was a licensed run time extra, and the claim was that it is not.

I think Beckhoff uses Codesys as its development platform/runtime software, does it not? If so, it might place in this category.

If the Codesys statement is true, then the spec could be a lock-out spec.

Dan
 

Similar Topics

Hey guys, last week I posted part 1 of a series of OPC UA articles in Node-RED. That article covered some important concepts of OPC UA and how...
Replies
8
Views
3,906
Hi; I had designed an HMI in RS View32 Works and an SLC-5/05 had connected with that HMI via direct driver. Now as per requirement, i need to...
Replies
4
Views
2,768
Hi forum! I have 2 PLCs that are not connected inbetween, but just to OPC server. There was setup, where PLC-1 was connected to OPC and to...
Replies
19
Views
5,056
Hi, Suggest me the the OPC server which supports various PLCs and also be accessible to read/write data through third party software or scripts...
Replies
14
Views
6,938
We have an upcoming software project that will be coded into a ControlLogix (Allen Bradley) PLC. Some of the data items we would like to send...
Replies
15
Views
5,606
Back
Top Bottom