You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@plc4x.apache.org by Etienne Robinet <er...@apache.org> on 2020/04/17 07:21:43 UTC
Camel Component features
Hi everyone,
As the Camel component is now working correctly, I thought about some features we could add on it, based on work I read from a coworker. I would like to know if these would fit inside this project and if so I would be glad to implement them.
Trigger & Completion
To prevent writing to a PLC that is using data or to fetch a bunch of data that has not changed, we could use Flags (Bits). A transaction will only take place if the Trigger bit is 1, and once it is done, it's set back to 0 and the completion bit to 1 (or Error bit). This way, the PLC is the master of the transaction and can tell when it can be written to or read from.
Polling
In order to be aware of the change of state of the trigger, we should do a polling on this bit. This way, we only read 1 bit, at an user specified interval, and once the bit is 1, we do the transaction(read/write)
Default values
If none or not every of these parameters are given, then we could use default values like reading the tags given every 1000ms or so (e.g. for monitoring)
Hope this is interesting for you and if so I would start next week.
Etienne
Re: Camel Component features
Posted by Etienne Robinet <43...@etu.he2b.be>.
Hi all,
another option would be to implement the idempotent Consumer on our Component.
https://camel.apache.org/components/latest/eips/idempotentConsumer-eip.html
This would allow to place processed messages in a repository (Trigger polling) and just execute the route if something is different (like Trigger bit). The result would be the same, but this feature is also implmented in other components so I thought of maybe we could use it aswell, what do you think?
Etienne
On 2020/04/17 20:28:52, Christofer Dutz <ch...@c-ware.de> wrote:
> Hi Etienne,
>
> Exactly ... Use the current api and when we refractor the scraper we just have to change all usages equally.
>
> Chris
> ________________________________
> Von: Etienne Robinet <43...@etu.he2b.be>
> Gesendet: Freitag, 17. April 2020 20:27
> An: dev@plc4x.apache.org <de...@plc4x.apache.org>
> Betreff: Re: Camel Component features
>
> Hi Chris,
> So what do tou think? Adapt the old scraper to use in the API and then use this in the Camel component?
>
> Etienne
>
> > Le 17 avr. 2020 à 12:10, Christofer Dutz <ch...@c-ware.de> a écrit :
> >
> > Hi all,
> >
> > And we should really rewrite and clean up the scraper internally ;-)
> >
> > Still got that on my ToDo, but would be happy if someone would beat me to it ;-)
> >
> > But I also agree that we shouldn't re-invent the wheel and reuse the components we already have.
> >
> > I think from an API side even a new scraper would be pretty much like the current one and the current one does work fine.
> >
> > Chris
> >
> >
> > Am 17.04.20, 09:45 schrieb "Julian Feinauer" <j....@pragmaticminds.de>:
> >
> > Etienne,
> >
> > like so often you are absolutely right with your analysis oft he Situation : )
> > Indeed these are very valuable features.
> >
> > In plc4x there exists a compontent called the "Scraper" (which I wrote initially) and which was extended to a "TriggeredScraper" by @Tim Mitsch which does exactly that.
> > Watch a bit or a condition and only fetch data, when this condition changes.
> >
> > In fact we want (since months) integrate our in-house developed Engine for these Tasks, CRUNCH as a PLC4X Subproject to push this even further (see here for CRUNCH https://github.com/pragmaticminds/crunch).
> >
> > I guess it helps you to take a look at both resoures!
> >
> > Julian
> >
> > Am 17.04.20, 09:21 schrieb "Etienne Robinet" <er...@apache.org>:
> >
> > Hi everyone,
> > As the Camel component is now working correctly, I thought about some features we could add on it, based on work I read from a coworker. I would like to know if these would fit inside this project and if so I would be glad to implement them.
> >
> > Trigger & Completion
> > To prevent writing to a PLC that is using data or to fetch a bunch of data that has not changed, we could use Flags (Bits). A transaction will only take place if the Trigger bit is 1, and once it is done, it's set back to 0 and the completion bit to 1 (or Error bit). This way, the PLC is the master of the transaction and can tell when it can be written to or read from.
> >
> > Polling
> > In order to be aware of the change of state of the trigger, we should do a polling on this bit. This way, we only read 1 bit, at an user specified interval, and once the bit is 1, we do the transaction(read/write)
> >
> > Default values
> > If none or not every of these parameters are given, then we could use default values like reading the tags given every 1000ms or so (e.g. for monitoring)
> >
> > Hope this is interesting for you and if so I would start next week.
> >
> > Etienne
> >
> >
> >
> >
>
Re: Camel Component features
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi Etienne,
Exactly ... Use the current api and when we refractor the scraper we just have to change all usages equally.
Chris
________________________________
Von: Etienne Robinet <43...@etu.he2b.be>
Gesendet: Freitag, 17. April 2020 20:27
An: dev@plc4x.apache.org <de...@plc4x.apache.org>
Betreff: Re: Camel Component features
Hi Chris,
So what do tou think? Adapt the old scraper to use in the API and then use this in the Camel component?
Etienne
> Le 17 avr. 2020 à 12:10, Christofer Dutz <ch...@c-ware.de> a écrit :
>
> Hi all,
>
> And we should really rewrite and clean up the scraper internally ;-)
>
> Still got that on my ToDo, but would be happy if someone would beat me to it ;-)
>
> But I also agree that we shouldn't re-invent the wheel and reuse the components we already have.
>
> I think from an API side even a new scraper would be pretty much like the current one and the current one does work fine.
>
> Chris
>
>
> Am 17.04.20, 09:45 schrieb "Julian Feinauer" <j....@pragmaticminds.de>:
>
> Etienne,
>
> like so often you are absolutely right with your analysis oft he Situation : )
> Indeed these are very valuable features.
>
> In plc4x there exists a compontent called the "Scraper" (which I wrote initially) and which was extended to a "TriggeredScraper" by @Tim Mitsch which does exactly that.
> Watch a bit or a condition and only fetch data, when this condition changes.
>
> In fact we want (since months) integrate our in-house developed Engine for these Tasks, CRUNCH as a PLC4X Subproject to push this even further (see here for CRUNCH https://github.com/pragmaticminds/crunch).
>
> I guess it helps you to take a look at both resoures!
>
> Julian
>
> Am 17.04.20, 09:21 schrieb "Etienne Robinet" <er...@apache.org>:
>
> Hi everyone,
> As the Camel component is now working correctly, I thought about some features we could add on it, based on work I read from a coworker. I would like to know if these would fit inside this project and if so I would be glad to implement them.
>
> Trigger & Completion
> To prevent writing to a PLC that is using data or to fetch a bunch of data that has not changed, we could use Flags (Bits). A transaction will only take place if the Trigger bit is 1, and once it is done, it's set back to 0 and the completion bit to 1 (or Error bit). This way, the PLC is the master of the transaction and can tell when it can be written to or read from.
>
> Polling
> In order to be aware of the change of state of the trigger, we should do a polling on this bit. This way, we only read 1 bit, at an user specified interval, and once the bit is 1, we do the transaction(read/write)
>
> Default values
> If none or not every of these parameters are given, then we could use default values like reading the tags given every 1000ms or so (e.g. for monitoring)
>
> Hope this is interesting for you and if so I would start next week.
>
> Etienne
>
>
>
>
Re: Camel Component features
Posted by Etienne Robinet <43...@etu.he2b.be>.
Hi Chris,
So what do tou think? Adapt the old scraper to use in the API and then use this in the Camel component?
Etienne
> Le 17 avr. 2020 à 12:10, Christofer Dutz <ch...@c-ware.de> a écrit :
>
> Hi all,
>
> And we should really rewrite and clean up the scraper internally ;-)
>
> Still got that on my ToDo, but would be happy if someone would beat me to it ;-)
>
> But I also agree that we shouldn't re-invent the wheel and reuse the components we already have.
>
> I think from an API side even a new scraper would be pretty much like the current one and the current one does work fine.
>
> Chris
>
>
> Am 17.04.20, 09:45 schrieb "Julian Feinauer" <j....@pragmaticminds.de>:
>
> Etienne,
>
> like so often you are absolutely right with your analysis oft he Situation : )
> Indeed these are very valuable features.
>
> In plc4x there exists a compontent called the "Scraper" (which I wrote initially) and which was extended to a "TriggeredScraper" by @Tim Mitsch which does exactly that.
> Watch a bit or a condition and only fetch data, when this condition changes.
>
> In fact we want (since months) integrate our in-house developed Engine for these Tasks, CRUNCH as a PLC4X Subproject to push this even further (see here for CRUNCH https://github.com/pragmaticminds/crunch).
>
> I guess it helps you to take a look at both resoures!
>
> Julian
>
> Am 17.04.20, 09:21 schrieb "Etienne Robinet" <er...@apache.org>:
>
> Hi everyone,
> As the Camel component is now working correctly, I thought about some features we could add on it, based on work I read from a coworker. I would like to know if these would fit inside this project and if so I would be glad to implement them.
>
> Trigger & Completion
> To prevent writing to a PLC that is using data or to fetch a bunch of data that has not changed, we could use Flags (Bits). A transaction will only take place if the Trigger bit is 1, and once it is done, it's set back to 0 and the completion bit to 1 (or Error bit). This way, the PLC is the master of the transaction and can tell when it can be written to or read from.
>
> Polling
> In order to be aware of the change of state of the trigger, we should do a polling on this bit. This way, we only read 1 bit, at an user specified interval, and once the bit is 1, we do the transaction(read/write)
>
> Default values
> If none or not every of these parameters are given, then we could use default values like reading the tags given every 1000ms or so (e.g. for monitoring)
>
> Hope this is interesting for you and if so I would start next week.
>
> Etienne
>
>
>
>
Re: Camel Component features
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi all,
And we should really rewrite and clean up the scraper internally ;-)
Still got that on my ToDo, but would be happy if someone would beat me to it ;-)
But I also agree that we shouldn't re-invent the wheel and reuse the components we already have.
I think from an API side even a new scraper would be pretty much like the current one and the current one does work fine.
Chris
Am 17.04.20, 09:45 schrieb "Julian Feinauer" <j....@pragmaticminds.de>:
Etienne,
like so often you are absolutely right with your analysis oft he Situation : )
Indeed these are very valuable features.
In plc4x there exists a compontent called the "Scraper" (which I wrote initially) and which was extended to a "TriggeredScraper" by @Tim Mitsch which does exactly that.
Watch a bit or a condition and only fetch data, when this condition changes.
In fact we want (since months) integrate our in-house developed Engine for these Tasks, CRUNCH as a PLC4X Subproject to push this even further (see here for CRUNCH https://github.com/pragmaticminds/crunch).
I guess it helps you to take a look at both resoures!
Julian
Am 17.04.20, 09:21 schrieb "Etienne Robinet" <er...@apache.org>:
Hi everyone,
As the Camel component is now working correctly, I thought about some features we could add on it, based on work I read from a coworker. I would like to know if these would fit inside this project and if so I would be glad to implement them.
Trigger & Completion
To prevent writing to a PLC that is using data or to fetch a bunch of data that has not changed, we could use Flags (Bits). A transaction will only take place if the Trigger bit is 1, and once it is done, it's set back to 0 and the completion bit to 1 (or Error bit). This way, the PLC is the master of the transaction and can tell when it can be written to or read from.
Polling
In order to be aware of the change of state of the trigger, we should do a polling on this bit. This way, we only read 1 bit, at an user specified interval, and once the bit is 1, we do the transaction(read/write)
Default values
If none or not every of these parameters are given, then we could use default values like reading the tags given every 1000ms or so (e.g. for monitoring)
Hope this is interesting for you and if so I would start next week.
Etienne
Re: Camel Component features
Posted by Julian Feinauer <j....@pragmaticminds.de>.
Etienne,
like so often you are absolutely right with your analysis oft he Situation : )
Indeed these are very valuable features.
In plc4x there exists a compontent called the "Scraper" (which I wrote initially) and which was extended to a "TriggeredScraper" by @Tim Mitsch which does exactly that.
Watch a bit or a condition and only fetch data, when this condition changes.
In fact we want (since months) integrate our in-house developed Engine for these Tasks, CRUNCH as a PLC4X Subproject to push this even further (see here for CRUNCH https://github.com/pragmaticminds/crunch).
I guess it helps you to take a look at both resoures!
Julian
Am 17.04.20, 09:21 schrieb "Etienne Robinet" <er...@apache.org>:
Hi everyone,
As the Camel component is now working correctly, I thought about some features we could add on it, based on work I read from a coworker. I would like to know if these would fit inside this project and if so I would be glad to implement them.
Trigger & Completion
To prevent writing to a PLC that is using data or to fetch a bunch of data that has not changed, we could use Flags (Bits). A transaction will only take place if the Trigger bit is 1, and once it is done, it's set back to 0 and the completion bit to 1 (or Error bit). This way, the PLC is the master of the transaction and can tell when it can be written to or read from.
Polling
In order to be aware of the change of state of the trigger, we should do a polling on this bit. This way, we only read 1 bit, at an user specified interval, and once the bit is 1, we do the transaction(read/write)
Default values
If none or not every of these parameters are given, then we could use default values like reading the tags given every 1000ms or so (e.g. for monitoring)
Hope this is interesting for you and if so I would start next week.
Etienne