machinekit-hal
machinekit-hal copied to clipboard
machinekit
OPC Communication Missing from MK
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.
Are there more details on OPC anywhere? It might be more suitable to write a broker that automatically converts Machinetalk messages to OPC.
@strahlex
What is OPC
https://opcfoundation.org/about/what-is-opc/
and
https://opcfoundation.org/developer-tools/specifications-unified-architecture
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.
@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.
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.
@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.
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?
@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.
@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.
@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.
@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).
@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.
I came around some API references which might be interesting. https://en.wikipedia.org/wiki/OPC_Unified_Architecture#OPC_UA_APIs
@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.
