Hi,

why not implement this in driver-base? Usually a driver could implement the 
subscription part directly or use the simulated subscriber, but any other 
combination doesn't really make sense, does it?

Chris

Am 12.09.18, 15:31 schrieb "Sebastian Rühl" 
<[email protected]>:

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

Reply via email to