Hi Dale,

The direction thing was inspired by the way the Beckhoff ADS protocol was 

There they sometimes Send Data alongside read requests and sometimes have 
strange "return what's in there and then overwrite with this" type of requests.
The Beckhoff support guy mentioned that they are used quite a lot. 

That was the main reasoning for me mentioning the direction thing. In general 
this could be set to a default of being bedirectional.


Am 19.02.18, 18:25 schrieb "Dale LaBossiere" <dml.apa...@gmail.com>:

    Doesn’t the user need access to the response code for each annotated item?
    I’m unclear on why a Direction is needed/desired.  Is it just for 
“documentation" of what is possible for an item at that address?  Maybe it 
would be checked when the annotated class is used in a Read vs Write request to 
verify the request makes sense for that item?  Or… ?
    Could you provide some small pseudo-code of how the app would use the API 
with such an annotated class.
    class MyAnnotatedClass { … };
    PlcConnection connection = PlcDriver(…);
    // make a read requests
    // access data in the responses
    — Dale
    > On Feb 19, 2018, at 6:16 AM, Christofer Dutz <christofer.d...@c-ware.de> 
    > Hi,
    > in the past I have been thinking how we can make the batch reads as 
simple as possible.
    > I would like to introduce an idea I had:
    > What if we started supporting annotated POJO classes? (The following 
names are just ideas …)
    > A POJO class could be annotated with some “@PlcEntity” annotation.
    > A property inside one of these classes could then be annotated with 
    > This PlcProperty could have the following attributes:
    >  *   Direction (Read/Write/Read&Write)
    >  *   Property (Name of a property that provides the address in the PLC)
    >  *   Address (Alternative to provide the address directly and give up on 
the flexibility to change the PLC-type / Protocol)
    > Providing would definitely be the less preferred option, but I guess we 
would have to provide a way that is extremely simple for new developers to get 
started. I wouldn’t want to overwhelm them with too much magic in the start.
    > The connection could be extended to look a (configurable) property file. 
A property property (😉) would then use this property map in the connection to 
get the real address string for the given property - hereby keeping the full 
    > Maybe it would be better to have two separate property annotations: one 
for property-based and one for hard-coded address strings.
    > The benefit would be that we then could simplify the integrations to 
frameworks like Edgent as we could create sources and sinks based on the POJO 
    > What do you think?
    > Chris

Reply via email to