Hi, I agree with Julian here; we could implement these things in a plc4j-util module or something like that (or pooling in a plc4j-pool).
Regarding implementing a plcSubscriber based on PlcReader: I think I did that in the camel component when no plcSubscriber is available if I remember correctly. I would vote against implementing such thing in the core module as PlcSubscriber shall only be used for „real“ notifications and not polled reads. Sebastian > Am 12.09.2018 um 13:33 schrieb Julian Feinauer <[email protected]>: > > Hi Andrey, > > we use this heavily (as we want frequent updates from S7 plcs) and have built > a complete layer on top of the communication in the last year. > So I strongly suggest to add this to the project but as another level. > I think we can also provide some code for this feature. > > The main reason why this should be "standalone" from my perspective is that > it has to deal with things like ThreadPools or Executors and handling of > connection losses and all those things. > And questions on how to deal with timeouts (if the plc is pretty busy) and > things like that. > Patterns like circuit breaker or request collapsing can be useful if you poll > enough messages (or are even necessary). > So in-depth we spent a lot of time with these things and do not see how we > could make a simple and easy to use solution for the core. > > Best > Julian > > Am 12.09.18, 13:04 schrieb "Andrey Skorikov" > <[email protected]>: > > Hello all, > > since not all protocols and devices support the subscriber model, I > believe that it is sensible to emulate the PlcSubscriber based on a > PlcReader as a fallback. This could be realized by polling the device at > a fixed rate in the client process. However, I am not sure whether this > should be part of the core plc4j component, or implemented separately on > top of it. What do you think? > > Regards, > Andrey Skorikov > > >
