OPC Communication Missing from MK

[ArcEye]

Issue by jpmoniz Mon Jan 11 01:12:32 2016 Originally opened as https://github.com/machinekit/machinekit/issues/858

---

I've had the idea of giving MK OPC server capability for a while. OPC is a pretty common communication scheme used in the industrial automation realm. Most HMI's and Scada packages support OPC.

Typically a OPC server instance is deployed on a PC or HMI along with appropriate drivers to communicate with PLC,Robot and other devices.

My thought was to run a OPC server instance within MK copying HAL pins over into the server.

OPC clients could then subscribe to information contained within the server.

Currently I have been toying around with https://github.com/FreeOpcUa/python-opcua I have been able to use the HAL cython bindings to read in HAL pin names and values into node objects within the OPC server.

Still need to work on basics like writing values from a OPC client into HAL pins

Here is a quick screen shot to better illustrate.

[ArcEye]

Comment by machinekoder Mon Jan 11 16:17:12 2016

---

Are there more details on OPC anywhere? It might be more suitable to write a broker that automatically converts Machinetalk messages to OPC.

[ArcEye]

Comment by jpmoniz Mon Jan 11 16:55:23 2016

---

@strahlex

What is OPC

https://opcfoundation.org/about/what-is-opc/

and

https://opcfoundation.org/developer-tools/specifications-unified-architecture

[ArcEye]

Comment by machinekoder Mon Jan 11 17:47:58 2016

---

I need an account to download the spec. Can you quickly summarize what it does? It seems to be a standardized data exchange format. Mentioned on the webpage is also that it is used to convert OPC commands to vendor specific formats. Sounds like a Machintalk bridge might make sense.

[ArcEye]

Comment by jpmoniz Mon Jan 11 18:04:39 2016

---

@strahlex

To make a short story long look here

https://www.youtube.com/watch?v=H1yG2Wy_TvA

or

It's just a standardized communication stack/Information model with security,subscription services and a bunch of other neat features probably beyond my comprehension. It uses a Server/Client architecture.

Typically in the past with OPC-COM a specific driver would be used to communicate with a device and then that devices data would be mapped into the OPC server

Now with OPC UA the vendor specific drivers disappear. Vendors are embedding client and server stacks into their devices and just talking OPC UA between devices.

[ArcEye]

Comment by machinekoder Sun Jan 17 02:39:56 2016

---

Looks interesting. They also talk about data semantics. I think it would make sense to make the bridge semantically compatible with wathever client you want to use. Not sure how useful a generic HAL adapter would be. Basically some sort of publish-subscribe and RPC meachanisms are used. It should be possible to map this on the Machinetalk API for various services. However, it might make sense to look on a specific use case in advance. I guess that certain type of controller provide specific interfaces and it would make sense to map the OPC interface to wathever is required.

[ArcEye]

Comment by jpmoniz Mon Jan 18 16:51:36 2016

---

@strahlex I would have to dig into machinetalk to better understand it. I was thinking very basic at the moment.

1.Start server and Read all available HAL pins into OPC server memory

2. Initiate Client connection from MK and connect to server.
3. On a HAL pin data change update the OPC server memory. HAL => OPC server
4. On a server data change subscription from clients other than MK write back to HAL. OPC Server => HAL.

I understand this is just a hack. I just don't understand Haltalk or MachineTalk that well right now.

[ArcEye]

Comment by machinekoder Tue Jan 26 02:02:30 2016

---

Do you have any specific use case? Would make sense to emulate a specific device category if it should be used in a production environment. If it is just for reading out HAL pins then your approach makes sense. Is there any example of how two OPC-capable devices are usually connected?

[ArcEye]

Comment by jpmoniz Tue Jan 26 02:57:16 2016

---

@strahlex

No specific use case in mind.

If I view MK as a robot controller or a PLC/PAC then it makes sense to me to expose HAL via OPC. My typical usage of OPC has been via standalone server application that have connectivity drivers builtin that allow connection of devices such as Robot controllers, PLC's, VFD and such. Examples include. Kepware,Matricon, Softing and such. OPC being directly built into devices, has only become popular in the last little bit with the whole industry 4.0 and IoT movements. I guess my thought would be that MK would not need a third party server to expose itself and could either provide a server interface or just a client interface depending on the need.

[ArcEye]

Comment by evanmj Thu Feb 11 19:43:12 2016

---

@strahlex,

Here is a typical industrial use case I've seen:

A customer hires 8 different integrators to build / integrate different parts of an assembly line... one that makes cars for instance.

Cells 1-8 of the line will often employ different technologies available from the various vendors available. Each PLC and robot vendor usually has a "native" protocol they use, and then a set of other protocols they "support". Often these "supported" protocols are options you can add ($$$), or you can use a software package like "kepware" that talks each of these unique protocols and convert them all to OPC-UA, so there is a common central data platform for the entire line.

OPC (The newest/best of which is OPC-UA) is often used as this "common" abstracted data system since it is rather simple and rather old and well supported.

Adding OPC-UA to machinekit (at some level) would in theory allow one of these 8 theoretical cells in the line to be based on machinekit, and have a central HMI with "more traditional" automation, and have them seamlessly integrate with the common HMI software used these days.

Long story short, it is data abstraction that is well supported in industrial automation. I think the folks behind the "Industry 4.0" movement have named it the default protocol.

[ArcEye]

Comment by machinekoder Fri Mar 4 10:18:55 2016

---

@evanmj Yes, I agree a common abstraction layer is a good idea. However, what I mean is that the data which has to be exposed by specific machine is depending on the application. It would be great if we would have a specific example. One thing that could be provided by Machinekit is a parametric OPC component for HAL which can be configured to expose certain HAL pins.

[ArcEye]

Comment by evanmj Fri Mar 4 15:51:49 2016

---

@strahlex, I agree. A configurable OPC<->HAL program would be ideal that lets a user decide which HAL pins to expose over OPC. Commonly used pins would be machine start, stop, various status info like current position, velocity, active tool, etc. (at least in the context of a machine tool).

[ArcEye]

Comment by jpmoniz Tue Mar 29 13:22:36 2016

---

@strahlex ,

If we kept the idea basic in nature to begin with. What are your thoughts about mapping HAL to OPC address space? How would you go about it. right now I crudely just used the cython api and read everything in wholesale.

[ArcEye]

Comment by luminize Wed Oct 18 18:24:37 2017

---

I came around some API references which might be interesting. https://en.wikipedia.org/wiki/OPC_Unified_Architecture#OPC_UA_APIs

[sirop]

@machinekoder

https://doc.qt.io/QtOPCUA/qtopcua-index.html

So more and more of OPC UA standard is getting into Qt, then if QtOPC gets part of QtQuickVcp, we can rely on the "usual" way of writing and reading HAL pins.

I tested QtOPC two months ago: just writing and reading some values worked already then. However, more advanced features like encryption might be still missing.