Hi Matthias,
I wouldn't like to have this handled by a new driver-name. Also do I think this
is something quite related to the driver itself as this type of problem doesn't
occur with other protocols (Not that I know of).
We probably will be refactoring all drivers to:
- IP-Based drivers simply have an IP and an optional port config
- Serial-Based drivers simply have device uri ("/dev/s0" or "com1")
Which would be pretty much similar to the existing, but the "S7" driver would
drop the "/1/1" at the end, the AMS would lose the last two ".1.1" and so on
and generally operate with defaults.
If a non-default has to be used, I think it's the plan to add options to the
string (Same way the S7 currently supports some additional things like to pass
in the expected remote PLC type):
s7://10.10.64.20:123?rack=2&slot=4
or for ADS/AMS:
ads://10.10.64.40?amsNetId=1.2.3.4.5.6
In your proposed opc-ua case I could imagine something like this:
opc-ua:typ://10.10.64.50?ndiscover=true
Would that be ok for you?
Chris
Am 02.12.19, 13:31 schrieb "Strljic, Matthias Milan"
<[email protected]>:
Hi all,
For this I have a question: How should we deal with this consistently in
the project?
The Camel discussion about parameters/annotation is not over yet (?) and I
want to avoid parameters in the URL that are not part of the domain model of
the protocol.
So I would solve it first as a new connection subtype.
"opcua:tcp-ndiscover://145.............".
But on the other hand this only makes sense if this is a real exception and
would else explode in number by defined subtypes.
So what do you think?
Greeting
Matthias Strljic, M.Sc.
Universität Stuttgart
Institut für Steuerungstechnik der Werkzeugmaschinen und
Fertigungseinrichtungen (ISW)
Seidenstraße 36
70174 Stuttgart
GERMANY
Tel: +49 711 685-84530
Fax: +49 711 685-74530
E-Mail: [email protected]
Web: http://www.isw.uni-stuttgart.de
-----Ursprüngliche Nachricht-----
Von: Alvaro del Castillo (Jira) <[email protected]>
Gesendet: Friday, November 29, 2019 5:21 PM
An: [email protected]
Betreff: [jira] [Created] (PLC4X-157) OPC-UA: Disable by config endpoint
discovery
Alvaro del Castillo created PLC4X-157:
-----------------------------------------
Summary: OPC-UA: Disable by config endpoint discovery
Key: PLC4X-157
URL: https://issues.apache.org/jira/browse/PLC4X-157
Project: Apache PLC4X
Issue Type: Improvement
Components: Driver-OPC-UA
Reporter: Alvaro del Castillo
Some real world devices like the [https://iqunet.com/server-and-data/]
includes as the OPC-UA server the FreeOPCUA server running inside a docker.
When you discover the endpoints, the IPs advertised are the internal ones in
the docker container, so you can not access these endpoint from the network.
It is an issue in the device, but for those cases, just using directly the
public IP in which the OPC-UA server is listening as the endpoint is the only
solution.
For PLC4x to work in those cases, a config option must be available to
disable the endpoint discovering and just connect to the endpoint build with
the public IP.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
