Hi Stephen, Thanks for your input :-)
With my statement I was referring to Modbus-TCP which will most likely be used with TCP, but I agree I should have chosen a different example. (We should investigate how Modbus-ASCII differs and mabe also directly support that). I guess even Modbus is probably the version with the most variants in transport being used. However, I would highly doubt, that for example PROFINET will be anything else than raw ethernet frames sent on a raw transport (with UDP for setting up the connection). I didn't want to limit PLC4X to use only the "supported" ones, in general I think if a user wants to do PROFINET via Serial, the framework shouldn't keep him from trying, but the user shouldn't expect it to work. Also testing all these combinations is a bit tricky, as they require hardware for testing, and I at least don't have that. Would you please be so kind and start a new thread about the problems you were mentioning? Are you planning on bringing your Modbus-RTU work back to the project? Cause that's been something there was quite a bit of discussion about and interest for. I think for protocols like EIP, KNX and BacNET there seems to be a wider range of interpretations in the Specs, and we have seen a number of "interpretation" by vendors that seem to differ from the specs. So it might be that for the one or the other device or vendor, we might have to come up with flavors, variants or modes in the drivers. However again, this is a bit problematic as we don't have the hardware. Auto-discovery is also something we have started working on ... I think the Go version is a bit more ahead regarding that, but for example PROFINET (WIP) already allows auto-detecting devices. Do you want to join in on working on this (Auto-discovery in general)? I think regarding your request to tweak the settings of the transport: Transports do have a list of supported options and we generally wanted to run the transports with sensible defaults (defaults provided by the corresponding driver) and make them overridable with options in the connection-string. So some of this tweaking should already be possible. However especially regarding serial transport options, I haven't got any hardware using any non-defaults, so difficult to test. Chris -----Original Message----- From: Stephen Snow <s40...@gmail.com> Sent: Mittwoch, 19. Januar 2022 13:33 To: dev@plc4x.apache.org; Łukasz Dywicki <lukasz.dywi...@connectorio.com> Subject: Re: [DISCUSS] Extend PlcDriver with "supportedTransports"? 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>*
