Or provide a Wireshark dump also! Von meinem Mobiltelefon gesendet
-------- Ursprüngliche Nachricht -------- Von: Christofer Dutz <[email protected]> Datum: So., 8. März 2020, 10:13 An: Etienne Robinet <[email protected]>, [email protected] Betreff: Re: Allen Bradley - ETH We built the first driver mainly based on some observations and wireshark dumps. Sometimes the observations are not 100% correct. So if you have such a device and there are things wrong with our mspec, feel free to correct and submit prs... They are highly welcome. Chris ________________________________ Von: Etienne Robinet <[email protected]> Gesendet: Samstag, 7. März 2020 23:16 An: [email protected] <[email protected]> Betreff: Re: Allen Bradley - ETH Hey Chris, Thanks for this I will test in on monday on the PLC. I also wanted to ask why you substracted 28 in the mspec. I analyzed it and it puts the length (in the Register Session packet) to 0 (getSizeinBytes()-28) as it should be 4 (from what I saw from a working implementation of EIP/CIP. The problem was that the PLC would send an error code back because of this 0 length. Etienne ROBINET > Le 7 mars 2020 à 12:27, Christofer Dutz <[email protected]> a écrit : > > Hi All, > > so I just added a packet-size-estimator for AB-ETH ... hope that helps a > little more. > > Chris > > > > Am 07.03.20, 12:23 schrieb "Christofer Dutz" <[email protected]>: > > Hi Etienne, > > well I just had a look at the driver ... it seems it's just not finished > yet. > The reason it doesn't parse the response is that it doesn't know how big > it is ... I will try to implement a packetSizeEstimator for this, but it > would really be great if someone who knows this protocol (Has some sort of > specification as well as a device to test it on) could work on this. > > I'll try to guess what it could be .. but no idea if this gets you much > further. > > We really should only put stuff outside the sandbox, if there's at least > one person willing and able to maintain it ... > > Chris > > > Am 06.03.20, 17:16 schrieb "Robinet, Etienne" <[email protected]>: > > Well from what I've seen, PLC4x is calling right the session register > but > can't handle the positive response (using AB-ETH) > Using 0.6 EIP protocol, the Session is properly opened, but impossible > to > rightly access data as there is no way to mention which slot the plc > is and > the tag (from what I understood) > > Etienne > >> Le ven. 6 mars 2020 à 17:03, Otto Fowler <[email protected]> a >> écrit : >> >> I’ve used that to test session, list identities and get all attributes >> calls from my code to cpppo. >> >> If you look at the documentation and the samples you can get cpppo talking >> to cpppo and then see how the plc4x stuff compares doing the same tasks >> maybe >> >> >> >> >> On March 6, 2020 at 10:49:27, Robinet, Etienne ([email protected]) wrote: >> >> What could I test with this library exactly? >> >> I managed to establish a Session registration at ENIP level, but seems like >> the app can not decode the answer (which has Success code 0 as expected). >> Here is where it's stuck: https://i.imgur.com/ZDrSVTA.png >> >> The packetSize= -1 because the packageSizeEstimator is null (why?) >> >> Etienne >> >> Le ven. 6 mars 2020 à 15:53, Otto Fowler <[email protected]> a écrit >> : >> >>> I would recommend using https://github.com/pjkundert/cpppo to test this >>> stuff to some extent. >>> >>> Using the docker container works well too. >>> >>> >>> >>> >>> On March 6, 2020 at 09:04:11, Christofer Dutz ([email protected] >> ) >>> wrote: >>> >>> Hi Robert, >>> >>> unfortunately I wasn't able to test the ported driver before as I don't >>> have access to an Allen Bradley device. >>> I do however recall that I brought up that the protocol looked familiar >> to >>> the EtherNet/IP protocol, however seems to have differences. >>> So you should treat wireshark decodings with care. >>> >>> Regarding the error itself, this should use the TCP transport which uses >>> the NioSocketChannel which should work with the NioEventLoop, >>> so this error is strange. But it seems to have disappeared as you managed >>> to get passed this issue. >>> >>> It now seems that the problems are related to an invalid request being >> sent >>> or a configuration error on the PLC (Don't know the AB-ETH protocol >>> really). >>> >>> Perhaps Volker can help here. However from a look at the mspec for that >>> protocol, I would assume it's only partially implemented, so perhaps you >>> are unimplemented parts of this protocol. >>> >>> Chris >>> >>> >>> >>> Am 06.03.20, 13:00 schrieb "Robinet, Etienne" <[email protected]>: >>> >>> Hi, >>> After some tweaking I managed to create a right "Register Session" >> message >>> ( >>> https://i.imgur.com/OR9RDdd.png), but I got an error response from the >> PLC >>> ( >>> https://i.imgur.com/2Zm1op3.png). >>> Do you know what the Request should be? >>> >>> Etienne >>> >>> Le ven. 6 mars 2020 à 10:47, Julian Feinauer < >> [email protected] >>>> >>> a écrit : >>> >>>> Hi, >>>> >>>> you already help with your bug reports and the feedback you give! >>>> >>>> Julian >>>> >>>> Am 06.03.20, 10:45 schrieb "Robinet, Etienne" <[email protected]>: >>>> >>>> Hi Julian, >>>> thanks for the fast response. I would be really glad if I could help a >>>> bit >>>> on that, as far as I can. >>>> >>>> Etienne >>>> >>>> Le ven. 6 mars 2020 à 10:43, Julian Feinauer < >>>> [email protected]> >>>> a écrit : >>>> >>>>> Hi Etienne, >>>>> >>>>> sorry that you have that much issues. Perhaps @Volker Emmert can >>>> comment >>>>> on that as he implemented the driver together with @Christofer Dutz. >>>>> >>>>> Julian >>>>> >>>>> Am 06.03.20, 10:37 schrieb "Etienne Robinet" <[email protected]>: >>>>> >>>>> Really sorry for double-post, but I managed to establish a >>>> connection >>>>> by changing the port from 2222 to 44818 ( >>>>> >>>> >>> >>> >> >> https://literature.rockwellautomation.com/idc/groups/literature/documents/qr/comm-qr001_-en-e.pdf >>>>> ) >>>>> >>>>> I also change the url to : ab-eth:tcp://163.243.183.250 >>>>> And this is where the application freezes now: >>>>> >>>>> ab-eth:tcp://163.243.183.250 >>>>> 10:34:49.867 [main] TRACE o.a.p.j.s.c.DefaultNettyPlcConnection - >>>>> Channel was created, firing ChannelCreated Event >>>>> 10:34:49.875 [nioEventLoopGroup-2-1] DEBUG >>>>> o.a.p.j.a.p.AbEthProtocolLogic - Sending COTP Connection Request >>>>> 10:34:49.909 [nioEventLoopGroup-2-1] TRACE >>>>> o.a.plc4x.java.spi.Plc4xNettyWrapper - Adding Response Handler ... >>>>> 10:34:49.909 [nioEventLoopGroup-2-1] TRACE >>>>> o.a.plc4x.java.spi.Plc4xNettyWrapper - Sending to wire >>>>> >>>> >>> >>> >> >> CIPEncapsulationConnectionRequest[sessionHandle=0,status=0,senderContext={0,0,0,0,0,0,0,0},options=0] >> >>> >>>>> 10:34:49.920 [nioEventLoopGroup-2-1] DEBUG >>>>> o.a.plc4x.java.spi.Plc4xNettyWrapper - Forwarding request to plc >>>>> >>>> >>> >>> >> >> CIPEncapsulationConnectionRequest[sessionHandle=0,status=0,senderContext={0,0,0,0,0,0,0,0},options=0] >> >>> >>>>> 10:34:49.926 [nioEventLoopGroup-2-1] DEBUG >>>> io.netty.util.Recycler - >>>>> -Dio.netty.recycler.maxCapacityPerThread: 4096 >>>>> 10:34:49.926 [nioEventLoopGroup-2-1] DEBUG >>>> io.netty.util.Recycler - >>>>> -Dio.netty.recycler.maxSharedCapacityFactor: 2 >>>>> 10:34:49.926 [nioEventLoopGroup-2-1] DEBUG >>>> io.netty.util.Recycler - >>>>> -Dio.netty.recycler.linkCapacity: 16 >>>>> 10:34:49.926 [nioEventLoopGroup-2-1] DEBUG >>>> io.netty.util.Recycler - >>>>> -Dio.netty.recycler.ratio: 8 >>>>> 10:34:49.935 [nioEventLoopGroup-2-1] DEBUG >>>>> io.netty.buffer.AbstractByteBuf - -Dio.netty.buffer.checkAccessible: >>>> true >>>>> 10:34:49.935 [nioEventLoopGroup-2-1] DEBUG >>>>> io.netty.buffer.AbstractByteBuf - -Dio.netty.buffer.checkBounds: true >>>>> 10:34:49.935 [nioEventLoopGroup-2-1] DEBUG >>>>> i.n.util.ResourceLeakDetectorFactory - Loaded default >>>> ResourceLeakDetector: >>>>> io.netty.util.ResourceLeakDetector@385a14ab >>>>> 10:34:49.966 [nioEventLoopGroup-2-1] DEBUG >>>>> o.a.p.j.s.GeneratedDriverByteToMessageCodec - Sending bytes to PLC >>>> for >>>>> message >>>>> >>>> >>> >>> >> >> CIPEncapsulationConnectionRequest[sessionHandle=0,status=0,senderContext={0,0,0,0,0,0,0,0},options=0] >> >>> >>>>> as data 01010000000000000000000000000000000000000000000000000000 >>>>> 10:34:49.972 [nioEventLoopGroup-2-1] TRACE >>>>> o.a.p.j.s.GeneratedDriverByteToMessageCodec - Receiving bytes, >>>> trying to >>>>> decode Message... >>>>> >>>>> BR, >>>>> >>>>> Etienne >>>>> >>>>> On 2020/03/06 09:30:22, Etienne Robinet <[email protected]> >>>> wrote: >>>>>> Hi all, >>>>>> I wanted to ask how far we are on the AB-ETH driver? I have a >>>>> LOGIXS5580 Series PLC to test, and when I try to run the HelloWorld >>>> example >>>>> I get following error: >>>>>> >>>>>> 10:24:44.771 [nioEventLoopGroup-2-1] INFO >>>>> o.a.p.j.s.c.NettyChannelFactory - Unable to connect, shutting down >>>> worker >>>>> thread. >>>>>> org.apache.plc4x.java.api.exceptions.PlcConnectionException: >>>> Error >>>>> creating channel. >>>>>> at >>>>> >>>> >>> >>> >> >> org.apache.plc4x.java.spi.connection.NettyChannelFactory.createChannel(NettyChannelFactory.java:115) >> >>> >>>>>> at >>>>> >>>> >>> >>> >> >> org.apache.plc4x.java.spi.connection.DefaultNettyPlcConnection.connect(DefaultNettyPlcConnection.java:89) >> >>> >>>>>> at >>>>> >>>> >>> >>> >> >> org.apache.plc4x.java.PlcDriverManager.getConnection(PlcDriverManager.java:74) >> >>> >>>>>> at >>>>> >>>> >>> >>> >> >> org.apache.plc4x.java.examples.helloplc4x.HelloPlc4x.main(HelloPlc4x.java:45) >> >>> >>>>>> Caused by: java.lang.IllegalStateException: incompatible event >>>> loop >>>>> type: io.netty.channel.nio.NioEventLoop >>>>>> at >>>>> >>>> >>> >>> >> >> io.netty.channel.AbstractChannel$AbstractUnsafe.register(AbstractChannel.java:462) >> >>> >>>>>> at >>>>> >>>> >>> >>> >> >> io.netty.channel.SingleThreadEventLoop.register(SingleThreadEventLoop.java:87) >> >>> >>>>>> at >>>>> >>>> >>> >>> >> >> io.netty.channel.SingleThreadEventLoop.register(SingleThreadEventLoop.java:81) >> >>> >>>>>> at >>>>> >>>> >>> >>> >> >> io.netty.channel.MultithreadEventLoopGroup.register(MultithreadEventLoopGroup.java:86) >> >>> >>>>>> at >>>>> >>>> >>> >>> >> >> io.netty.bootstrap.AbstractBootstrap.initAndRegister(AbstractBootstrap.java:322) >> >>> >>>>>> at >>>>> io.netty.bootstrap.Bootstrap.doResolveAndConnect(Bootstrap.java:159) >>>>>> at io.netty.bootstrap.Bootstrap.connect(Bootstrap.java:143) >>>>>> at >>>>> >>>> >>> >>> >> >> org.apache.plc4x.java.spi.connection.NettyChannelFactory.createChannel(NettyChannelFactory.java:99) >> >>> >>>>>> ... 3 more >>>>>> >>>>>> Any ideas on where this comes from? In Studio5000 the PLC is >>>> on the >>>>> slot 4 and I am connected to a swtich on IP: 163.243.183.250 and >>>> here's the >>>>> plc4x uri: "ab-eth://163.243.183.250/". >>>>>> >>>>>> BR, >>>>>> >>>>>> Etienne >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >> > > > >
