You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@plc4x.apache.org by Ben Hutcheson <be...@gmail.com> on 2021/08/15 20:04:25 UTC
Modbus RTU
Just looking at implementing Modbus RTU and have a couple of options around
it's structure, that I wanted to get opinions on.
The protocol uses two main data structures, an ADU and a PDU. The PDU is
the main part of modbus and has all the function codes and data included in
it. This is the same for modbus tcp and rtu. The ADU wraps the PDU to
provide additional data such as address and CRC fields.
RTU is very similar to modbus TCP with only the ADU format changing that
wraps the PDU. As it is very similar it could be possible to reuse the
existing mspec with the addition of an RTU ADU. And then use this ADU in
the RTU protocol logic.
The protocol logic I think is going to be different enough to warrant an
entirely new version as opposed to implementing switches in the current
logic, which I think could get confusing very quickly. It also has the
added benefit of allowing odd specs like Modbus RTU over TCP trivially.
The protocol identifier I'm looking at using is modbus-rtu. I dislike it as
the original modbus tcp one is just modbus and not modbus-tcp. But figured
it's the better option.
Ben
Re: Modbus RTU
Posted by Niclas Hedhman <ni...@hedhman.org>.
On 2021-08-16 00:16, Ben Hutcheson wrote:
> Niclas, For floating point and large integers, this is already
> supported,
> where we serialized/parse multiple modbus registers to the different
> data
> types. You should be able to use something like 40001:REAL as the
> Address
> field.
Excellent!
Niclas
Re: Modbus RTU
Posted by Ben Hutcheson <be...@gmail.com>.
Thanks Łukasz, I’ll take a look at the stack configurator, might take some
time to understand it.
I’m assuming that would result in having it all under the same maven module.
Niclas, For floating point and large integers, this is already supported,
where we serialized/parse multiple modbus registers to the different data
types. You should be able to use something like 40001:REAL as the Address
field.
On Mon, Aug 16, 2021 at 7:49 AM Niclas Hedhman <ni...@hedhman.org> wrote:
> On 2021-08-15 22:40, Łukasz Dywicki wrote:
> > Then each driver flavor of modbus (rtu, ascii, tcp) would simply need
> > to
> > wrap and unwrap structures coming from an transport.
>
> I have come across a lot of Modbus over the years, but I can't recall
> seeing the ascii variant since the 1980s or early 1990s. IIUIC, it was
> mostly used for hand terminals, and not to connect to computers.
> So I wouldn't spend time on that, unless nothing else is around.
>
> I haven't checked the mspec in details, but I suspect it is close to
> formal specification. But I would like to bring attention to that a fair
> amount of equipment has extensions that are not in the specification
> (well, at least last time I read it about 20 years ago), namely floating
> point numbers and 32/64-bit integers. It would be neat to support
> that...
>
> Unfortunately, I don't have cycles to help out with it.
>
> Cheers
> Niclas
>
Re: AW: Modbus RTU
Posted by Łukasz Dywicki <lu...@code-house.org>.
Hey Stephen,
It really depends how you copied the repository.
Have a look on output of "git remote -v" command.
For me its:
connectorio git@github.com:ConnectorIO/plc4x.git (fetch)
connectorio git@github.com:ConnectorIO/plc4x.git (push)
origin git@github.com:apache/plc4x.git (fetch)
origin git@github.com:apache/plc4x.git (push)
Each time when I do git fetch or pull it defaults to "origin". If your
origin points your github fork then you might not see all branches
immediately.
I believe that quickest and dirtiest way is to do:
git remote add plc4x git@github.com:apache/plc4x.git
git fetch plc4x
git checkout feature/modbusrtu
Best,
Łukasz
On 18.08.2021 14:56, Stephen Snow wrote:
> Hi Ben,
> I forked the repo, actually had it forked for snapshot 0.7.0 so just
> had to merge the commits from the repo.
>
> On Wed, 2021-08-18 at 07:12 +1000, Ben Hutcheson wrote:
>> Hi Stephen,
>>
>> I have pushed support for RTU to the branch feature/modbusrtu, it
>> seems to
>> work. I've only used RTU over TCP using the connection string
>> modbus-rtu:tcp://127.0.0.1:502. There is also a few things to update
>> docs,
>> test and refactoring.
>>
>> Until it gets merged into the develop branch it won't appear in the
>> 0.9.0-SNAPSHOT so you'll have to build the feature/modbusrtu branch
>> using
>
> I couldn't find that branch listed. I see 48 branches in my fork.
>
>> maven. Once you have built it then it will get stored in your maven
>> repository cache as the 0.9.0-SNAPSHOT
>>
>> As you are looking at contributing you should take a look at
>> https://plc4x.apache.org/developers/contributing.html
>> This gives you an overview of how to fork the main repository and
>> keep it
>> up to date.
>>
>> Once you have it forked then you should be able to update your copy
>> and
>> push the changes to your fork. This should then request you to create
>> a PR
>> (You can change it to push to the feature/modbusrtu branch on the
>> main
>> repository) which we can review. A simple change if you want to test
>> it
>> would be to add a Modbus RTU ascii doc to the folder
>> src/site/asciidoc/users/protocols folder based on the existing Modbus
>> TCP
>> page.
>>
>> There's plenty of people activate that are generally more than happy
>> to
>> help if you have any questions
>>
>> Ben
>>
>>
> Any thoughts?
> Stephen
>
>> On Tue, Aug 17, 2021 at 10:45 PM Stephen Snow <s4...@gmail.com>
>> wrote:
>>
>>> Hi Ben,
>>>
>>> On Tue, 2021-08-17 at 06:50 +1000, Ben Hutcheson wrote:
>>>> Hi Stephen,
>>>>
>>>> Thank you for the offer and if it's ok I'll certainly take you up
>>>> on
>>>> it.
>>>>
>>> Sure, what snapshot should I point maven to? Currently I have 0.8.0
>>> that I was playing with a bit yesterday.
>>>
>>>> Next week I'll be starting a new job so I won't be contributing
>>>> for a
>>>> while, However I'll try and get something up and running this
>>>> week.
>>>> If you
>>>> are able to test it and/or take over the implementation from
>>>> there it
>>>> would
>>>> be great.
>>> Should I fork the repo? Where do I look for the directions on PR's
>>> etc...?
>>>
>>> Stephen
>>>
>>>>
>>>> Ben
>>>>
>>>> On Tue, Aug 17, 2021 at 4:25 AM Stephen Snow <s4...@gmail.com>
>>>> wrote:
>>>>
>>>>> I'd be more than willing to setup some equipment for a lab to
>>>>> test
>>>>> with. Readily available to me are a couple of Omron CP1-H CPU's
>>>>> and
>>>>> a
>>>>> Red Lion G3800C (which is outdated, but communicates with
>>>>> everything
>>>>> ootb), plus I can easily get some Modicon stuff as well. The
>>>>> Omrons
>>>>> are
>>>>> fitted with serial ports capable of communicating RS-485 in
>>>>> modbus
>>>>> RTU,
>>>>> and the RLC HMI can talk Modbus TCP as well, so that is without
>>>>> laying
>>>>> my hands on some Modicon equipment.
>>>>>
>>>>> Let me know, and I can start pretty much as soon as I clear
>>>>> space
>>>>> on my
>>>>> lab bench for the setup.
>>>>>
>>>>> Stephen
>>>>>
>>>>>
>>>>> On Mon, 2021-08-16 at 11:44 +0000, Christofer Dutz wrote:
>>>>>> Hi Stephen,
>>>>>>
>>>>>> it's not that we're dropping anything ... it's just that we
>>>>>> haven't
>>>>>> put any work into creating such a driver. Some day, if
>>>>>> someone
>>>>>> stumbles over PLC4X with the need to use ASCII, we might
>>>>>> implement it
>>>>>> for them (Mabe as a paid-gig or not).
>>>>>>
>>>>>> In the inital days of PLC4X I invested a huge amount of time
>>>>>> into
>>>>>> thinking what the industry could need ... I switched to the
>>>>>> way
>>>>>> more
>>>>>> healthy mode of implementing was is actually needed and when
>>>>>> it's
>>>>>> needed.
>>>>>>
>>>>>> But I agree ... Modbus TCP, Modbus RTU (over RS or TCP) are
>>>>>> definitely flavors we should be supporting.
>>>>>>
>>>>>> Chris
>>>>>>
>>>>>>
>>>>>> -----Ursprüngliche Nachricht-----
>>>>>> Von: Stephen Snow <s4...@gmail.com>
>>>>>> Gesendet: Montag, 16. August 2021 13:39
>>>>>> An: dev@plc4x.apache.org
>>>>>> Betreff: Re: Modbus RTU
>>>>>>
>>>>>> So I use modbus in all it's flavours, including modbusRTU and
>>>>>> Modbus
>>>>>> TCP. And the newer flavours Modicon is using now. Modbus RTU
>>>>>> is
>>>>>> definitely in heavy use on industrial equipment I encounter.
>>>>>> It
>>>>>> is
>>>>>> commonly a drive networking choice, and a HMI networking
>>>>>> choice.
>>>>>> So,
>>>>>> depending on what is using it ASCII is likely needed too. The
>>>>>> one
>>>>>> thing you don't want to do is drop ASCII.
>>>>>>
>>>>>> Regards,
>>>>>> Stephen
>>>>>>
>>>>>>
>>>>>> On Sun, 2021-08-15 at 23:48 +0200, Niclas Hedhman wrote:
>>>>>>> On 2021-08-15 22:40, Łukasz Dywicki wrote:
>>>>>>>> Then each driver flavor of modbus (rtu, ascii, tcp) would
>>>>>>>> simply
>>>>>>>> need to wrap and unwrap structures coming from an
>>>>>>>> transport.
>>>>>>>
>>>>>>> seeing the ascii variant since the 1980s or early 1990s.
>>>>>>> IIUIC,
>>>>>>> it
>>>>>>> was
>>>>>>> mostly used for hand terminals, and not to connect to
>>>>>>> computers.
>>>>>>> So I wouldn't spend time on that, unless nothing else is
>>>>>>> around.
>>>>>>>
>>>>>>> I haven't checked the mspec in details, but I suspect it is
>>>>>>> close
>>>>>>> to
>>>>>>> fair amount of equipment has extensions that are not in the
>>>>>>> specification (well, at least last time I read it about 20
>>>>>>> years
>>>>>>> ago),
>>>>>>> namely floating point numbers and 32/64-bit integers. It
>>>>>>> would
>>>>>>> be
>>>>>>> neat
>>>>>>> to support that...
>>>>>>>
>>>>>>> Unfortunately, I don't have cycles to help out with it.
>>>>>>>
>>>>>>> Cheers
>>>>>>> Niclas
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>
>
Re: AW: Modbus RTU
Posted by Stephen Snow <s4...@gmail.com>.
Hi Ben,
I forked the repo, actually had it forked for snapshot 0.7.0 so just
had to merge the commits from the repo.
On Wed, 2021-08-18 at 07:12 +1000, Ben Hutcheson wrote:
> Hi Stephen,
>
> I have pushed support for RTU to the branch feature/modbusrtu, it
> seems to
> work. I've only used RTU over TCP using the connection string
> modbus-rtu:tcp://127.0.0.1:502. There is also a few things to update
> docs,
> test and refactoring.
>
> Until it gets merged into the develop branch it won't appear in the
> 0.9.0-SNAPSHOT so you'll have to build the feature/modbusrtu branch
> using
I couldn't find that branch listed. I see 48 branches in my fork.
> maven. Once you have built it then it will get stored in your maven
> repository cache as the 0.9.0-SNAPSHOT
>
> As you are looking at contributing you should take a look at
> https://plc4x.apache.org/developers/contributing.html
> This gives you an overview of how to fork the main repository and
> keep it
> up to date.
>
> Once you have it forked then you should be able to update your copy
> and
> push the changes to your fork. This should then request you to create
> a PR
> (You can change it to push to the feature/modbusrtu branch on the
> main
> repository) which we can review. A simple change if you want to test
> it
> would be to add a Modbus RTU ascii doc to the folder
> src/site/asciidoc/users/protocols folder based on the existing Modbus
> TCP
> page.
>
> There's plenty of people activate that are generally more than happy
> to
> help if you have any questions
>
> Ben
>
>
Any thoughts?
Stephen
> On Tue, Aug 17, 2021 at 10:45 PM Stephen Snow <s4...@gmail.com>
> wrote:
>
> > Hi Ben,
> >
> > On Tue, 2021-08-17 at 06:50 +1000, Ben Hutcheson wrote:
> > > Hi Stephen,
> > >
> > > Thank you for the offer and if it's ok I'll certainly take you up
> > > on
> > > it.
> > >
> > Sure, what snapshot should I point maven to? Currently I have 0.8.0
> > that I was playing with a bit yesterday.
> >
> > > Next week I'll be starting a new job so I won't be contributing
> > > for a
> > > while, However I'll try and get something up and running this
> > > week.
> > > If you
> > > are able to test it and/or take over the implementation from
> > > there it
> > > would
> > > be great.
> > Should I fork the repo? Where do I look for the directions on PR's
> > etc...?
> >
> > Stephen
> >
> > >
> > > Ben
> > >
> > > On Tue, Aug 17, 2021 at 4:25 AM Stephen Snow <s4...@gmail.com>
> > > wrote:
> > >
> > > > I'd be more than willing to setup some equipment for a lab to
> > > > test
> > > > with. Readily available to me are a couple of Omron CP1-H CPU's
> > > > and
> > > > a
> > > > Red Lion G3800C (which is outdated, but communicates with
> > > > everything
> > > > ootb), plus I can easily get some Modicon stuff as well. The
> > > > Omrons
> > > > are
> > > > fitted with serial ports capable of communicating RS-485 in
> > > > modbus
> > > > RTU,
> > > > and the RLC HMI can talk Modbus TCP as well, so that is without
> > > > laying
> > > > my hands on some Modicon equipment.
> > > >
> > > > Let me know, and I can start pretty much as soon as I clear
> > > > space
> > > > on my
> > > > lab bench for the setup.
> > > >
> > > > Stephen
> > > >
> > > >
> > > > On Mon, 2021-08-16 at 11:44 +0000, Christofer Dutz wrote:
> > > > > Hi Stephen,
> > > > >
> > > > > it's not that we're dropping anything ... it's just that we
> > > > > haven't
> > > > > put any work into creating such a driver. Some day, if
> > > > > someone
> > > > > stumbles over PLC4X with the need to use ASCII, we might
> > > > > implement it
> > > > > for them (Mabe as a paid-gig or not).
> > > > >
> > > > > In the inital days of PLC4X I invested a huge amount of time
> > > > > into
> > > > > thinking what the industry could need ... I switched to the
> > > > > way
> > > > > more
> > > > > healthy mode of implementing was is actually needed and when
> > > > > it's
> > > > > needed.
> > > > >
> > > > > But I agree ... Modbus TCP, Modbus RTU (over RS or TCP) are
> > > > > definitely flavors we should be supporting.
> > > > >
> > > > > Chris
> > > > >
> > > > >
> > > > > -----Ursprüngliche Nachricht-----
> > > > > Von: Stephen Snow <s4...@gmail.com>
> > > > > Gesendet: Montag, 16. August 2021 13:39
> > > > > An: dev@plc4x.apache.org
> > > > > Betreff: Re: Modbus RTU
> > > > >
> > > > > So I use modbus in all it's flavours, including modbusRTU and
> > > > > Modbus
> > > > > TCP. And the newer flavours Modicon is using now. Modbus RTU
> > > > > is
> > > > > definitely in heavy use on industrial equipment I encounter.
> > > > > It
> > > > > is
> > > > > commonly a drive networking choice, and a HMI networking
> > > > > choice.
> > > > > So,
> > > > > depending on what is using it ASCII is likely needed too. The
> > > > > one
> > > > > thing you don't want to do is drop ASCII.
> > > > >
> > > > > Regards,
> > > > > Stephen
> > > > >
> > > > >
> > > > > On Sun, 2021-08-15 at 23:48 +0200, Niclas Hedhman wrote:
> > > > > > On 2021-08-15 22:40, Łukasz Dywicki wrote:
> > > > > > > Then each driver flavor of modbus (rtu, ascii, tcp) would
> > > > > > > simply
> > > > > > > need to wrap and unwrap structures coming from an
> > > > > > > transport.
> > > > > >
> > > > > > seeing the ascii variant since the 1980s or early 1990s.
> > > > > > IIUIC,
> > > > > > it
> > > > > > was
> > > > > > mostly used for hand terminals, and not to connect to
> > > > > > computers.
> > > > > > So I wouldn't spend time on that, unless nothing else is
> > > > > > around.
> > > > > >
> > > > > > I haven't checked the mspec in details, but I suspect it is
> > > > > > close
> > > > > > to
> > > > > > fair amount of equipment has extensions that are not in the
> > > > > > specification (well, at least last time I read it about 20
> > > > > > years
> > > > > > ago),
> > > > > > namely floating point numbers and 32/64-bit integers. It
> > > > > > would
> > > > > > be
> > > > > > neat
> > > > > > to support that...
> > > > > >
> > > > > > Unfortunately, I don't have cycles to help out with it.
> > > > > >
> > > > > > Cheers
> > > > > > Niclas
> > > > >
> > > > >
> > > >
> > > >
> > > >
> >
> >
> >
Re: AW: Modbus RTU
Posted by Stephen Snow <s4...@gmail.com>.
Thanks Ben,
I'll get set up and fork the branch you noted.
I'm sure I'll need some hand holding, but I'll try to not be much
bother.
Regards,
Stephen
On Wed, 2021-08-18 at 07:12 +1000, Ben Hutcheson wrote:
> Hi Stephen,
>
> I have pushed support for RTU to the branch feature/modbusrtu, it
> seems to
> work. I've only used RTU over TCP using the connection string
> modbus-rtu:tcp://127.0.0.1:502. There is also a few things to update
> docs,
> test and refactoring.
>
> Until it gets merged into the develop branch it won't appear in the
> 0.9.0-SNAPSHOT so you'll have to build the feature/modbusrtu branch
> using
> maven. Once you have built it then it will get stored in your maven
> repository cache as the 0.9.0-SNAPSHOT
>
> As you are looking at contributing you should take a look at
> https://plc4x.apache.org/developers/contributing.html
> This gives you an overview of how to fork the main repository and
> keep it
> up to date.
>
> Once you have it forked then you should be able to update your copy
> and
> push the changes to your fork. This should then request you to create
> a PR
> (You can change it to push to the feature/modbusrtu branch on the
> main
> repository) which we can review. A simple change if you want to test
> it
> would be to add a Modbus RTU ascii doc to the folder
> src/site/asciidoc/users/protocols folder based on the existing Modbus
> TCP
> page.
>
> There's plenty of people activate that are generally more than happy
> to
> help if you have any questions
>
> Ben
>
>
> On Tue, Aug 17, 2021 at 10:45 PM Stephen Snow <s4...@gmail.com>
> wrote:
>
> > Hi Ben,
> >
> > On Tue, 2021-08-17 at 06:50 +1000, Ben Hutcheson wrote:
> > > Hi Stephen,
> > >
> > > Thank you for the offer and if it's ok I'll certainly take you up
> > > on
> > > it.
> > >
> > Sure, what snapshot should I point maven to? Currently I have 0.8.0
> > that I was playing with a bit yesterday.
> >
> > > Next week I'll be starting a new job so I won't be contributing
> > > for a
> > > while, However I'll try and get something up and running this
> > > week.
> > > If you
> > > are able to test it and/or take over the implementation from
> > > there it
> > > would
> > > be great.
> > Should I fork the repo? Where do I look for the directions on PR's
> > etc...?
> >
> > Stephen
> >
> > >
> > > Ben
> > >
> > > On Tue, Aug 17, 2021 at 4:25 AM Stephen Snow <s4...@gmail.com>
> > > wrote:
> > >
> > > > I'd be more than willing to setup some equipment for a lab to
> > > > test
> > > > with. Readily available to me are a couple of Omron CP1-H CPU's
> > > > and
> > > > a
> > > > Red Lion G3800C (which is outdated, but communicates with
> > > > everything
> > > > ootb), plus I can easily get some Modicon stuff as well. The
> > > > Omrons
> > > > are
> > > > fitted with serial ports capable of communicating RS-485 in
> > > > modbus
> > > > RTU,
> > > > and the RLC HMI can talk Modbus TCP as well, so that is without
> > > > laying
> > > > my hands on some Modicon equipment.
> > > >
> > > > Let me know, and I can start pretty much as soon as I clear
> > > > space
> > > > on my
> > > > lab bench for the setup.
> > > >
> > > > Stephen
> > > >
> > > >
> > > > On Mon, 2021-08-16 at 11:44 +0000, Christofer Dutz wrote:
> > > > > Hi Stephen,
> > > > >
> > > > > it's not that we're dropping anything ... it's just that we
> > > > > haven't
> > > > > put any work into creating such a driver. Some day, if
> > > > > someone
> > > > > stumbles over PLC4X with the need to use ASCII, we might
> > > > > implement it
> > > > > for them (Mabe as a paid-gig or not).
> > > > >
> > > > > In the inital days of PLC4X I invested a huge amount of time
> > > > > into
> > > > > thinking what the industry could need ... I switched to the
> > > > > way
> > > > > more
> > > > > healthy mode of implementing was is actually needed and when
> > > > > it's
> > > > > needed.
> > > > >
> > > > > But I agree ... Modbus TCP, Modbus RTU (over RS or TCP) are
> > > > > definitely flavors we should be supporting.
> > > > >
> > > > > Chris
> > > > >
> > > > >
> > > > > -----Ursprüngliche Nachricht-----
> > > > > Von: Stephen Snow <s4...@gmail.com>
> > > > > Gesendet: Montag, 16. August 2021 13:39
> > > > > An: dev@plc4x.apache.org
> > > > > Betreff: Re: Modbus RTU
> > > > >
> > > > > So I use modbus in all it's flavours, including modbusRTU and
> > > > > Modbus
> > > > > TCP. And the newer flavours Modicon is using now. Modbus RTU
> > > > > is
> > > > > definitely in heavy use on industrial equipment I encounter.
> > > > > It
> > > > > is
> > > > > commonly a drive networking choice, and a HMI networking
> > > > > choice.
> > > > > So,
> > > > > depending on what is using it ASCII is likely needed too. The
> > > > > one
> > > > > thing you don't want to do is drop ASCII.
> > > > >
> > > > > Regards,
> > > > > Stephen
> > > > >
> > > > >
> > > > > On Sun, 2021-08-15 at 23:48 +0200, Niclas Hedhman wrote:
> > > > > > On 2021-08-15 22:40, Łukasz Dywicki wrote:
> > > > > > > Then each driver flavor of modbus (rtu, ascii, tcp) would
> > > > > > > simply
> > > > > > > need to wrap and unwrap structures coming from an
> > > > > > > transport.
> > > > > >
> > > > > > seeing the ascii variant since the 1980s or early 1990s.
> > > > > > IIUIC,
> > > > > > it
> > > > > > was
> > > > > > mostly used for hand terminals, and not to connect to
> > > > > > computers.
> > > > > > So I wouldn't spend time on that, unless nothing else is
> > > > > > around.
> > > > > >
> > > > > > I haven't checked the mspec in details, but I suspect it is
> > > > > > close
> > > > > > to
> > > > > > fair amount of equipment has extensions that are not in the
> > > > > > specification (well, at least last time I read it about 20
> > > > > > years
> > > > > > ago),
> > > > > > namely floating point numbers and 32/64-bit integers. It
> > > > > > would
> > > > > > be
> > > > > > neat
> > > > > > to support that...
> > > > > >
> > > > > > Unfortunately, I don't have cycles to help out with it.
> > > > > >
> > > > > > Cheers
> > > > > > Niclas
> > > > >
> > > > >
> > > >
> > > >
> > > >
> >
> >
> >
Re: AW: Modbus RTU
Posted by Ben Hutcheson <be...@gmail.com>.
Hi Stephen,
I have pushed support for RTU to the branch feature/modbusrtu, it seems to
work. I've only used RTU over TCP using the connection string
modbus-rtu:tcp://127.0.0.1:502. There is also a few things to update docs,
test and refactoring.
Until it gets merged into the develop branch it won't appear in the
0.9.0-SNAPSHOT so you'll have to build the feature/modbusrtu branch using
maven. Once you have built it then it will get stored in your maven
repository cache as the 0.9.0-SNAPSHOT
As you are looking at contributing you should take a look at
https://plc4x.apache.org/developers/contributing.html
This gives you an overview of how to fork the main repository and keep it
up to date.
Once you have it forked then you should be able to update your copy and
push the changes to your fork. This should then request you to create a PR
(You can change it to push to the feature/modbusrtu branch on the main
repository) which we can review. A simple change if you want to test it
would be to add a Modbus RTU ascii doc to the folder
src/site/asciidoc/users/protocols folder based on the existing Modbus TCP
page.
There's plenty of people activate that are generally more than happy to
help if you have any questions
Ben
On Tue, Aug 17, 2021 at 10:45 PM Stephen Snow <s4...@gmail.com> wrote:
> Hi Ben,
>
> On Tue, 2021-08-17 at 06:50 +1000, Ben Hutcheson wrote:
> > Hi Stephen,
> >
> > Thank you for the offer and if it's ok I'll certainly take you up on
> > it.
> >
> Sure, what snapshot should I point maven to? Currently I have 0.8.0
> that I was playing with a bit yesterday.
>
> > Next week I'll be starting a new job so I won't be contributing for a
> > while, However I'll try and get something up and running this week.
> > If you
> > are able to test it and/or take over the implementation from there it
> > would
> > be great.
> Should I fork the repo? Where do I look for the directions on PR's
> etc...?
>
> Stephen
>
> >
> > Ben
> >
> > On Tue, Aug 17, 2021 at 4:25 AM Stephen Snow <s4...@gmail.com>
> > wrote:
> >
> > > I'd be more than willing to setup some equipment for a lab to test
> > > with. Readily available to me are a couple of Omron CP1-H CPU's and
> > > a
> > > Red Lion G3800C (which is outdated, but communicates with
> > > everything
> > > ootb), plus I can easily get some Modicon stuff as well. The Omrons
> > > are
> > > fitted with serial ports capable of communicating RS-485 in modbus
> > > RTU,
> > > and the RLC HMI can talk Modbus TCP as well, so that is without
> > > laying
> > > my hands on some Modicon equipment.
> > >
> > > Let me know, and I can start pretty much as soon as I clear space
> > > on my
> > > lab bench for the setup.
> > >
> > > Stephen
> > >
> > >
> > > On Mon, 2021-08-16 at 11:44 +0000, Christofer Dutz wrote:
> > > > Hi Stephen,
> > > >
> > > > it's not that we're dropping anything ... it's just that we
> > > > haven't
> > > > put any work into creating such a driver. Some day, if someone
> > > > stumbles over PLC4X with the need to use ASCII, we might
> > > > implement it
> > > > for them (Mabe as a paid-gig or not).
> > > >
> > > > In the inital days of PLC4X I invested a huge amount of time into
> > > > thinking what the industry could need ... I switched to the way
> > > > more
> > > > healthy mode of implementing was is actually needed and when it's
> > > > needed.
> > > >
> > > > But I agree ... Modbus TCP, Modbus RTU (over RS or TCP) are
> > > > definitely flavors we should be supporting.
> > > >
> > > > Chris
> > > >
> > > >
> > > > -----Ursprüngliche Nachricht-----
> > > > Von: Stephen Snow <s4...@gmail.com>
> > > > Gesendet: Montag, 16. August 2021 13:39
> > > > An: dev@plc4x.apache.org
> > > > Betreff: Re: Modbus RTU
> > > >
> > > > So I use modbus in all it's flavours, including modbusRTU and
> > > > Modbus
> > > > TCP. And the newer flavours Modicon is using now. Modbus RTU is
> > > > definitely in heavy use on industrial equipment I encounter. It
> > > > is
> > > > commonly a drive networking choice, and a HMI networking choice.
> > > > So,
> > > > depending on what is using it ASCII is likely needed too. The one
> > > > thing you don't want to do is drop ASCII.
> > > >
> > > > Regards,
> > > > Stephen
> > > >
> > > >
> > > > On Sun, 2021-08-15 at 23:48 +0200, Niclas Hedhman wrote:
> > > > > On 2021-08-15 22:40, Łukasz Dywicki wrote:
> > > > > > Then each driver flavor of modbus (rtu, ascii, tcp) would
> > > > > > simply
> > > > > > need to wrap and unwrap structures coming from an transport.
> > > > >
> > > > > seeing the ascii variant since the 1980s or early 1990s. IIUIC,
> > > > > it
> > > > > was
> > > > > mostly used for hand terminals, and not to connect to
> > > > > computers.
> > > > > So I wouldn't spend time on that, unless nothing else is
> > > > > around.
> > > > >
> > > > > I haven't checked the mspec in details, but I suspect it is
> > > > > close
> > > > > to
> > > > > fair amount of equipment has extensions that are not in the
> > > > > specification (well, at least last time I read it about 20
> > > > > years
> > > > > ago),
> > > > > namely floating point numbers and 32/64-bit integers. It would
> > > > > be
> > > > > neat
> > > > > to support that...
> > > > >
> > > > > Unfortunately, I don't have cycles to help out with it.
> > > > >
> > > > > Cheers
> > > > > Niclas
> > > >
> > > >
> > >
> > >
> > >
>
>
>
Re: AW: Modbus RTU
Posted by Stephen Snow <s4...@gmail.com>.
Hi Ben,
On Tue, 2021-08-17 at 06:50 +1000, Ben Hutcheson wrote:
> Hi Stephen,
>
> Thank you for the offer and if it's ok I'll certainly take you up on
> it.
>
Sure, what snapshot should I point maven to? Currently I have 0.8.0
that I was playing with a bit yesterday.
> Next week I'll be starting a new job so I won't be contributing for a
> while, However I'll try and get something up and running this week.
> If you
> are able to test it and/or take over the implementation from there it
> would
> be great.
Should I fork the repo? Where do I look for the directions on PR's
etc...?
Stephen
>
> Ben
>
> On Tue, Aug 17, 2021 at 4:25 AM Stephen Snow <s4...@gmail.com>
> wrote:
>
> > I'd be more than willing to setup some equipment for a lab to test
> > with. Readily available to me are a couple of Omron CP1-H CPU's and
> > a
> > Red Lion G3800C (which is outdated, but communicates with
> > everything
> > ootb), plus I can easily get some Modicon stuff as well. The Omrons
> > are
> > fitted with serial ports capable of communicating RS-485 in modbus
> > RTU,
> > and the RLC HMI can talk Modbus TCP as well, so that is without
> > laying
> > my hands on some Modicon equipment.
> >
> > Let me know, and I can start pretty much as soon as I clear space
> > on my
> > lab bench for the setup.
> >
> > Stephen
> >
> >
> > On Mon, 2021-08-16 at 11:44 +0000, Christofer Dutz wrote:
> > > Hi Stephen,
> > >
> > > it's not that we're dropping anything ... it's just that we
> > > haven't
> > > put any work into creating such a driver. Some day, if someone
> > > stumbles over PLC4X with the need to use ASCII, we might
> > > implement it
> > > for them (Mabe as a paid-gig or not).
> > >
> > > In the inital days of PLC4X I invested a huge amount of time into
> > > thinking what the industry could need ... I switched to the way
> > > more
> > > healthy mode of implementing was is actually needed and when it's
> > > needed.
> > >
> > > But I agree ... Modbus TCP, Modbus RTU (over RS or TCP) are
> > > definitely flavors we should be supporting.
> > >
> > > Chris
> > >
> > >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Stephen Snow <s4...@gmail.com>
> > > Gesendet: Montag, 16. August 2021 13:39
> > > An: dev@plc4x.apache.org
> > > Betreff: Re: Modbus RTU
> > >
> > > So I use modbus in all it's flavours, including modbusRTU and
> > > Modbus
> > > TCP. And the newer flavours Modicon is using now. Modbus RTU is
> > > definitely in heavy use on industrial equipment I encounter. It
> > > is
> > > commonly a drive networking choice, and a HMI networking choice.
> > > So,
> > > depending on what is using it ASCII is likely needed too. The one
> > > thing you don't want to do is drop ASCII.
> > >
> > > Regards,
> > > Stephen
> > >
> > >
> > > On Sun, 2021-08-15 at 23:48 +0200, Niclas Hedhman wrote:
> > > > On 2021-08-15 22:40, Łukasz Dywicki wrote:
> > > > > Then each driver flavor of modbus (rtu, ascii, tcp) would
> > > > > simply
> > > > > need to wrap and unwrap structures coming from an transport.
> > > >
> > > > seeing the ascii variant since the 1980s or early 1990s. IIUIC,
> > > > it
> > > > was
> > > > mostly used for hand terminals, and not to connect to
> > > > computers.
> > > > So I wouldn't spend time on that, unless nothing else is
> > > > around.
> > > >
> > > > I haven't checked the mspec in details, but I suspect it is
> > > > close
> > > > to
> > > > fair amount of equipment has extensions that are not in the
> > > > specification (well, at least last time I read it about 20
> > > > years
> > > > ago),
> > > > namely floating point numbers and 32/64-bit integers. It would
> > > > be
> > > > neat
> > > > to support that...
> > > >
> > > > Unfortunately, I don't have cycles to help out with it.
> > > >
> > > > Cheers
> > > > Niclas
> > >
> > >
> >
> >
> >
Re: AW: Modbus RTU
Posted by Ben Hutcheson <be...@gmail.com>.
Hi Stephen,
Thank you for the offer and if it's ok I'll certainly take you up on it.
Next week I'll be starting a new job so I won't be contributing for a
while, However I'll try and get something up and running this week. If you
are able to test it and/or take over the implementation from there it would
be great.
Ben
On Tue, Aug 17, 2021 at 4:25 AM Stephen Snow <s4...@gmail.com> wrote:
> I'd be more than willing to setup some equipment for a lab to test
> with. Readily available to me are a couple of Omron CP1-H CPU's and a
> Red Lion G3800C (which is outdated, but communicates with everything
> ootb), plus I can easily get some Modicon stuff as well. The Omrons are
> fitted with serial ports capable of communicating RS-485 in modbus RTU,
> and the RLC HMI can talk Modbus TCP as well, so that is without laying
> my hands on some Modicon equipment.
>
> Let me know, and I can start pretty much as soon as I clear space on my
> lab bench for the setup.
>
> Stephen
>
>
> On Mon, 2021-08-16 at 11:44 +0000, Christofer Dutz wrote:
> > Hi Stephen,
> >
> > it's not that we're dropping anything ... it's just that we haven't
> > put any work into creating such a driver. Some day, if someone
> > stumbles over PLC4X with the need to use ASCII, we might implement it
> > for them (Mabe as a paid-gig or not).
> >
> > In the inital days of PLC4X I invested a huge amount of time into
> > thinking what the industry could need ... I switched to the way more
> > healthy mode of implementing was is actually needed and when it's
> > needed.
> >
> > But I agree ... Modbus TCP, Modbus RTU (over RS or TCP) are
> > definitely flavors we should be supporting.
> >
> > Chris
> >
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Stephen Snow <s4...@gmail.com>
> > Gesendet: Montag, 16. August 2021 13:39
> > An: dev@plc4x.apache.org
> > Betreff: Re: Modbus RTU
> >
> > So I use modbus in all it's flavours, including modbusRTU and Modbus
> > TCP. And the newer flavours Modicon is using now. Modbus RTU is
> > definitely in heavy use on industrial equipment I encounter. It is
> > commonly a drive networking choice, and a HMI networking choice. So,
> > depending on what is using it ASCII is likely needed too. The one
> > thing you don't want to do is drop ASCII.
> >
> > Regards,
> > Stephen
> >
> >
> > On Sun, 2021-08-15 at 23:48 +0200, Niclas Hedhman wrote:
> > > On 2021-08-15 22:40, Łukasz Dywicki wrote:
> > > > Then each driver flavor of modbus (rtu, ascii, tcp) would simply
> > > > need to wrap and unwrap structures coming from an transport.
> > >
> > > seeing the ascii variant since the 1980s or early 1990s. IIUIC, it
> > > was
> > > mostly used for hand terminals, and not to connect to computers.
> > > So I wouldn't spend time on that, unless nothing else is around.
> > >
> > > I haven't checked the mspec in details, but I suspect it is close
> > > to
> > > fair amount of equipment has extensions that are not in the
> > > specification (well, at least last time I read it about 20 years
> > > ago),
> > > namely floating point numbers and 32/64-bit integers. It would be
> > > neat
> > > to support that...
> > >
> > > Unfortunately, I don't have cycles to help out with it.
> > >
> > > Cheers
> > > Niclas
> >
> >
>
>
>
Re: AW: Modbus RTU
Posted by Stephen Snow <s4...@gmail.com>.
I'd be more than willing to setup some equipment for a lab to test
with. Readily available to me are a couple of Omron CP1-H CPU's and a
Red Lion G3800C (which is outdated, but communicates with everything
ootb), plus I can easily get some Modicon stuff as well. The Omrons are
fitted with serial ports capable of communicating RS-485 in modbus RTU,
and the RLC HMI can talk Modbus TCP as well, so that is without laying
my hands on some Modicon equipment.
Let me know, and I can start pretty much as soon as I clear space on my
lab bench for the setup.
Stephen
On Mon, 2021-08-16 at 11:44 +0000, Christofer Dutz wrote:
> Hi Stephen,
>
> it's not that we're dropping anything ... it's just that we haven't
> put any work into creating such a driver. Some day, if someone
> stumbles over PLC4X with the need to use ASCII, we might implement it
> for them (Mabe as a paid-gig or not).
>
> In the inital days of PLC4X I invested a huge amount of time into
> thinking what the industry could need ... I switched to the way more
> healthy mode of implementing was is actually needed and when it's
> needed.
>
> But I agree ... Modbus TCP, Modbus RTU (over RS or TCP) are
> definitely flavors we should be supporting.
>
> Chris
>
>
> -----Ursprüngliche Nachricht-----
> Von: Stephen Snow <s4...@gmail.com>
> Gesendet: Montag, 16. August 2021 13:39
> An: dev@plc4x.apache.org
> Betreff: Re: Modbus RTU
>
> So I use modbus in all it's flavours, including modbusRTU and Modbus
> TCP. And the newer flavours Modicon is using now. Modbus RTU is
> definitely in heavy use on industrial equipment I encounter. It is
> commonly a drive networking choice, and a HMI networking choice. So,
> depending on what is using it ASCII is likely needed too. The one
> thing you don't want to do is drop ASCII.
>
> Regards,
> Stephen
>
>
> On Sun, 2021-08-15 at 23:48 +0200, Niclas Hedhman wrote:
> > On 2021-08-15 22:40, Łukasz Dywicki wrote:
> > > Then each driver flavor of modbus (rtu, ascii, tcp) would simply
> > > need to wrap and unwrap structures coming from an transport.
> >
> > seeing the ascii variant since the 1980s or early 1990s. IIUIC, it
> > was
> > mostly used for hand terminals, and not to connect to computers.
> > So I wouldn't spend time on that, unless nothing else is around.
> >
> > I haven't checked the mspec in details, but I suspect it is close
> > to
> > fair amount of equipment has extensions that are not in the
> > specification (well, at least last time I read it about 20 years
> > ago),
> > namely floating point numbers and 32/64-bit integers. It would be
> > neat
> > to support that...
> >
> > Unfortunately, I don't have cycles to help out with it.
> >
> > Cheers
> > Niclas
>
>
AW: Modbus RTU
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi Stephen,
it's not that we're dropping anything ... it's just that we haven't put any work into creating such a driver. Some day, if someone stumbles over PLC4X with the need to use ASCII, we might implement it for them (Mabe as a paid-gig or not).
In the inital days of PLC4X I invested a huge amount of time into thinking what the industry could need ... I switched to the way more healthy mode of implementing was is actually needed and when it's needed.
But I agree ... Modbus TCP, Modbus RTU (over RS or TCP) are definitely flavors we should be supporting.
Chris
-----Ursprüngliche Nachricht-----
Von: Stephen Snow <s4...@gmail.com>
Gesendet: Montag, 16. August 2021 13:39
An: dev@plc4x.apache.org
Betreff: Re: Modbus RTU
So I use modbus in all it's flavours, including modbusRTU and Modbus TCP. And the newer flavours Modicon is using now. Modbus RTU is definitely in heavy use on industrial equipment I encounter. It is commonly a drive networking choice, and a HMI networking choice. So, depending on what is using it ASCII is likely needed too. The one thing you don't want to do is drop ASCII.
Regards,
Stephen
On Sun, 2021-08-15 at 23:48 +0200, Niclas Hedhman wrote:
> On 2021-08-15 22:40, Łukasz Dywicki wrote:
> > Then each driver flavor of modbus (rtu, ascii, tcp) would simply
> > need to wrap and unwrap structures coming from an transport.
>
> seeing the ascii variant since the 1980s or early 1990s. IIUIC, it was
> mostly used for hand terminals, and not to connect to computers.
> So I wouldn't spend time on that, unless nothing else is around.
>
> I haven't checked the mspec in details, but I suspect it is close to
> formal specification. But I would like to bring attention to that a
> fair amount of equipment has extensions that are not in the
> specification (well, at least last time I read it about 20 years ago),
> namely floating point numbers and 32/64-bit integers. It would be neat
> to support that...
>
> Unfortunately, I don't have cycles to help out with it.
>
> Cheers
> Niclas
Re: Modbus RTU
Posted by Stephen Snow <s4...@gmail.com>.
So I use modbus in all it's flavours, including modbusRTU and Modbus
TCP. And the newer flavours Modicon is using now. Modbus RTU is
definitely in heavy use on industrial equipment I encounter. It is
commonly a drive networking choice, and a HMI networking choice. So,
depending on what is using it ASCII is likely needed too. The one thing
you don't want to do is drop ASCII.
Regards,
Stephen
On Sun, 2021-08-15 at 23:48 +0200, Niclas Hedhman wrote:
> On 2021-08-15 22:40, Łukasz Dywicki wrote:
> > Then each driver flavor of modbus (rtu, ascii, tcp) would simply
> > need
> > to
> > wrap and unwrap structures coming from an transport.
>
> seeing the ascii variant since the 1980s or early 1990s. IIUIC, it
> was
> mostly used for hand terminals, and not to connect to computers.
> So I wouldn't spend time on that, unless nothing else is around.
>
> I haven't checked the mspec in details, but I suspect it is close to
> formal specification. But I would like to bring attention to that a
> fair
> amount of equipment has extensions that are not in the specification
> (well, at least last time I read it about 20 years ago), namely
> floating
> point numbers and 32/64-bit integers. It would be neat to support
> that...
>
> Unfortunately, I don't have cycles to help out with it.
>
> Cheers
> Niclas
Re: Modbus RTU
Posted by Niclas Hedhman <ni...@hedhman.org>.
On 2021-08-15 22:40, Łukasz Dywicki wrote:
> Then each driver flavor of modbus (rtu, ascii, tcp) would simply need
> to
> wrap and unwrap structures coming from an transport.
I have come across a lot of Modbus over the years, but I can't recall
seeing the ascii variant since the 1980s or early 1990s. IIUIC, it was
mostly used for hand terminals, and not to connect to computers.
So I wouldn't spend time on that, unless nothing else is around.
I haven't checked the mspec in details, but I suspect it is close to
formal specification. But I would like to bring attention to that a fair
amount of equipment has extensions that are not in the specification
(well, at least last time I read it about 20 years ago), namely floating
point numbers and 32/64-bit integers. It would be neat to support
that...
Unfortunately, I don't have cycles to help out with it.
Cheers
Niclas
Re: Modbus RTU
Posted by Christofer Dutz <ch...@c-ware.de>.
And I think the RTU Adu is already defined in the modbus mspec. It's just not used right now. As far as I remember it's the first datatype right at the top.
I would also opt for the option with a second driver, but in the same maven module. We could add modbus-tcp as an alias for modbus, die keeping the naming more consistent (the TCP Variant being the more modern one)
Chris
Holen Sie sich Outlook für Android<https://aka.ms/AAb9ysg>
________________________________
From: Łukasz Dywicki <lu...@code-house.org>
Sent: Sunday, August 15, 2021 10:40:37 PM
To: dev@plc4x.apache.org <de...@plc4x.apache.org>
Subject: Re: Modbus RTU
I think that in some ways what you described defines a close form of
"canonical" modbus. We know that modbus uses PDU and A(P)DU with some
info about function code and data blocks. We could simply update
protocol logic to rely on these *without* relying on specific encoding.
Then each driver flavor of modbus (rtu, ascii, tcp) would simply need to
wrap and unwrap structures coming from an transport.
Please have a look on stack configurer changes (currently stuck in
can-stack-tunning feature branch):
https://github.com/apache/plc4x/blob/2530287ec3982bb685700e76e956a0141ebc45cd/plc4j/drivers/canopen/src/main/java/org/apache/plc4x/java/canopen/CANOpenPlcDriver.java#L126L139
Changes which Sebastian helped me with in May this year will allow you
to customize protocol instantiation. Effectively it opens a path to
chain or wrap protocol logic needed by driver.
I believe that it is essential to keep protocol logic unified and
encoding/decoding separated. If we will need to copy logic for each
modbus flavor then very soon we will have more than 3 drivers only for that.
Not that I am against of supporting all of them. I am just afraid that
we might get into trouble making them consistent.
Cheers,
Łukasz
On 15.08.2021 22:04, Ben Hutcheson wrote:
> Just looking at implementing Modbus RTU and have a couple of options around
> it's structure, that I wanted to get opinions on.
>
> The protocol uses two main data structures, an ADU and a PDU. The PDU is
> the main part of modbus and has all the function codes and data included in
> it. This is the same for modbus tcp and rtu. The ADU wraps the PDU to
> provide additional data such as address and CRC fields.
>
> RTU is very similar to modbus TCP with only the ADU format changing that
> wraps the PDU. As it is very similar it could be possible to reuse the
> existing mspec with the addition of an RTU ADU. And then use this ADU in
> the RTU protocol logic.
>
> The protocol logic I think is going to be different enough to warrant an
> entirely new version as opposed to implementing switches in the current
> logic, which I think could get confusing very quickly. It also has the
> added benefit of allowing odd specs like Modbus RTU over TCP trivially.
>
> The protocol identifier I'm looking at using is modbus-rtu. I dislike it as
> the original modbus tcp one is just modbus and not modbus-tcp. But figured
> it's the better option.
>
> Ben
>
Re: Modbus RTU
Posted by Łukasz Dywicki <lu...@code-house.org>.
I think that in some ways what you described defines a close form of
"canonical" modbus. We know that modbus uses PDU and A(P)DU with some
info about function code and data blocks. We could simply update
protocol logic to rely on these *without* relying on specific encoding.
Then each driver flavor of modbus (rtu, ascii, tcp) would simply need to
wrap and unwrap structures coming from an transport.
Please have a look on stack configurer changes (currently stuck in
can-stack-tunning feature branch):
https://github.com/apache/plc4x/blob/2530287ec3982bb685700e76e956a0141ebc45cd/plc4j/drivers/canopen/src/main/java/org/apache/plc4x/java/canopen/CANOpenPlcDriver.java#L126L139
Changes which Sebastian helped me with in May this year will allow you
to customize protocol instantiation. Effectively it opens a path to
chain or wrap protocol logic needed by driver.
I believe that it is essential to keep protocol logic unified and
encoding/decoding separated. If we will need to copy logic for each
modbus flavor then very soon we will have more than 3 drivers only for that.
Not that I am against of supporting all of them. I am just afraid that
we might get into trouble making them consistent.
Cheers,
Łukasz
On 15.08.2021 22:04, Ben Hutcheson wrote:
> Just looking at implementing Modbus RTU and have a couple of options around
> it's structure, that I wanted to get opinions on.
>
> The protocol uses two main data structures, an ADU and a PDU. The PDU is
> the main part of modbus and has all the function codes and data included in
> it. This is the same for modbus tcp and rtu. The ADU wraps the PDU to
> provide additional data such as address and CRC fields.
>
> RTU is very similar to modbus TCP with only the ADU format changing that
> wraps the PDU. As it is very similar it could be possible to reuse the
> existing mspec with the addition of an RTU ADU. And then use this ADU in
> the RTU protocol logic.
>
> The protocol logic I think is going to be different enough to warrant an
> entirely new version as opposed to implementing switches in the current
> logic, which I think could get confusing very quickly. It also has the
> added benefit of allowing odd specs like Modbus RTU over TCP trivially.
>
> The protocol identifier I'm looking at using is modbus-rtu. I dislike it as
> the original modbus tcp one is just modbus and not modbus-tcp. But figured
> it's the better option.
>
> Ben
>