Connecting Via OPC to Allen-Bradley PLCs

[Colt Hero]

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 back to our *proprietary* DCS for secondary display (the ControlLogix app will have local panels).

Previously, our proprietary DCS provided Function Blocks in its toolbox to communicate with PLC-5's and SLC's via a serial interface, but this functionality was never expanded upon and it is now gone (Controller hardware was 'upgraded' from 68000-based to PowerPC eliminating the serial interface).

So ... if we wanted to read the data directly from the PLC to the proprietary DCS Controller (via Ethernet) we would have to do what? Would we have to write an OPC-compliant piece of software to communicate with RSLinx?

Currently, the DCS Controllers use Ethernet to read live I/O from MTL PAC8000 Controllers. They also run some custom code that uses PI-API to push data up to PI Servers for archiving. On one particular Controller 'cluster', Wonderware is coupled as the front-end. I *believe* there is some OPC capability here in order to make this work. If this is true, is this specific to Wonderware, or could it be used for the PLC communications also?

I guess what I'm asking is: OPC is a standard, but you still have to write *specific* OPC interfaces for different clients or servers, correct??

FYI: The proprietary DCS Controller runs under Microware (a Unix variant).

 

[JesperMP]

If you can use OPC it is definitely the way to go.
It seems that in the past your system used some kind of "direct driver" and you cant use that any more for some reason.

To be clear.
The user application will be an OPC Client. Wonderware is an OPC Client for example.
In order for the OPC clients to communicate with the PLCs or other devices, there must be OPC servers for these devices. You get the OPC server from the same suppliers as the devices (f.ex. R.A.), or in some cases from 3rd party vendors (f.ex. Kepware).

OPC has until recently been a Windows-only affair. But the latest variant (OPC UA) is less Windows dependant. It may be possible that your proprietary DCS can be an OPC UA client.

The questions you should ask are:
How can the DCS communicate with devices in the field ?
OPC UA ?
Modbus TCP ?
Ethernet/IP (direct driver) ?
Serial DF1 via gateway ?

 

[JesperMP]

We are using OPC UA with Siemens, and I just assumed that R.A. (RSLinx) can also do OPC UA, but I am actually not sure about that. Someone else may elaborate.

 

[the_msp]

I don't know for sure if RSLinx does OPC UA, if it does not, Ignition by Inductive Automation have a OPC UA server for allen bradley and siemens PLCs over ethernet. Price? It's free.

 

[baldone]

If you need OPC UA you might need Factorytalk Gateway instead of RSLinx.

If I recall a 5000 tag Factorytalk Gateway was around $500 and 32000 tag was around $1100 so it is not to bad price wise.

On Edit....looks like it's only OPC DA.

 

[danatomega]

In the past, I have written such custom data / I/O monitoring programs in VB6 and VB.NET using Ingear drivers.

http://www.ingeardrivers.com/allen_bradley/allen_bradley.htm

They have a single use license for developing on a single system for ~$300

 

[JesperMP]

This is the important bit of information.

FYI: The proprietary DCS Controller runs under Microware (a Unix variant).

 

[TheWaterboy]

I was gonna say... 68000 to PowerPC, doesn't sound like a Windows machine.

 

[Archie]

AdvancedHMI has the tools to get the data to/from the ControlLogix that are very easy to use, but what about sending/receiving data from the DCS. Is the PI-API OPC compliant or work with .NET?

 

[Stephen Luft]

Greetings,

You may want to keep this in mind also. Kepware (for whom we distribute their products) offers a U-Con driver. U-Con stands for User Configurable. This is used when there is not a driver available as part of the current offering of device drivers. More information about it is available through the following link to our web site:

http://www.eternity-sales.com/kepware/ucon.htm

If you were to use both U-Con and Allen Bradley, you would want to consider the Manufacturing Suite. This pays for itself if you are in need of more than two driver suites. More information is available through the following link:

http://www.eternity-sales.com/Kepware/serverbundles-ms.htm

To learn more regarding the KepserverEX OPC server you can do so through the following link:

http://www.eternity-sales.com/Kepware/kepserverex.htm

If you have any additional questions, feel free to post, pm or you can email me through the link provided below.

 

[Ken Roach]

I generally recommend against using a PC as a middleware layer between controllers unless it's absolutely necessary, and even then I limit my recommendation to dedicated-purpose OPC mirrors like Mr. Luft mentioned can be done in Kepware.

The Wonderware installation is probably an OPC Client and the DCS implements an OPC Server. This is merely a guess, as it's been correctly mentioned that OPC-DA (Data Access) is the classic OPC technology that is Windows-centric.

It's worth looking into exactly how the Wonderware installation (is it modern, or NT-era ?) communicates to the DCS. But don't expect to wave an OPC wand and get data flowing.

 

[Ken Roach]

Colt, do you know what protocol the DCS uses to communicate with the MTL PAC8000 controllers ? Is this a SafetyNet application ?

Do you know if it implements Modbus/TCP as well ?

Modbus/TCP is as close to as "lingua franca" as you'll find in the industrial automation world, and the ProSoft Technology modules for the ControlLogix chassis are straightforward to configure and use.

 

[Colt Hero]

Archie:

The PI-API code runs in the PowerPC-based Controller; it's written in "C", runs under Microware's version of Unix (OS-9), and 'pushes' buffers of data this way up to the PI archive over Ethernet. It's a one-way street there.

Ken Roach:

The DCS uses Modbus protocol over TCP/IP Ethernet to communicate with the MTL PAC8000 Controllers. It's not a SafetyNet app (AFAIK ... at least I've never *heard* "SafetyNet" mentioned ever). However, the proprietary DCS software development environment "toolbox" was specifically 'upgraded' to include new Function Blocks to provide this functionality. The only thing configurable on the blocks is a node number, IP Address, Rack #, and Slot # on each function block to read a particular I/O module at the remote I/O cabinet(s). Each block reads 4 or 8 values to match the actual MTL hardware module. I think it's specific to MTL and probably could not be made to read a PLC, but I could be wrong. Big problem here is - I don't have access to the lowest-level code. That's proprietary and maintained by the owner. So I cannot change the development toolbox myself - and the owner won't either. The MTL I/O was changed out because the previous generation MTL I/O system (which worked via a high-speed serial interface into a "TransNet" board in each Controller) *finally* started experiencing module failures in the cabinets and there were no spares available anywhere. The owner basically does not support the software development environment.

Wonderware (Archestra) was introduced as a replacement for the (also proprietary) display system for one of the areas back in 2008. At that time, an OPC interface was written specifically to talk to the DCS. I don't know how this OPC interface works because the proprietary DCS has a very peculiar database that is nothing at all like a Wonderware Archestra database, therefore there has to be some kind of translation being done in between. Just to update the WW database requires export of an encrypted display information file from the proprietary DCS development environment, which is then de-crypted (using an offline tool also developed in 2008), which then allows a Galaxy import via a .csv file into a Historian Server running Archestra. It's kind of a pain in the butt (with all the undeploys and re-deploys), but it works (for the most part). Right now, the W/W Viewer machines are running under Windows 7 and their app servers are running some fairly recent version of Windows Server.

I agree that the Wonderware OPC interface is probably my best hope to talk to a PLC, but I'm not sure how. If the DCS W/W OPC interface is acting as a server (talking to a WW client), and the Rockwell OPC interface is *also* a server, does that mean I would need some kind of "double-client" middleware to transparently make the interface work?

I know you made reference to the 'magic wand', but that's kind of what I'm hoping for here ... and it *seems like* it should be possible. Putting a box in between the DCS and PLC is probably an acceptable solution in this case (at least initially) since we are only talking about secondary display of data.

 

[Ken Roach]

The Modbus/TCP (or possibly even Modbus RTU encapsulated over TCP) is the most intriguing possibility to me, because it's the one you can investigate and understand most easily and cheaply.

My guess is that there is a pre-defined set of Modbus holding registers that the DCS reads from the PAC8000 controllers. If so, you could very likely set up a ControlLogix interface to look just like the I/O modules from a PAC8000.

That would be my approach, anyhow. If you can gain access to the Ethernet network connection, you can add a tap or switch with a mirror port and get very useful information about the data exchange between the DCS and the PAC8000 with the free Wireshark protocol analyzer.

Your options for making a ControlLogix talk Modbus/TCP are fairly numerous: HMS or Digi or Prosoft or even a 1756-EN2T with a special user program running in the ControlLogix.

You are correct that to get an OPC Server to talk to another OPC Server generally requires a "bridge" or "mirror" middleware program. Kepware does a good one, as does Matrikon. But I've struggled to get well-documented OPC mirrors from the same company working right, and you're talking about a custom product with a complex import/export mechanism in the middle. I would be afraid to touch it for fear of being accused of breaking it.

 

[Colt Hero]

Ken Roach:

It'd be very nice if the MTL I/O Function Blocks could be connected to the PLC - and I'll give it a try, but I'll be surprised if it works. Wouldn't the underlying logic below those Function Blocks (which I cannot modify, BTW) be coded to speak MTL PAC8000 protocol (using ModBus/TCP)? Wouldn't there need to be some piece of logic in the PLC that could understand these packet requests and convert them to PLC register data requests?

The way it is setup now in the DCS logic is there is one Function Block pointed to the MTL I/O Controller itself (which just reads in its status data), then a bunch of AI, AO, DI, and DO Function blocks continuously reading the live I/O data from the MTL I/O data modules. All the blocks have the same node # and IP address. Additionally, the I/O data modules specify a slot # (I think it's something like a max of 56 I/O module slots across 7 "carriers"). So I'm thinking that when the individual I/O Function Blocks execute in the DCS, they are sending a data packet request for a particular MTL I/O module in a particular slot, and when the PLC receives this it won't know what to do with it.