AW: Current status of the ADS protocol support

[Christofer Dutz <ch...@c-ware.de>]

Hi Jens,

picking up on this older discussion.

Since March I now have implemented the ADS protocol and did a pretty extensive manual test of all the datatypes. This version now supports multiple-reads in contrast to the 0.6 version however I haven’t implemented Publish/Subscribe (yet).

But regarding performance. I can probably guarantee that with normal OPC-UA you won’t get the performance you get from ADS/Modbus/S7/… One of my tests is even to read one item of every dataype single and then to do 100 reads with all types in random order. The performance of the ADS driver is clearly the best the S7 driver takes 4 times as long and the Modbus (given that it doesn’t support reading of multiple items in one request) is a lot slower. When reading only single items, I would expect Modbus to be fastest. Unfortunately I haven’t got an OPC-UA device ready for testing, but it would really be interesting how this would perform (However I would expect it to greatly differ, depending on the PLC it’s running on)

Chris

Von: Jens Vagts <je...@gmail.com>
Gesendet: Montag, 2. März 2020 13:15
An: Christofer Dutz <ch...@c-ware.de>
Cc: dev@plc4x.apache.org
Betreff: Re: Current status of the ADS protocol support

Hi Chris,

I will ask for some budget for improving the ADS driver, which should be possible, as soon as the priority is clear for us. Some colleagues are thinking about using OPC UA as single protocol for all our use cases, which I do not agree with, due to our pretty fast machines and the old existing PLCs to be supported.

Jens


Am Mo., 2. März 2020 um 08:28 Uhr schrieb Christofer Dutz <ch...@c-ware.de>>:
Hi Jens,

I can't do any estimation on this. Unfortunately the initial work on this was done by a colleague of mine. I will definitely work on this, but right now my focus is definitely to get the test coverage of all drivers back up. I have to do this as this work is nothing companies would want to pay for in paid gigs but I think it's essential for the project.

If the ads driver however has a high priority for you and your company, there is always the option to make it my priority by making it a paid gig ;-)

This would also help me very much, because currently the interest in plc4x is pretty high in general, but I can't say how long I'll be able to work on it full time as my bosses are complaining that I'm not making any revenue even though this interest is there.

Chris
________________________________
Von: Jens Vagts <je...@gmail.com>>
Gesendet: Montag, 2. März 2020 07:15
An: dev@plc4x.apache.org<ma...@plc4x.apache.org> <de...@plc4x.apache.org>>
Betreff: Re: Current status of the ADS protocol support

Hi Chris,

together with a colleague I had a very nice conversation with Julian,
getting explained the developments and use of PLC4X within the projects of
his company. Thanks again to Julian for his time and kindness!

We have one remaining question regarding the ADS support: what do you
expect the new (generated) ADS driver might be completed in terms of the
ADS protocol features?

The ADS protocol seems to be a very advanced protocol compared to others
and these advanced features like structures and arrays of structures are
mandatory for the fast data rates of our machines.

Regards,
Jens


Am Montag, den 24.02.2020, 10:38 +0100 schrieb Jens Vagts:

Hi Chris,

thank you for the quick response of the current development timeline!

We are still in an early stage of our product so this does fit for us and I
very happy to be able to help you with testing of the new ADS driver.
Please let me know if I can help else. My background is Java backend
development for 15 years (after some years of C++) , mainly with OSGi,
Spring, Hibernate, PostgreSQL, MDD/MDA. I'm not a PLC developer myself but
working together with very experienced PLC developers.

Good to hear that Beckhoff provided you a device and thus is supporting the
project. Besides their closed source Windows developments they are working
on platform independent open source drivers as well for C++ (
https://github.com/Beckhoff/ADS) and .NET Core (
https://www.nuget.org/packages/Beckhoff.TwinCAT.Ads/5.0.0-preview4). But
for me a community driven project not limited to one protocol makes far
more sense, as you described as well in the current Linux Magazin :-) (
https://www.linux-magazin.de/ausgaben/2020/03/sps-und-edge/). Nice article
by the way!

Regards,
Jens


Am Fr., 21. Feb. 2020 um 14:13 Uhr schrieb Christofer Dutz <
christofer.dutz@c-ware.de<ma...@c-ware.de>>:

Hi Jens,

also a nice and warm welcome from me too.

Perhaps I can give you some insight on the status of the ADS driver or the
drivers in general.

We currently have 2 important branches.

1) In the rel/0.6 branch we have the old drivers. Old is relative, but the
main point with all of them is that they are all manually implemented and
some require external libraries.

2) In the develop branch we have a new generation of drivers. These are all
formally specified with specs and 90% of the code is generated by a
code-generator we built. Currently we are working hard on porting all old
drivers to the new type. The ADS driver was initially built by a colleague
and project member which is currently a little less available. Therefore
the port hasn't progressed to a level that it's usable at all. The old
driver we did some testing against a device Beckhoff kindly provided us
with but we have never used it in production. However I know the Beckhoff
driver is important and I`ll definitely address finishing an initial port
of this driver as soon as I'm finished with creating the unit- and
integration-test suite.

I would expect a first new version to be available for testing in perhaps a
month or so. It would definitively help having you on board for testing,
tuning and improving our implementation. Your involvement would be very
highly appreciated.

Chris


Am 21.02.20, 12:53 schrieb "Julian Feinauer" <j....@pragmaticminds.de>
>:

    Hi Jens,

    first, welcome and nice to have you here!
    Second, cool that you have a Karaf backend... I would love to have one
__

    And now regarding your questions... We use PLC4X in prod, meaning on
several large machines from different industries on the plants (core
shooters, saws, ...).
    So yes its still early in the project and sometimes you have to adjust
things a bit but you can run it on the Shopfloor (but not an a raspberry
pi... this is something we learned... : ) ).

    We abandoned our own "home grown" code and joined the project as we had
the same issues with our own code base and it just makes more sense to
collaborate on that.
    From the community side I think we could consider a hangout or "web
meetout" to talk a bit about that or I can offer that myself or @Tim Mitsch
have a Teams call with you and show you a  bit of what we do it and give
you a bit of background of our exact usages in real plants.

    Hope that helps you a bit : )

    Julian

    Am 21.02.20, 12:49 schrieb "jens.vagts@gmail.com<ma...@gmail.com>" <je...@gmail.com>
>:

        Hi PLC4X developers,

        I'm working for a manufacturer of packaging machines in northern
        Germany using Beckhoff PLCs only. In order to gather data for a
        condition monitoring solution from our fast running machines (our
        fastest PLCs have cycle times of 1ms) we are looking for a library
        enabling us to access the PLC remotely as fast as possible (via ADS)
        from a Java runtime running wihtin a (Docker) container. PLC4X looks
        like a perfect match for us! It has a nice API supporting different
PLC
        protocols (Rockwell EtherNet/IP might be required by our product as
        well in the future) , supports OSGi to be used in our Karaf based
        backend and is a fully java implementation to be used in a Linux
        environment.

        During the last days we did some tests to check the support of
        elemental data types mandatory for our first product and found some
        limitations, e.g.:
        - writing variables seems not to work at all. As far as I
understoud a
        field encoder seems not be implemented at all
        - reading of arrays and structure is not implemented yet
        - reading of multiple variables via one single request results in
        timeouts
        - read floating values results in incorrect values

        This is ok as the version number of PLC4X and "limited"
documentation
        do indicate the early state of the whole library. What we would
like to
        know:
        Is PLC4x ready for production use and does somebody still work on
the
        ADS support (the related Jira issues are updated months ago)?

        Since we are very interested in PLC4X and I'm personally interested
in
        OpenSource development, I would even like to help with
contributions.

        Kind regrads,
        Jens Vagts