Hi Chris,
in our situation we would have a conversion between the string and a "valid" S7
Query which is then passed down the current S7Comm protocol.
We could also do this with the current setup but we would need to "register" a
Lookup Table "Map<String, String>" which maps the symbolic name to a "valid"
Address in the parseQuery Method.
My thought was to generalize this concept for all drivers and allow them to
have a "global" alias map.
Regarding your note. I think this is one general problem of the current trent
towards "configuration by code". A similar example would be the @Query(native =
true, "my db specific query") of Spring Boot Data / JPA.
I can imagine use cases where one is certain that this is not going to change
(write a small helper app to scrape some data from a machine) and I agree that
there are many situations where one would not do that.
One solution could be the concept of "global" symbolic names where one ties
these "aliases" to the entity but is free to change the "real address" (or
query) behind the alias.
And even if we don’t provide such a feature I think its up to the programmers
(or users) responsibility to use this feature reasonable (see the JPA example
above).
Julian
Am 24.08.18, 11:12 schrieb "Christofer Dutz" <christofer.d...@c-ware.de>:
Hi Julian,
but wouldn't Symbolic Addressing, just be a different Query String for a
S7CommPluss driver instance? That could probably return:
- SymbolicAddressingQuery
- StandardAddressingQuery
...
Or could you reference structures with a symbolic name?
And you all have to keep in mind ... by using something like
"@Field('address string')" we will be producing code hard-coded to one type...
Chris
Am 24.08.18, 11:03 schrieb "Julian Feinauer" <j.feina...@pragmaticminds.de>:
Hey Chris,
this definition seems valid to me but is lacking one thing which is the
"killer feature" for me, the "symbolic addressing".
I spent some time the last week to "disassemble" parts of the TIA file
format (zap14).
The aim is to take the zap14 file and to extract all symbolic names and
the respective offsets (in not optimized blocks, of course).
I plan then to be able to init something (Connection, EntitiyManager)
with these information and use the symbolic names for the rest of the "session".
And my feeling is that this would fit better in an layer on top of the
current Connection than directly in the Connection.
What do you think?
Or is this something you would not incorporate in our JPA at all?
Julian
Am 24.08.18, 10:25 schrieb "Christofer Dutz"
<christofer.d...@c-ware.de>:
Hi Julian,
well I think I would define that "JPA" (Java PLC API ;-) ) layer
the following way (Joking, but lacking a name, I'll just call it JPA):
- Each driver can provide the types he likes
- Each request item can address exactly one of these types
- As soon as someone wants to reference more items with one query
and eventually re-use that --> This is where JPA comes in
Would that be a valid definition?
We already thought about something like that and there was a thread
to this [1] so maybe it's worth following up on that thread ... Have to admit
that I also have to re-read it first ;-)
Chris
[1]
https://lists.apache.org/thread.html/dfca30f6c3319e592c4a6412924edc9a31f2e18844204dc373eebc5d@%3Cdev.plc4x.apache.org%3E
Am 24.08.18, 10:18 schrieb "Julian Feinauer"
<j.feina...@pragmaticminds.de>:
Hi all,
I decided to start a new thread to answer to Sebastians mail
below regarding the Plc4X JPA Like layer.
First, I think, we should get a feeling of what we all think
this layer could or should do and what kind of features we want to incorporate
there.
From my perspective this layer should allow the following:
1. Provide access to fields via “symbolic names” or aliases.
They could be provided by the system (S7CommPlus) or they could be registered
with the “EntityManager”
2. Annotations for POJOs “PlcEntities”
I Imagine something like
@PlcEntity
class Pojo {
@PlcTimestamp
private long timestamp;
@PlcField(“%DB8:DBL4:INT”)
private int value;
}
Of course this is a very first sketch but I suggest to collect
our ideas on a Confluence to develop the idea “over time”.
Best
Julian
Am 24.08.18, 09:03 schrieb "Sebastian Rühl"
<sebastian.ruehl...@googlemail.com.INVALID>:
Hi Julian,
Depending on the type of change this might something I
could implement to ADS locally if its just a change of the Address format.
Chatting with Chris we stumbled over the size attribute in
a ReadRequestItem. This might become obsolete too as in its form right now it
isn’t that helpful.
FYI: I was about to read something like this from the plc
https://infosys.beckhoff.com/index.php?content=../content/1031/tcplclibutilities/html/tcplclibutilities_timestruct.htm&id=
<https://infosys.beckhoff.com/index.php?content=../content/1031/tcplclibutilities/html/tcplclibutilities_timestruct.htm&id=>
What we can see here that we need read 8 words from the
plc. We can do that by suppling the IndexGroup/IndexOffset and a Length(ADS) of
16 Bytes. Then I would need to chunk the response into 2 bytes. Im still not
sure if this is something I would integrate into the plc4x directly or into a
layer above aka JPA/Plc4xJPA (Java Persistence Layer alike) [maybe for the
basic structs of ADS it might be worth it]. Then there are complex types which
are mixed
https://infosys.beckhoff.com/index.php?content=../content/1031/tcplclibutilities/html/tcplclibutilities_timestruct.htm&id=
<https://infosys.beckhoff.com/index.php?content=../content/1031/tcplclibutilities/html/tcplclibutilities_timestruct.htm&id=>.
Here a chunking into 8 would not work as you would need to read fixed
different chunks (aligned to it type) from a byte stream. For this I would then
use a „RAW“ read and slice it in the application level (or PLC4XJPA).
Maybe working on the Plc4xJPA (working title you name it ;)
would be a good idea to get some impression of requirements from that side too
(I’ll will scope that on my next TODOs).
What is still missing in your PR suggestion „3) Define 2
types of ItemRequest/-Responses:“. But that might be ok as these changes are an
addition to that and as I wrote in the first sentence this might be local to
the S7 address format in the first step anyway so in my opinion you are good to
go (Maybe leave out the renaming of the query for now to keep the PR footprint
a bit lower).
Regarding API design: Its hard. It should be simple yet
powerful. So if the first iteration doesn’t fit well we just refactor it :)
Sebastian
