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>*
