Hi,
If we were to let the server control a minimum rate for change of 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
Looking at issue we could utilize marker interfaces.
At least in Java we could define Qualified and Timestamped types.
Yet looking at present state of API we are unlikely to make each and
every PlcValue in each and every variant (qualified and timestamped,
timestamped, qualified). It would force
I have not mentioned metadata term in my answer, so credits for mining
it API go to you. :-)
Now since you brought it I remember that JDBC has a "result set
metadata". That might be thing we still miss. The result code is most
important and available instantly, other information is supplemental
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
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
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) -
Hi all,
sorry for being late to the party ... KNX is currently consuming all my cycles.
Just wanted to add my thoughts to the discussion.
Initially I thought about adding this sort of information to the API, but then
I thought that we have so little protocols supporting this sort of concept
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
Gesendet: Montag, 8. März 2021 12:58
An:
+1 for Łukasz‘s metadata approach, it would avoid having to create
duplicate PLcValue classes and give us a lot of flexibility in the future.
On Mon, Mar 8, 2021 at 5:14 AM Christofer Dutz
wrote:
> Hi all,
>
> sorry for being late to the party ... KNX is currently consuming all my
> cycles.
>
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
Hi,
I must admit that I would be in favor of keeping it as simple as possible (max
age in the connection string) and to implement more of the missing parts in
plc4x (like the subscription simulation layer) and hereby getting the drivers
we have a bit more aligned, than to implement more and
Hold on for a second.
Making options pushed over connection string is a long term recipe for
disaster. Apache Camel is a prime example of what could happen if you
starting with configuration with URIs and dynamic parameters. Most of
components distinguish producer (writer) and consumer (receiver)
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
+1 to Lukasz
Am Mo., 8. März 2021 um 14:09 Uhr schrieb Łukasz Dywicki <
l...@code-house.org>:
> Hold on for a second.
>
> Making options pushed over connection string is a long term recipe for
> disaster. Apache Camel is a prime example of what could happen if you
> starting with configuration
Hi,
I'm generally more concerned about users expecting us to deliver feature that
driver X has for driver Y too.
I won't object, if you think it's worth doing.
Perhaps if you could whip up an example in a feature branch? I think perhaps I
was still not understanding what you propose.
Would
BUILD-STABLE: Job 'PLC4X/PLC4X/develop [develop] [272]':
Is back to normal.
BUILD-FAILURE: Job 'PLC4X/PLC4X/develop [develop] [271]':
Check console output at "https://ci-builds.apache.org/job/PLC4X/job/PLC4X/job/develop/271/;>PLC4X/PLC4X/develop
[develop] [271]"
BUILD-FAILURE: Job 'PLC4X/PLC4X/develop [develop] [270]':
Check console output at "https://ci-builds.apache.org/job/PLC4X/job/PLC4X/job/develop/270/;>PLC4X/PLC4X/develop
[develop] [270]"
Hi all,
i see there a point of how useful this meta information could be in some
scenarios. But i would rather go the route of chris. Because I see there is
more of a risk of an overcomplicated inhomogeneous api structure. I would
not say that all API should have the same java structure on each
19 matches
Mail list logo
