Hi Etienne, well the mspec currently doesn't even exist ... so it would be at first creating the mspec module altogether. Then the mspec itself would have to be created.
After that I would suggest to create a new driver module and to have the parser, serializer and model code generated there. Inn that project it would probably be best to create a parser-serializer test first to check if your mspec correctly decodes and encodes given protocol payload (I usually use a wireshark recording to get some example message payload). As soon as that's done, you need to add the protocol logic itself. But I guess I'd probably do the first steps before worrying about that. Just tell me if you need any help getting started. Chris Am 09.03.20, 14:14 schrieb "Etienne Robinet" <[email protected]>: Hi Chris, I would be pleased to help you on that! As I am fearly new, I just wanted to make sure: what are the steps to port it to the generated driver? Is there only the mspec file or something more needs tweaking? Etienne On 2020/03/09 10:58:33, Christofer Dutz <[email protected]> wrote: > H Etienne, > > I just wanted to post that to me it looks as your findings correlate to the EIP EtherNet/IP protocol, which is a different protocol. > > As I said ... EIP isn't ported yet as we would have to write the entire mspec first. That is on my personal list, but currently there's more in front of this list. If you want to get started on implementing it, we'll be more than happy to help. > > Chris > > > > > > > Am 09.03.20, 11:53 schrieb "Etienne Robinet" <[email protected]>: > > Sorry for the spam, > It seems like PLC4X uses DF1 Messages to communicate with the PLC. From the wireshark dumps from the library of my colleague and Studio500, this is not the protocol used by the PLC. I have an implementation of CIP encapsulation working, but it takes the backpane, slot and the tag(as String) you want to access and then sending it with a Service code(read/write). Been trying to work with the mspec but with no results for now. You guys think I should go back to 0.6 and hardcode it? Doesn't seem to be the best option for me thoough. > > Etienne > > On 2020/03/09 09:37:28, Etienne Robinet <[email protected]> wrote: > > Hi again, > > I managed to decapsulate the RegisterSession response from the PLC. The problem here is that the Register Session request and response have the same Command (0x0065) and the response only has the attributed Session Handler Number needed for the read/write request. > > From what I see there is no Service Handler for a ConnectionRequest (the response gets read as a request since the command number is equal). > > > > Should I add a Service Handler for it (and how?) because the only thing we need is the SessionHandle, or how do I manage to make him acknowledge the Response and not the request? > > > > Etienne > > > > On 2020/03/08 09:56:52, Julian Feinauer <[email protected]> wrote: > > > 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 > > > >>>>>> > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>> > > > >>>> > > > >>>> > > > >>> > > > >> > > > > > > > > > > > > > > > > > > > > > > > >
