Dear all,
On Mon, 2019-12-02 at 12:43 +0000, Christofer Dutz wrote:
> 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
I find easier to understand:
opc-ua:typ://10.10.64.50?discover=false
Following this discussion, for modbus the idea for the slaveId could
be:
modbus:tcp://10.10.64.51:502?slaveId=1
Right?
I update the JIRA issue about it.
Cheers!
>
> 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)
>
>
