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 <cesar.gar...@ceos.com.ve> Datum: Montag, 26. Februar 2024 um 15:14 An: dev@plc4x.apache.org <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 (<christofer.d...@c-ware.de>) 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 <support.aan.automat...@siemens.com>*
