Hi Chris, On Wed, 2022-01-19 at 12:52 +0000, Christofer Dutz wrote: > Hi Stephen, > > Thanks for your input :-) > You're welcome, it's easy to be an armchair quarterback.;)
> With my statement I was referring to Modbus-TCP which will most > likely be used with TCP, Agree. > but I agree I should have chosen a different example. (We should > investigate how Modbus-ASCII differs and mabe also directly support > that). Sorry, my bad, it is actually just ASCII for all PLC's (that I have used anyway), and it is based on Hayes modem protocol. It is the traditional serial communication for remote units at places like waste water treatment plants, etc... > 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). > Agreed. > 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. > Okay, implimentation specifics can be an area of concern, so in my mind "expect to work" has always come with caveats and in my experiences too. > Also testing all these combinations is a bit tricky, as they require > hardware for testing, and I at least don't have that. > I have some ... * Rockwell Automation Micro820-20QBB, 1xSerial (RS-232/RS-485, Modbus/ASCII capable), 1xEth (Ethernet/IP, Modbus-TCP) * Omron CP1H PLC (x2), 2xSerial RS-232 Omron protocols, 1xUSB prg port * Red Lion Control's G308C, 1xEth, 1xRS485, 2xRS232, 1xUSB, pretty much any protocol you can pick for all ports except USB. (HMI with a micro PLC and mini PC more or less) * Raspberry Pi IIb, 1xEth, 1xSerial (needs linedriver addon for that) * Allen-Bradley PowerFlex 523 VFD, DSI I believe can run as Modbus RTU If you need something (code) tested, I don't mind helping. I had a Modicon PLC around but had to return it, M221. > Would you please be so kind and start a new thread about the problems > you were mentioning? > Sure, let me poke at it for a bit. > 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. > Yes, I volunteered to help Ben with it, I forked the repo (Modbus-RTU) and cloned it which I am working with now. > 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. > I want to get the Rockwell Automation CIP protocol (EIP) sorted since I will be more likely to use it around here in Allen-Bradley land. Again, any particular needs here I don't mind helping where I can with. > 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)? > Yes. > 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. > Again, testing is something I can do for the above hardware I list. Unfortunately, I haven't been as active with Siemens S7 products as I would have liked since the use is low in my area. The S5 and Sinumerik platforms were the ones I was familiar with, PLC and CNC systems. So I am not as cozy with Siemens Canada as I was back then. Not sure any of my old contacts would be around. Stephen > 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>* >
