Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added OPC UA server support #16

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

guqinchen
Copy link

Mapped all Modbus I/O (discrete and analog) to OPC UA server.

Mapped all Modbus I/O (discrete and analog) to OPC UA server.
Copy link
Owner

@thiagoralves thiagoralves left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just skimmed through the code and it looks really good! It appears to be in sync with the current OpenPLC coding scheme. Thank you for the contribution! Just two quick questions:

  1. Both Modbus and DNP3 standards define that inputs are read-only from the protocol. I’m not familiar with OPCUA, so I don’t know what is the right approach for this, but I noticed that your code has inputs with what appears to be only write permissions (opcua.cpp lines 137-152 and 174-185)

  2. Have you tested this on all three platforms (Windows, Linux, and Raspberry Pi)? If not, I’ll test it first and then merge.

@guqinchen
Copy link
Author

@thiagoralves In my understanding, the OpenPLC takes inputs from the OPC UA server, which may be set by a sensor device or simply software; conversely, after the PLC program executes based on the inputs, the outputs are updated in the OPC UA server for actuators to read. Thus, I have set the inputs as writable (and also readable by default), and outputs as read-only, as they can only be updated by the PLC program.
I haven't tested this on all three platforms. I would appreciate if you can test it. But feel free to remove the support for Windows/Raspberry Pi and other non-Linux platforms for now.

@epgodoy
Copy link

epgodoy commented Nov 12, 2018

Even though the operation described by guqinchen is interesting for other applications, in my opinion, the OpenPLC must use the input values from the physical PLC inputs. And the OPC UA should be used for monitoring purposes.

@thiagoralves
Copy link
Owner

@guqinchen The operation you described is more suitable for the Slave Devices module. This module currently uses Modbus to communicate with slave devices, and therefore reads their inputs and update their outputs, just like you described. However, this module only has access to a small portion of the OpenPLC address space (%IX100, %QX100, etc), and not the whole thing. As @epgodoy explained, it is not wise to let OPCUA applications overwrite what OpenPLC is reading through its physical inputs. If you want to use the whole address space like Modbus and DNP3 protocols are doing, you must change the OPCUA implementation to be a slave instead of a master, i.e. software will connect for monitoring purposes.

@thiagoralves
Copy link
Owner

Just to get back on this, it seems that the operation described by @guqinchen is more suitable for a Hardware Layer than a protocol addition. From my understanding, this code is using data from an OPC Server as internal I/O. That's exactly what a Hardware Layer does. The slave devices support on OpenPLC is very similar to this, but instead of using OPC, it uses Modbus. It was added as a Hardware Layer (file modbus_master.cpp)

The execution phase is skipped in each scan cycle unless a signal is
received from the client, containing the I/O settings.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants