Hi Dale,
The direction thing was inspired by the way the Beckhoff ADS protocol was
designed.
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.
Chris
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>
wrote:
>
> 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
“@PlcProperty”
> 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
portability.
>
> 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
type.
>
> What do you think?
>
> Chris
