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 <[email protected]> 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" <[email protected]>: > > 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" <[email protected]>: > > 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 > > > >
