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
>     > > >>>>>>
>     > > >>>>>
>     > > >>>>>
>     > > >>>>>
>     > > >>>>
>     > > >>>>
>     > > >>>>
>     > > >>>
>     > > >>
>     > > >
>     > > >
>     > > >
>     > > >
>     > > 
>     > 
>     
> 
> 

Reply via email to