Re: Supporting different layers of protocols depending on the used transport

2020-09-02 Thread Christofer Dutz
Well I think there ist sort of protocol level logic and transport level logic. Both usually don't really have much in common. For example for every serial packet the serial transport logic waits for an ack message and if this doesn't come in a given time Re sends the packet. I wouldn't want to

Re: Supporting different layers of protocols depending on the used transport

2020-09-02 Thread Łukasz Dywicki
Maybe a bit of idea.. I think we have abstract fields (not sure if types). Can we align both AmsData kinds somehow? After all the role of transport is to ship payload and all we want do do is unification of these at certain level in order to implement logic just once. From high level point of vie

Re: Leaking nioEventLoopGroup threads

2020-09-02 Thread Adam Rossi
Hi Julian. I would like to submit a fix for this, but the relevant section of the code is tricky for me to understand. Basically, if the PooledPlcDriverManager is used with DefaultNettyPlcConnections, when code calls the "close" method of the PlcConnection, the "close" method of the defaultNettyPl

Re: MODBUS over RTU configuration

2020-09-02 Thread Christofer Dutz
Well the PLC4X folks have just recently started working on a new initiative: PLC4PY (All PLC4X drivers in native Python implementations) Unfortunately I'm consumed with my PLC4C ... if you want to join them ... they would be happy about anyone helping. But if you want to get rid of Python (whic

Re: MODBUS over RTU configuration

2020-09-02 Thread Alessio Bernesco Làvore
Yes, in fact right now we are using a python edge system (written by ourselves) to connect, but i'd like to migrate it to java. We mainly interact with OPC-UA or ModBus devices but sometimes the latter are Serial 485 and so we need an RTU enabled driver. I'll constantly keep an eye on the list and

Re: MODBUS over RTU configuration

2020-09-02 Thread Christofer Dutz
Hi Alessio, thanks for volunteering to help with testing ... as Otto will agree ... testing stuff is sometimes a good thing to do ;-) Even if it's not highest priority for you, we should continue the discussion as this issue will come up sooner or later. Chris Am 02.09.20, 17:29 schrieb "Al

Re: [jira] [Created] (PLC4X-214) [Modbus] Holding register addresses have an offset of 1 (Not reading the correct address)

2020-09-02 Thread Christofer Dutz
Hi Ben, while I just updated the Modbus documentation I noticed your recent additions aren't documented anywhere. I could probably do it, but I would feel more comfortable if you could do so as you actually understand the stuff :-) Would be super awesome, if you could add the description of yo

Re: Supporting different layers of protocols depending on the used transport

2020-09-02 Thread Christofer Dutz
Hi ... bumping this thread back to life due to recent user-requests. __ @Julian ... would you be able to provide me with some empty extension stub to implement something like in below email? Perhaps we should have a "withDefaultTransportProtocol" too ... as we do have a lot of transports (tcp

Re: MODBUS over RTU configuration

2020-09-02 Thread Alessio Bernesco Làvore
Hello Chris, thank you! I'm currently using some exotic RTU devices, just for test, so mine is a low priority question. Of course i'm fully available to test any release against those devices. Greetings, Alessio On Wed, Sep 2, 2020 at 5:14 PM Christofer Dutz wrote: > Hi Alessio, > > welcome on

Re: MODBUS over RTU configuration

2020-09-02 Thread Christofer Dutz
Hi Alessio, welcome on this super-cool community list of ours :-) Unfortunately I have a little "uncool" news ... while working on the new drivers, it occurred to me that we currently are absolutely able to run one protocol over multiple transports, however if the transports require different

MODBUS over RTU configuration

2020-09-02 Thread Alessio Bernesco Làvore
Hi everyone, i'm trying to complete some tests connecting a Modbus RTU device (digital input converter). The device is connected using a USB/485 converter, running with pyModbus i'm able to communicate with the device. I'm using this connection string: PlcConnection plcConnection = new PlcDrive

Re: [MODBUS][DISCUSS] Improving handling of datatypes ...

2020-09-02 Thread Christofer Dutz
Hi Julian, I agree ... if one driver would define an "INT" as 32bit integer and the others would treat it as 16bit ... that could be a problem. Perhaps having a statement of the project that we use the IEC 61131 types as a basis and if you want to use a given protocols different types, that you

Re: [MODBUS][DISCUSS] Improving handling of datatypes ...

2020-09-02 Thread Julian Feinauer
Hi, agree with your suggestion! Although we have to be careful to not mix it up with specific implementations of datatypes in some drivers. Julian Am 02.09.20, 15:21 schrieb "Christofer Dutz" : Hi all, today I was at a customer’s site and used the Modbus driver to get data. This gen

[MODBUS][DISCUSS] Improving handling of datatypes ...

2020-09-02 Thread Christofer Dutz
Hi all, today I was at a customer’s site and used the Modbus driver to get data. This generally worked fine. The thing however I found a little complicated, was that the PLC seemed to offer all values as 32Bit Floating point values. So in order to correctly read them, I had to read an array of t

[DRAFT] September Board Report

2020-09-02 Thread Christofer Dutz
Hi all … I just prepared our board report and saved it as a draft … please review and give feedback if you want me to add/remove/change things … Chris ## Description: The mission of the Apache PLC4X project is creating a set of libraries for communicating with industrial programmab