AW: We need to work on some of the basics ... and I could use your help with that.
Hi Cesar, sure … feel free to give it a shot. Chris Von: Cesar Garcia Datum: Dienstag, 27. Februar 2024 um 11:43 An: dev@plc4x.apache.org Betreff: Re: We need to work on some of the basics ... and I could use your help with that. Good day, For the approach you make for PLC4X frontend, I proposed "qooxdoo". I have been testing the new version and we can definitely get results very quickly. It is pure JavaScript, nothing to do with NetBeans. In the case of NetBeans Platform, the integration with PLC4X, I see it for final applications, and very specific solutions. We cannot cover all scenarios with web applications. And I would propose it for the "plc4j/integration" section. If you agree, I can take a few steps with qooxdoo, and we will evaluate it to present it to the work team. I'm going to get a coffee, Have a great day, Kind regards, El mar, 27 feb 2024 a las 4:32, Christofer Dutz () escribió: > 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 > 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 (< > 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 > * > -- *CEOS Automatización, C.A.* *GALPON
Re: We need to work on some of the basics ... and I could use your help with that.
Good day, For the approach you make for PLC4X frontend, I proposed "qooxdoo". I have been testing the new version and we can definitely get results very quickly. It is pure JavaScript, nothing to do with NetBeans. In the case of NetBeans Platform, the integration with PLC4X, I see it for final applications, and very specific solutions. We cannot cover all scenarios with web applications. And I would propose it for the "plc4j/integration" section. If you agree, I can take a few steps with qooxdoo, and we will evaluate it to present it to the work team. I'm going to get a coffee, Have a great day, Kind regards, El mar, 27 feb 2024 a las 4:32, Christofer Dutz () escribió: > 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 > 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 (< > 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 > * > -- *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
AW: We need to work on some of the basics ... and I could use your help with that.
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
Datum: Dienstag, 27. Februar 2024 um 09:32
An: 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
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 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
>
>
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 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 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
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 *
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
