Hi Together,
As symbolic addressing is already implemented in ADS you can look there how it
is currently implemented.
Sebastian
> Am 24.08.2018 um 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
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
