Hi Stephen, That's a cool list of systems you can play with. So, I think this would really be cool to verify things work on these. I'll be happy to help you sort out any problems you come across.
Just today, Sebastian created a neat little tool (plc4j/utils/test-generator), that takes a WireShark recording with packets for a given protocol and creates these XML ParserSerializerTestsuite.xml files from them. This will greatly help track down and reproduce problems. So, if for example you are doing something and it's not working, you could simply record those packets, create a testsuite.xml from that and either use that to fix the problem yourself or you can attach it to a ticket with which people without that device can poke around. I haven't used it yet and it might need a bit of polishing, but I am sure it will be a great help in sorting problems out in a distributed fashion. We might even use it to record the traffic created by one utility and use the generated testsuite to ensure our version is identical. Especially with the EIP I must admit, the only device I had, when I initially wrote that driver, was a Wago 2 channel digital input ... so I would expect it to not be as thoroughly tested as the others. But I think the version we have now isn't my initial one anyway ... so just forget about that ;-) Happy to hack a bit on this with you. Chris -----Original Message----- From: Stephen Snow <s40...@gmail.com> Sent: Mittwoch, 19. Januar 2022 18:13 To: dev@plc4x.apache.org Subject: Testing - my hardware list, and change of topic 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>* >
