Can an AB PLC talk OPC?

TheWaterboy

Lifetime Supporting Member + Moderator
Join Date
May 2006
Location
-27.9679796,153.419016
Posts
1,905
I hope this isn't an obvious question but can any AB PLC talk OPC such that it could read and write directly to Kepware (or IGS) system tags? OR any OPC tags for that matter.

I very well know that Kepware is intended to work in the opposite direction, I'm just curious. There could be potential use for a PLC knowing the state of a Kepware tag. I don't have one yet.... just asking
 
Gut feeling is that there isn't market for traditional OPC DA running on a processor. Would it make a difference who initiates the transfer of data between Kepware and PLC?

On the other hand, if there was one that "spoke" OPC, it would most likely be licensed separately. I wonder if that CompactLogix that runs Windows could be used to achieve something like this? Running Linx on it and then, somehow, transferring the value to the PLC?
 
I was certain I recalled AB talking about supporting it at one point but it turns out they only do it through software (FTLinx and now Optix) and there is a Softing hardware module now so that pretty much spells it out.

I'll move on to other fruitless quests.
 
So, here is the deal: AB PLCs don't talk OPC. This means that they don't have OPC Compliance built in, and OPC protocol can't be responded to via AB PLCs.

However, almost all popular OPC servers have various AB PLC Drivers, which act as middleware and allow OPCs to talk to all the different types of PLCs from PLC5->Logix series.


To accomplish getting the system tags from OPC to AB PLC's tag memory, you will need to first link the system tags to AB tags, on the OPC server.

This should be possible to do via advanced tags most OPC servers provide: https://www.youtube.com/watch?v=1WmtBp0Cbr8. Disclaimer, I've only used these to link AB<-> Beckhoff/Siemens PLCs, but I don't think System tags would be a problem.


You should be able to test this out really quickly with KepwareEX's trial version. Currently my testbench is down otherwise I would have been happy...
 
Siemens PLCs can be both OPC UA servers and OPC UA clients, so it is not such a farfetched notion. And one of the intentions of OPC UA is to cut out the middle-man (OPC DA or OPC UA on PC) for communicating between devices.

OPC DA only exists on Windows PCs.
 
I know an actual PLC can communicate to a SoftLogix PLC (PLC Running on a PC as a service). I have done that before. So maybe something along that line?
 
I think Siemens is going down the route of OPC UA to cut the middlemen selling drivers, but also to force people to use the benefits of their tag based approach.

I am not very confident about this approach being copied over to the rest of the industry(Maybe I'll eat my words). OPC onboard creates a lot of overhead I'm sure, and major players might be hesitant to do this as OPC Companies already provide 1st party support for their products.

Honestly even today if I was to make a Siemens based IOT architecture, I would suggest a S7 driver rather than an intermediary OPC connection to the PLC, but that might just be me.
 
One though (if you wanted to write enough code) is to use the 1756-CMS1B1 (Windows Compute Module) with the SDK rockwell provides, and build a OPC server using the SDK that enables direct tag interaction between the controller and your OPC server. It would be a lot of work though, since the best OPC implementation to use is the OPC Foundation's .NET library for OPC UA and if I remember correctly the Rockwell SDK is in C++, so bridging the two would be the trick. I have built OPC servers on the OPC Foundation's .NET implementation, and that part is not so bad. For OPC DA there are some old C++ projects that exist on GitHub, but it would take more effort than it is worth to resurrect them and tie them into the Rockwell SDK.

The other option is to implement OPC UA using the ControlLogix socket messages. I image it would be slow and cumbersome though. OPC UA is quite complex and it would be hard to implement in logic in the controller.

EDIT: If the goal is to know the quality of the kepware tag (OPC quality) then you could might be able to do something like creating an advanced tag in Kepware that copies the quality of one tag into the value of another tag that gets written to the PLC. Basically you would have a value and quality tag in the PLC and Kepware, where Kepware updates the quality and the PLC updates the value.
 
Last edited:
I am not very confident about this approach being copied over to the rest of the industry(Maybe I'll eat my words). OPC onboard creates a lot of overhead I'm sure, and major players might be hesitant to do this as OPC Companies already provide 1st party support for their products.

Honestly even today if I was to make a Siemens based IOT architecture, I would suggest a S7 driver rather than an intermediary OPC connection to the PLC, but that might just be me.


For sure, when you're connecting to a system that can use S7 connections, that's a good option, but OPC UA has a few advantages. The first, and most obvious, is that it supports systems that don't have an S7 driver, but a big second is that it is way more secure than basic S7 comms. Certificate and user/pass options for authentication and encryption are huge, over the wide open S7 protocol. Also, you can create an interface for your machine for OPC UA, whereas with S7 the data access is all or nothing.



I see OPC UA as a great option for machine to machine (m2m) communication, especially when it isn't a simple 1:1 setup. I-device is all well and good, but Profinet has some definite limitations and expectations (no routing, for one).



Siemens has definite recommendations on how to structure your data to optimize the communication and minimize the overhead. The goal is request 1 big array or 1 big UDT with 1000 tags in it, not 1000 individual tags.
 
Honestly even today if I was to make a Siemens based IOT architecture, I would suggest a S7 driver rather than an intermediary OPC connection to the PLC, but that might just be me.

When you say IOT, do you mean a PLC sending stuff to AWS database somewhere in the globe? Or a local system?
 

Similar Topics

Hi I have an old panel builder 32 that I’m replacing for a factory talk me hmi . In the plc for the old panel builder there is a coms bit for the...
Replies
0
Views
61
Good day colleagues, I have a problem with a plc slc 5 since I export the tags to my factory program to load them into a panel view 1000 plus 6...
Replies
0
Views
87
Hi all, I'm having an issue with connecting View Studio emulation to a real PLC. I am running View Studio 8.01 on a Hyper-V virtual machine...
Replies
0
Views
233
I am trying to evaluate the differences between using FactoryTalk Security and the Service Edition of Rockwell software to limit access to edit...
Replies
3
Views
2,195
Hello everyone, hoping someone here has experience with doing something like this. I am wanting to transfer a string of the currently logged in...
Replies
11
Views
3,533
Back
Top Bottom