plc4x-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Snow <s40...@gmail.com>
Subject Re: [DISCUSS] Minimum sampling interval on change of state subscription
Date Mon, 08 Mar 2021 13:34:59 GMT
I  will just add some of my experience with both older and newer PLC's.
First when I am referring to 'older' it generally means PLC's made
prior to the advent of object oriented control architecture that is
being employed by such OEM's as the current Siemens, Rockwell, Modicon
controllers which can have complex data structures that combine most if
not all primitive datat structures as well as user defined ones. These
are the 'newer PLC's and they have better communication handling
capablities as they were designed for this purpose. 
Irrespective of the age though, in most cases communication is divided
into different priorities by the PLC itself, an example would be when a
programming terminal is connected to it, that terminal effectivley owns
the PLC at that time and it's communication will bump less important
comms if required to satisfy scan time limits. What this implies is
that if you are 'testing' a connection to the PLC for your data
collection purposes while having a programming terminal connected, be
aware that the results are affected by the terminal connection. Also,
commonly on the control network, there will be operator terminals
(HMI's) for the operation of the equipment locally, these gain access
to memory location in the PLC and usually are setup to only look for
change of state to make writes/reads. This ability has been present
across all OEMs and HMI OEM's for a couple of decades at least (and
longer with some). SCADA has been around for a very long time, and
again, the proprietary drivers that used to be the path to connecting
your PLC to your data aquisition system were the ones to choose,
because they worked, just not always as flexibly as you liked. Products
like WonderWare, WinCC, RSView, etc all do this without substantial
overhead increases on the network or for the PLC, although at a premium
based on tag databsae size usually. From my Rockwell Automation Systems
Special days I know that their drivers they employ sit pretty low on
the OSI layer model and they use an ABI as they term it to provide
connectivity for user applications, at least this is how it was done in
the mid 2000's. So OEM driver ---> OEM ABI(API) ----> User created app.
This is all harware dependant to some degree, but there are processor
status bits you can monitor to determine if there is a change of state
on IO, in some PLC's this is correlated directly to specific IO areas,
but I cannot say this for all of them since my experience only covers
Siemens, Rockwell, Omron, Reliance, Allen-Bradley, Mitsubishi, Modicon,
ABB, and some now extinct types.

So with systems I have encountered and those I was involved in the
design on, I can say that polling was used for non control critical
data manipulation, so production data, logging data, basically nothing
that actually has any direct control fucntion. Anything that needed to
be reactive or active in the control strategy needed to be update on
change of state. Again, modern PLC's have come a long way and now you
can access memory location directly, even in modbus RTU networks. The
big OEM's such as Siemens Modicon and Rockwell use this IO has changed
state capability in their processors for thid purpose. Also, my
understanding of accessing the IO memory locations directly is if you
write a one into an output for instance, the PLC program will still
overwrite the value based on the program state regardless. So to time
stamps, which have been used ad nausium since we have been connecting
to PLC's to get data from the plant floor up to the ERP. Usually, if
the data collection system is the communication master, then they
applied a time stamp to the log activity for that data point. This was
necessary since very few PLC's had an RTC at first, and those that did
were very rarely connected to an NTP server like the data collection
system was. I would suggest, without fully looking at your PLC4X code,
that you make a timestamp function/method that applies the time stamp
outside of the driver, if the PLC has a RTC like most do nowadays, try
to link it to the network NTP server if possible (usually security
implications here) but I would be reluctant to rely on ther PLC's idea
of the time, per se.

Just some thoughts your conversation is provoking in me. Good luck!

Stephen

On Mon, 2021-03-08 at 13:37 +0100, Andreas Vogler wrote:
> Hi, 
> I have not really read all details of your mails …. just my personal
> opinion: for a subscription I would expect that I get every single
> change of value (what the source is able to deliver to me) ...if this
> will potentially flood my client then I have to take care about it…
> and start to think about back pressure strategies … or set a
> subscription interval to bigger than 0 (if possible, like it is with
> OPC UA )and be aware of possible lost value changes… But it is just
> my personal opinion. I mostly work on top of SCADA & event driven…
> and sure, here we are on the edge between polling/plc and event
> driven architectures (pub/sub)...
> Andy
> 
> > On 08.03.2021, at 13:08, Christofer Dutz
> > <christofer.dutz@c-ware.de> wrote:
> > 
> > Hi all,
> > 
> > But I would probably assume a sensible default but make ich
> > changeable on a per-connection basis. Not on a per-request or even
> > per-field. That would simply be a bit too much, I think.
> > 
> > Chris
> > 
> > -----Ursprüngliche Nachricht-----
> > Von: Lukas Ott <ott.lukas.14@gmail.com> 
> > Gesendet: Montag, 8. März 2021 12:58
> > An: dev@plc4x.apache.org
> > Betreff: Re: [DISCUSS] Minimum sampling interval on change of state
> > subscription
> > 
> > Hi,
> > 
> > concerning limiting the data rate is a really valid point as the
> > newer PLCs are doing exactly that (e.g. they have a Data collector
> > and Data Processor included - and we did exactly that as well with
> > some IIoT sensors that we collected and processed the data directly
> > on the microcontroller) - as the older ones are not build for
> > sending data - it would be quite helpful to configure a timer but
> > one second may be too long as default value
> > 
> > Best,
> > Lukas
> > 
> > Am Mo., 8. März 2021 um 12:49 Uhr schrieb Ben Hutcheson <
> > ben.hutche@gmail.com>:
> > 
> > > Hi,
> > > 
> > > state subscriptions then we could overload the client.
> > > 
> > > I think allowing a value of 0 would be a good idea in case you
> > > really 
> > > do want to capture every change even if it is incredibly fast,
> > > but 
> > > still defaulting to 1s.
> > > 
> > > Ben
> > > 
> > > On Mon, Mar 8, 2021 at 5:20 AM Christofer Dutz 
> > > <christofer.dutz@c-ware.de>
> > > wrote:
> > > 
> > > > Hi all,
> > > > 
> > > > yeah ... I wanted to say something to that too:
> > > > 
> > > > Change of State shouldn't have a sampling interval (Perhaps a
> > > > min
> > > interval
> > > > to prevent flooding an application with too many updates) The
> > > > use 
> > > > case seems a bit like a polling use case and we have a separate
> > > > set 
> > > > of subscription properties for that. For polling, there should
> > > > be a 
> > > > sampling interval and that's even included in the API.
> > > > 
> > > > If we are "simulating" a change of state functionality on a 
> > > > protocol,
> > > that
> > > > doesn't support this (like S7, Modbus, ...) we should have a
> > > > generic 
> > > > property to control this sampling interval throughout all PLC4X
> > > > drivers.
> > > As
> > > > I recall we currently don't have this subscription simulation
> > > > layer ...
> > > not
> > > > yet ...
> > > > 
> > > > Chris
> > > > 
> > > > 
> > > > -----Ursprüngliche Nachricht-----
> > > > Von: Łukasz Dywicki <luke@code-house.org>
> > > > Gesendet: Montag, 8. März 2021 11:08
> > > > An: dev@plc4x.apache.org
> > > > Betreff: Re: [DISCUSS] Minimum sampling interval on change of
> > > > state 
> > > > subscription
> > > > 
> > > > Hey Ben,
> > > > I began writing this answer shortly after you sent your mail
> > > > but 
> > > > eventually left it for a day or two to thing it through.
> > > > Looking at API I believe we have three major cases:
> > > > - polling/push interval
> > > > - change of value
> > > > - every value
> > > > 
> > > > Looking at above change of value should not require any
> > > > interval 
> > > > cause it should be determined by device we subscribe to. It
> > > > knows 
> > > > for sure that value changed and should push an update to us.
> > > > Same 
> > > > applies to event
> > > field.
> > > > For cases where we can specify update interval the first
> > > > (cyclic) 
> > > > option is intended. I know very little of OPC UA so above might
> > > > be 
> > > > not entirely valid in context of it. The real question is shall
> > > > we 
> > > > fit OPC into our
> > > API
> > > > or our API into OPC.
> > > > 
> > > > Looking closer at cyclic subscriptions we don't have a clear 
> > > > indication
> > > of
> > > > who does the time handling. Is it device (or server) who post 
> > > > updates
> > > back
> > > > to us at given frequency? Or we poll it given interval? How our
> > > > API
> > > caller
> > > > will know who controls time?
> > > > 
> > > > To sum all this - I would say that case you have seems to fit
> > > > more 
> > > > into cyclic subscription than change of state.
> > > > 
> > > > Best,
> > > > Łukasz
> > > > 
> > > > 
> > > > On 06.03.2021 13:06, Ben Hutcheson wrote:
> > > > > Looking at the change of state subscription interface there's
> > > > > no 
> > > > > explanation or way to modify the Duration parameter which
> > > > > defaults 
> > > > > to one second. This is used in OPC UA as a minimum reporting
> > > > > time 
> > > > > so will never report back faster than 1 second.
> > > > > 
> > > > > What's everyone's thoughts on adding this as an optional
> > > > > parameter?
> > > > > 
> > > > > I thought about changing the default but I think 1 second is
> > > > > a 
> > > > > good value for it.
> > > > > I also think an absolute minimum value should be allowed of 5
> > > > > or 10ms.
> > > > > 
> > > > > * Adds a new field to the to be constructed request which
> > > > > should 
> > > > > be updated as soon as
> > > > > * a value changes in the PLC.
> > > > > *
> > > > > * @param name       alias of the field.
> > > > > * @param fieldQuery field query string for accessing the
> > > > > field.
> > > > > * @return builder.
> > > > > */
> > > > > PlcSubscriptionRequest.Builder addChangeOfStateField(String
> > > > > name, 
> > > > > String fieldQuery);
> > > > > 
> > > > 
> > > 
> 



Mime
View raw message