I come over this issue yesterday, but on other end. While trying to get
0.10 running under OSGi I found that "wiring" if fine but whole thing
fails to work at runtime.
This boils down to several things, but Transport SPI lookup too. I agree
that listing supported transports types (tcp/udp/serial/can) is fine for
start. On other hand it is unlikely we will ever get S7 working over
serial line so we could in theory declare that it works only with
TcpTransport. Later one is actually beneficiary, at least for OSGi,
cause it makes S7 driver classpath aware of TcpTransport requirement.
This was issue Etiane was facing back then while working with Camel
components to wire everything in.
Anyhow, I am fine with both, with some level of preference for listing
transports directly. If we scope dependencies properly end users will
get drivers working out of the box with very few entries in their build
tool.
Best,
Łukasz
On 19.01.2022 10:44, Christofer Dutz wrote:
Hi Cesar,
right now, I would only like to give back a list of strings that are the codes
of the supported transports.
Perhaps we should extend the transports to give tooling more assistance on how
a given transport is to be configured.
Chris
-----Original Message-----
From: Cesar Garcia <[email protected]>
Sent: Sonntag, 9. Januar 2022 17:29
To: Apache PLC4X <[email protected]>
Subject: Re: [DISCUSS] Extend PlcDriver with "supportedTransports"?
How are they?
Not only the transport, but also the data structures of the items.
This would allow the user to have a reference of what you can request in the
items.
Looking to the future, this would be a must for the OPC-UA server.
Kind regards,
El dom, 9 ene 2022 a las 6:10, Christofer Dutz (<[email protected]>)
escribió:
Hi all,
I know initially I built the Plc4X API to generally allow any form of
driver to use any form of transport.
However, this only would have worked in theory.
I think we should probably have every driver provide a list of
supported transports.
This would also help make tool integration easier.
If we see that for example sometimes, we have ModbusRTU passed along
TCP/UDP connections via serial-to-ethernet adapters, we can definitely
support that and if we come across a mode of operation, that we
haven't encountered, it should be easy to extend.
But this way we could ensure that we build the drivers in a way that
they know what to expect.
What do you think?
--
*CEOS Automatización, C.A.*
*GALPON SERVICIO INDUSTRIALES Y NAVALES FA, C.A.,* *PISO 1, OFICINA 2, AV. RAUL
LEONI, SECTOR GUAMACHITO,*
*FRENTE A LA ASOCIACION DE GANADEROS,BARCELONA,EDO. ANZOATEGUI* *Ing. César
García*
*Cel: +58 414-760.98.95*
*Hotline Técnica SIEMENS: 0800 1005080*
*Email: [email protected]
<[email protected]>*
