Hello, I would like to just add to this conversation if I may. On Wed, 2022-01-19 at 11:00 +0000, Christofer Dutz wrote: > Well the problem with eagerly including transports is:
> For example, using Modbus ... most transports being used will > probably be onls TCP. Not entirely true, there is Modbus Ascii which is used over serial and is not limited in scope like RTU. Sometimes referred to as extended. > And with Modbus-RTU it should only work with Serial, but there are > people using serial-to-network converters, so you also could use > Modbus-RTU via TCP transport Yes, been there done that. > ... also, if we ever support passive-mode we would be adding raw- > passive. I think initially I made the drivers explicitly depend on > the default transports and have people include the optional ones. I > think for the raw transports on some systems you needed to run the > application as root or with privileged network access. > So for this project, which is an API to talk to any PLC presumably, I think that the end use case does determine the extent to which discovery is desirable. In my use case(s) I am trying to make a viable product from, I am finding the driver inflexible in the regards to messaging. As an example, I can connect both via TCP and via Serial transport to the same PLC. After a bit of bashing, I was able to get a response via Modbus-RTU from a lone address in the PLC. But the physical serial connection was established and I could also build a message manually and just use the serial transport to send/receive it and works fine. I was getting netty.io complaints going through the PLC4X protocol. The TCP connection is EIP protocol and the PLC is a Rockwell Automation Micro820, so at this time I am going to dig into the EIP protocol bit to determine why the message is failing with it since the structure is what the PLC is expecting. I believe that there was some discussion of Allen-Bradley CIP protocol issues, I'm going to dig into that presently. > But admittedly this has been so many years ago .. I don't even know > if this is a problem today. > > My reasoning on using "supported" is that these are the transports we > are aware of and explicitly support, if the user uses S7 with Serial > for example, that's not "supported" and if he has trouble with this > ... well I guess it's his problem ;-) > So, I have worked as a Systems Integrator, a Solution Provider, and a machine builder (turn-key solutions) for a long time and have seen almost everything that was made for purpose 'A' being made to work for purpose 'B'. The one thing about PLC's is that they can be used for a broad range of tasks, though they are more specialized generally, but that is usually I/O count or motion capability. IMO, the driver(s) should work with whatever transport is available (within reason). I frequently am connected (out in the field) to one device on a network, using one driver, and talking to two or more devices on the network via pass-thru, which most OEM's like Siemens support, does PLC4X contemplate supporting such? From the POV of the user, I would like to connect to a e'net switch, and browse to connect, this is my current goal, discoverable PLC with automatic connection. I understand my use case is likely very specific in that I am a sole proprietor and follow my customers needs while trying to look out for their future needs, so I am not always doing the latest and greatest, just what they require (and are willing to pay for). > So, what would you be proposing on returning? @Łukasz Dywicki ... > instead of returning "tcp" to return "Class<TcpTransport>" (or > however we do it)? > I would return a transport object, ie the instance that was created. I need to be able to after connection change things like baud rate etc., or in the case of Modbus-RTU protocol, the timing of the communication instructions needs to be configurable and should be easily exposed with getter/setter methods. Also, from the POV of a serial transport, I need to be able to set the port mode in some cases (RS-232 or RS-485 or RS- 422) for whatever purpose, like talking on an RS-232/RS-485/RS-422 network all over the serial port. Stephen > Chris > > > -----Original Message----- > From: Łukasz Dywicki <l...@code-house.org> > Sent: Mittwoch, 19. Januar 2022 11:47 > To: dev@plc4x.apache.org > Subject: Re: [DISCUSS] Extend PlcDriver with "supportedTransports"? > > 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 <cesar.gar...@ceos.com.ve> > > Sent: Sonntag, 9. Januar 2022 17:29 > > To: Apache PLC4X <dev@plc4x.apache.org> > > 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 > > (<christofer.d...@c-ware.de>) > > 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: support.aan.automat...@siemens.com > > <support.aan.automat...@siemens.com>*
