And regarding my plans on extending the code generation. That’s generally multiple steps … each one generating more parts of the code:
* Message Templates: Here we use the same syntax we used for defining test-messages, but can use placeholders “${someVariable}” instead of fixed values and it generates a factory method that takes all placeholders as arguments which can be used to “createConnectionRequest(param1, param2)” * Message Interactions: Here we use Message Templates to produce a message, but also declare what we consider to be a response. This would generate the sendRequest and expectResponse parts. So, an interaction would be something like: “sendConnectionRequest(param1, param2, response -> {code handling the response})”. I would consider the input to such a definition being also in XML, but having a set of expressions, which describe what we currently do in code. * I have already started writing down some of the general state-machine descriptions for the documentation. The general Idea of the third step would be to have a state-machine description and use the Message Interactions as transitions from one state to the other. All of this won’t fully generate the drivers, but it would get us a lot further and the manual labor of implementing a driver would be a lot less. So much for my ideas ;-) Chris Von: Christofer Dutz <christofer.d...@c-ware.de> Datum: Dienstag, 27. Februar 2024 um 09:32 An: dev@plc4x.apache.org <dev@plc4x.apache.org> Betreff: AW: We need to work on some of the basics ... and I could use your help with that. Hi Cesar, Having had a look at https://qooxdoo.org/ … it seems as this is a web-framework not at all linked with NetBeans. So, do you propose to use that or a NetBeans GUI? 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>*