Being the Overlord of Magic that can be done in Java, I have some comments
to make on this idea.

1. In principle what you suggest can already be done quite easily in Apache
Polygene, by creating a "generic mixin" that overrides the generic
PropertyMixin. Polygene is probably way more powerful than anything you
could dream up here. Although Polygene has a strong JSON serialization and
persistence "story", both fully pluggable, it does not use the Glasgow
spec, a.k.a JavaBeans, a.k.a "getter/setter naming convention", which has
been plaguing the Java community for 2 decades now.
If I created a Plc4xBackingPropertyMixin, which I think would only take a
few hours, maybe a couple of days, depending on how advance we want it, you
would end up with;

*public interface Boiler{*

*    @Plc4x( url="s7://......", period=5000, priority=low )*

*    Property<Boolean> running();*

*    @Plc4x( url="s7://......", direction=out )*

*    Property<Boolean> onoff();*

*    @Plc4x( url="s7://......", period=500, priority=high )*

*    Property<Boolean> alarm();    @Plc4x( url="s7://......", period=5000,
priority=normal )*

*    Property<Double> temperature();*

and in the "assembly", we would need to override the default PropertyMixin,
by doing;

    *module.transients( Boiler.class ).withMixins(
Plc4xBackingPropertyMixin.class );*

That said, Apache Polygene is quite overwhelming for new users, so although
the idea is very persuasive for myself, I am under no illusion that others
are as easily convinced. And it is quite likely that I will create this,
since you brought it up, and the effort is rather small.

2. I have been doing PLC Master apps in Java since 1997 (and other
languages since 1984), and experience tells me that the biggest challenge
for really large applications is how to handle "permanent" vs "temporary"
values. What do I mean? In really large systems, it is not feasible to scan
all variables at all times. The latency will not be acceptable. Instead, we
acknowledge that many values are only of interest when someone is looking
at them, be it a person or a datalogger. Not saying it is unsolvable, but
it adds a fair bit of complexity in a Java world with GC, and relying on
finalize() is not really a solution and the outside "javabeans-friendly"
frameworks are clueless about resource management.

GutFeeling(tm) says that this can and should probably be postponed until we
have more experience and made all compatibility-breaking changes that comes
along the way.


On Tue, Feb 20, 2018 at 5:32 AM, Christofer Dutz <>

> 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" <>:
>     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 <
>> 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

Niclas Hedhman, Software Developer - New Energy for Java

Reply via email to