Hi all,
here comes a summary of what we discussed yesterday … feel free to add things,
that I might have missed writing down.
* Lukasz brought up the problem in Modbus (and I guess CAN) that he would
like to extend the address syntax with a “unit-id” attribute in order to
address multiple devices.
We decided that we should start adding this sort of optional “tag-options” with
a java-script-like notation after the tag:
tag-address:plc-value-type{option:’value’, option-2:’value-2’}
- Lukasz started working on this and is leading this extension.
* OSGI support: It seems that we currently generate the OSGI manifests
automatically. This works, but has the disadvantage, that a lot more is
included than is really needed. Lukasz and Ben proposed to manually curate this
list of dependencies and hereby make the OSGI bundles a lot more lightweight. I
proposed to live with the generated bundles per default and to manually update
them. This way we are not reliant on Lukasz and Ben keeping them up to date.
So, we have the fallback: If there are problems with the bundles, but nobody is
there to manage them manually – we default back to the generated ones.
- Lukasz volunteered to lead this initiative.
* We discussed the usefulness of a Simulator: Chris proposed to generally
build it, so it is only built for working with PLC4X drivers (It is not meant
to be a full implementation of the protocols). A plc4x driver needs to be used
to configure the simulated device that is then also queried by the same driver.
This simplifies everything a LOT and as a result we could both tests a PLC4X
application for which the corresponding PLC does not exist (or we want to test
how the application behaves in hard to produce situations.
- No real lead has been set and this is considered more a long-time-perspective
goal to reach
* We discussed the need to generate larger protions of the code (Chris gave
a walk through what he thinks we need and in which steps to achieve it:
1. Generate Message Templates (helper functions to generate and initialize
protocol messages)
2. Generate Interactions (Use the message templates and define what defines a
“response” and simplify sending requests and handling responses
3. Generate a driver as sequence of interactions based an a directed graph,
that represents the protocol logic.
- Chris said he’s currently working on the message templates based on an
extended XML notation that matches that of the unit- and integration-tests.
* We discussed splitting up the repository into a main repo and an
“plc4x-extras” repo, that contains examples, integration modules and optional
tools. The reasoning behind this is, that most security-related dependency
updates and transitive CVEs we get reported are mostly because of the
integration modules and examples. By splitting the repositories up, we would
rid the core-repo of these CVEs. Especially looking toward the CRE and PLD
initiatives, we see a large benefit in having our core-repo clean of these
dependencies.
- A vote was started on the mailing list, and it was in huge favor of creating
the plc4x-extras repo and the creation has been initiated
- Currently we are discussing on the list which parts should be moved and how,
also which branch strategy to use etc.
* Ben and Lukas worked on moving finishing some unfinished business in
PLC4PY and moving this out of the sandbox
- This work has been finished during the meetup and plc4py is now located in
the root of the main repo
* As the “sandbox” now only contained no longer worked on initiatives, we
decided to remove these and we then completely removed the now empty sandbox
all together.
* We discussed the need to refactor the OPC-UA testsuite:
- Chris suggested to refactor the tests requiring a server into
Integration-Tests which are executed in the integration-test phase and for
which one Milo server instance would be started in the pre-integration-test
phase and which is then torn down in the post-integration-test phase, as this
would probably solve a lot of the issues we were having with Milo in unit-tests.
- Chris will also be working on this feature.
The probably biggest discussion was the: What’s needed for 1.0.0
* Publish API (Counterpart of Subscription) (chris)
* Streamline other PLC4X Languages APIs to match those of PLC4J
(sebastian: go, chris: c)
* Subscriptions survive connection-reconnections when using
connection-cache (Auto Re-Subscribe) (chris)
* SubscriptionEmulation “decorator” (Component, that implements
PlcConnection API, but takes care of emulating subscriptions)
* PlcConnectionManager fluent API extension “ensureSubscribable()”
* (Lukasz, chris)
* Subscriptions: Example: Generally, supports “true” for S7 for example
if we’re connected to a s7 300 or 400 and reports false for S7-1200 and
S7-1500. SubscriptionRequestBuilder checks if a given connection supports
subscriptions for a given address and returns “UNSUPPORTED” or similar for a
given field if this is not supported.
* Subscription API support Timestamp on Callback-Level (chris, lukasz)
* Refactor SubscriptionAPI to have one handler registered for a request,
not a field. Generally, we should only use the pre-registered approach. (chris)
* Shared transport-instances (RS485 multiple connections sharing
physical transport)
* BOM (Lukasz)
Open-Question:
* ben and Lukas … could you have a look at the PLC4PY api, that is
semantically matches the updated Java version?
* Cesar: could you possibly have a look at the S7 subscription request
builder to signal if a tag address doesn’t support subscriptions and return a
corresponding (possibly new) PLC4X status code for only the fields that are not
supported?
* Not quite sure that the “BOM” thing means, that I noted for the 1.0.0
So … hope that summarizes everything … feel free to correct things, where I
mis-understood things and to add things that I missed.
Chris
