Hi Julian,
Good idea. :)
What I had in mind:
@PlcEntity(“someAddress with the length of bytes to read“)
class Pojo {
@DataChunk(oder = 2, bytes = 4)
private int numberOfEvents;
@DataChunk(oder = 1, bytes = 28)
private string eventDescription;
}
With the above it would be easy to map this type from ADS
(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=>):
@PlcEntity(„somesymbolicAddress:16Bytes")
class Timestruct {
@DataChunk(bytes = 2)
int year;
@DataChunk(bytes = 2)
int month;
@DataChunk(bytes = 2)
int dayOfWeek;
@DataChunk(bytes = 2)
int day;
@DataChunk(bytes = 2)
int hour;
@DataChunk(bytes = 2)
int minute;
@DataChunk(bytes = 2)
int second;
@DataChunk(bytes = 2)
int milliseconds;
}
As you see above we could make the order optional and take the order of fields
as mapping (would be a bit wonky though). The benefit of the above would be
that this could be read in one request. Additionally we could als provide
support for a „virtual entity“ like you described below where the plcentity has
no attributes at all and the elements come from different address areas of the
plc (this might be mapped then to multiple plc requests under the hood).
All in all it would be a combination of both however I would rather rename the
proposed @PlcField to a @PlcQuery. What do you think?
Sebastian
> Am 24.08.2018 um 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
>
