We need to work on some of the basics ... and I could use your help with that.
Hi all, So, we now have more and more drivers in more and more languages and are seeing that this is becoming a bit of a problem, as it’s difficult to keep all of them aligned. It was always my plan to work on this by extremely increasing the portion of generated code. The problem is that there is also stuff that needs doing to promote the project (Our users are asking for more drivers, better integrations, bugfixes etc.) I personally see that we need the following features: - A general purpose Request-Optimizer, that rewrites requests and possibly splits them up - A rewrite of the scraper - A general purpose “subscription emulator” that allows using the subscription API with connections only allowing reads - A general purpose UI that allows interacting with PLCs using PLC4X in a graphical way. However, you can imagine, that I can’t do all of that on my own, especially as I unfortunately no longer can work on this sort of things full-time as part of my day job. So, I’m mostly relying on rainy weekends and dark and rainy evenings. My question to you all: Anyone willing to help take any of this off my plate? Chris
Re: [PR] build(deps): bump github.com/schollz/progressbar/v3 from 3.14.1 to 3.14.2 in /plc4go
sruehl merged PR #1428: URL: https://github.com/apache/plc4x/pull/1428 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@plc4x.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] build(deps): bump com.google.protobuf:protobuf-java from 3.25.2 to 3.25.3
sruehl merged PR #1427: URL: https://github.com/apache/plc4x/pull/1427 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@plc4x.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] build(deps): bump com.google.googlejavaformat:google-java-format from 1.19.2 to 1.20.0
sruehl merged PR #1426: URL: https://github.com/apache/plc4x/pull/1426 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@plc4x.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] build(deps): bump nl.jqno.equalsverifier:equalsverifier from 3.15.6 to 3.15.7
sruehl merged PR #1425: URL: https://github.com/apache/plc4x/pull/1425 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@plc4x.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: We need to work on some of the basics ... and I could use your help with that.
Hello, Reading your email while having a coffee, what comes to mind is a word "time". I can remember that I followed up on the way Woodhead (Applicom) cards work and definitely before the request they have an optimizer, but they achieve this by creating a model of the device as an intermediate layer, which will plan the requests. The poorest implementation of a driver, I could see a communication with Modbus of a Simenes MP277, horrible! There are some papers like [1] that attack this problem, it would be interesting for the work team to debate how to implement an "optimizer + scheduler", which would solve two of the problems you raise. The interesting thing here is how to maintain a unified architecture between the versions of C and Java, which are the ones I can evaluate. My proposal for visualization follows the same line, we continue working with Apache NetBeans Platform for relatively complex applications, and web visualization with "qooxdoo" [2]. Why I propose "qooxdoo", because of its simplicity, we don't want to learn a lot of React, Typescript, css, etc. To make a simple functional table, qooxdoo's implementation of a table is the best I've tried [3]. The integration of qooxdoo with Apache ECharts [4] is pure magic. The best thing, qooxdoo + ECharts V4, works with old equipment that we still find in some industries (yes, Windows XP is still used). I would just add to the list, PLC4X driver as a service. In this case supported by Apache Karaf and Apache Celix. Uhs, I'm out of coffee, My grain of sand, Have an excellent day. 1. https://www.researchgate.net/publication/332657959_Dynamic_Optimization_of_Data_Packet-based_Communication_for_PLC_Visual_Monitoring 2. https://qooxdoo.org/ 3. https://qooxdoo.org/qxl.demobrowser/#table~Table.html 4. https://echarts.apache.org/en/index.html El lun, 26 feb 2024 a las 5:17, Christofer Dutz () escribió: > Hi all, > > So, we now have more and more drivers in more and more languages and are > seeing that this is becoming a bit of a problem, as it’s difficult to keep > all of them aligned. > It was always my plan to work on this by extremely increasing the portion > of generated code. > > The problem is that there is also stuff that needs doing to promote the > project (Our users are asking for more drivers, better integrations, > bugfixes etc.) > I personally see that we need the following features: > > - A general purpose Request-Optimizer, that rewrites requests and possibly > splits them up > - A rewrite of the scraper > - A general purpose “subscription emulator” that allows using the > subscription API with connections only allowing reads > - A general purpose UI that allows interacting with PLCs using PLC4X in a > graphical way. > > However, you can imagine, that I can’t do all of that on my own, > especially as I unfortunately no longer can work on this sort of things > full-time as part of my day job. > So, I’m mostly relying on rainy weekends and dark and rainy evenings. > > My question to you all: Anyone willing to help take any of this off my > plate? > > Chris > > -- *CEOS Automatización, C.A.* *GALPON SERVICIO INDUSTRIALES Y NAVALES FA, C.A.,* *PISO 1, OFICINA 2, AV. RAUL LEONI, SECTOR GUAMACHITO,* *FRENTE A LA ASOCIACION DE GANADEROS,BARCELONA,EDO. ANZOATEGUI* *Ing. César García* *Cel: +58 414-760.98.95* *Hotline Técnica SIEMENS: 0800 1005080* *Email: support.aan.automat...@siemens.com *
AW: We need to work on some of the basics ... and I could use your help with that.
Hi Cesar, Well, I guess for a general purpose we’d have to come up with general functionality for some things like: * Size of a base request (no items) * Size of a base response (no items) * Size of a request item * Size of a response item With this and a given request and max pdu-size, we should be able to build a general-purpose optimizer, that produces a sequence of requests, that utilize the PDU size. What I built for S7, simply keeps on checking: “does it work, if I add this item?” … as soon as it doesn’t it finishes the first request and starts a new one. This doesn’t make use of possibly re-arranging items to better fill PDUs, which should also be pretty general purpose. The next step would be one that is able to apply protocol-dependent optimizations. Like … if I read 10 boolean values, it might be better to read an array of bytes instead, as the overhead is a lot less. I could imagine that such an optimizer would be pretty much like a rule engine. I have no objections if anyone wants to build a UI tool with some other technology. I’m not overwhelmed when I hear “Netbeans”, as I remember that is built by an ANT build from hell … pretty much on one level with all the Eclipse stuff that uses Tycho to build and you essentially have to build it in an Eclipse IDE. I would not be willing to buy easy implementation of tables by inheriting a nightmare of a build. If you could whip up a PR with such an editor (doesn’t have to be much more than what I have in React). I guess that would be something we could be discussing over. I just thought: If I must learn something new, I might as well learn something I might be benefiting from in my future carrier. And I was expecting more people to be able to join in with React compared to any other UI framework. I’d love if this thing would become backed by a community that is able to sustain it. Nothing that someone built and then I have to maintain it. Chris Von: Cesar Garcia Datum: Montag, 26. Februar 2024 um 15:14 An: dev@plc4x.apache.org Betreff: Re: We need to work on some of the basics ... and I could use your help with that. Hello, Reading your email while having a coffee, what comes to mind is a word "time". I can remember that I followed up on the way Woodhead (Applicom) cards work and definitely before the request they have an optimizer, but they achieve this by creating a model of the device as an intermediate layer, which will plan the requests. The poorest implementation of a driver, I could see a communication with Modbus of a Simenes MP277, horrible! There are some papers like [1] that attack this problem, it would be interesting for the work team to debate how to implement an "optimizer + scheduler", which would solve two of the problems you raise. The interesting thing here is how to maintain a unified architecture between the versions of C and Java, which are the ones I can evaluate. My proposal for visualization follows the same line, we continue working with Apache NetBeans Platform for relatively complex applications, and web visualization with "qooxdoo" [2]. Why I propose "qooxdoo", because of its simplicity, we don't want to learn a lot of React, Typescript, css, etc. To make a simple functional table, qooxdoo's implementation of a table is the best I've tried [3]. The integration of qooxdoo with Apache ECharts [4] is pure magic. The best thing, qooxdoo + ECharts V4, works with old equipment that we still find in some industries (yes, Windows XP is still used). I would just add to the list, PLC4X driver as a service. In this case supported by Apache Karaf and Apache Celix. Uhs, I'm out of coffee, My grain of sand, Have an excellent day. 1. https://www.researchgate.net/publication/332657959_Dynamic_Optimization_of_Data_Packet-based_Communication_for_PLC_Visual_Monitoring 2. https://qooxdoo.org/ 3. https://qooxdoo.org/qxl.demobrowser/#table~Table.html 4. https://echarts.apache.org/en/index.html El lun, 26 feb 2024 a las 5:17, Christofer Dutz () escribió: > Hi all, > > So, we now have more and more drivers in more and more languages and are > seeing that this is becoming a bit of a problem, as it’s difficult to keep > all of them aligned. > It was always my plan to work on this by extremely increasing the portion > of generated code. > > The problem is that there is also stuff that needs doing to promote the > project (Our users are asking for more drivers, better integrations, > bugfixes etc.) > I personally see that we need the following features: > > - A general purpose Request-Optimizer, that rewrites requests and possibly > splits them up > - A rewrite of the scraper > - A general purpose “subscription emulator” that allows using the > subscription API with connections only allowing reads > - A general purpose UI that allows interacting with PLCs using PLC4X in a > graphical way. > > However, you can imagine, that I can’t do all of that on my own, > especially as I unfortunate
