Hi Chris,
so that will be the EIP protocol? We stay with the AB protocol using DF1 on 
port 222?
I will start and try and let you know when I'm stuck, thanks for the help.

Etienne
On 2020/03/09 14:39:32, Christofer Dutz <[email protected]> wrote: 
> 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
>     >     > > >>>>>>
>     >     > > >>>>>
>     >     > > >>>>>
>     >     > > >>>>>
>     >     > > >>>>
>     >     > > >>>>
>     >     > > >>>>
>     >     > > >>>
>     >     > > >>
>     >     > > >
>     >     > > >
>     >     > > >
>     >     > > >
>     >     > > 
>     >     > 
>     >     
>     > 
>     > 
>     
> 
> 

Reply via email to