Can an AB PLC talk OPC?

[TheWaterboy]

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

[cardosocea]

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?

[JesperMP]

deleted, I misread the question...

[TheWaterboy]

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.

[PreLC]

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...

[PreLC]

Originally Posted by cardosocea

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?

This is funny, as Siemens now gives 1st party OPC onboard the S7 PLCs. https://support.industry.siemens.com...dti=0&lc=en-WW

[JesperMP]

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.

[JaxGTO]

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?

[cardosocea]

Originally Posted by PreLC

This is funny, as Siemens now gives 1st party OPC onboard the S7 PLCs. https://support.industry.siemens.com...dti=0&lc=en-WW

Yes, OPC UA... which comes with a lot more possibilities and features than OPC DA. I assumed OPC DA, but I see that was wrong.



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.

[PreLC]

Originally Posted by cardosocea

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.

[tlf30]

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.

[mk42]

Originally Posted by PreLC

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.

[busarider29]

Originally Posted by JesperMP

Siemens PLCs can be both OPC UA servers and OPC UA clients, so it is not such a farfetched notion.

Same for Beckhoff PLC's too.

[cardosocea]

Originally Posted by PreLC

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?

[PreLC]

Local. Probably don't want to put my PLCs nor the onboard OPC on the www.