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 < [email protected]>: > 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 <[email protected]> > *Gesendet:* Montag, 2. März 2020 07:15 > *An:* [email protected] <[email protected]> > *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 < > [email protected]>: > > 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" < > [email protected] > >: > > 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 "[email protected]" < > [email protected] > >: > > 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 >
