Chris,
that is exactly my line of thought as well.

On Tue, Mar 6, 2018 at 4:43 PM, Christofer Dutz <christofer.d...@c-ware.de>
wrote:

> Hi Niclas,
>
> as far as I understood Polygene especially after your examples. I would be
> hesitant to use this per default in PLC4Xs core. It does seem to add quite
> a lot of complexity which I personally would like to avoid. I don't want to
> confuse potential users. Especially the ones peeking into our world from
> the Automation side of the industry. If we present them with something they
> can't immediately wrap their heads around, I doubt we will have much
> adoption from their side.
>
> However if it was possible to use Polygene to implement some "JPA for
> PLCs" like functionality, I think a dedicated integration module for this
> alongside examples would be a good way to go.
>
> What do you (all) think?
>
> Chris
>
>
>
>
> Am 06.03.18, 07:24 schrieb "hedh...@gmail.com im Auftrag von Niclas
> Hedhman" <hedh...@gmail.com im Auftrag von nic...@hedhman.org>:
>
>     Polygene is highly opinionated, for better and worse. Minimally,
> Polygene
>     requires to start a runtime, and that everything needed is declared
>     explicitly upfront at boot time. The minimal start code is something
> like;
>
>
>     public static void main( String[] args )
>         throws Exception
>     {
>         app = new SingletonAssembler( module -> {
>             module.transients( Boiler.class, Ahu.class, Fan.class )
>                   .withMixins( Plc4xBackingPropertyMixin.class );
>
>             module.services( Plc4xPollService.class )
>                   .withMixins( Plc4xModbusDriver.class );
>             :
>             :
>         } );
>     }
>
>
>     If one wants to implement additional behavior in the Boiler class,
> then you
>     create Mixin classes. Let's say we want to capture the temperature
> once an
>     hour.
>
>     @Mixins(HistoryMixin.class)
>     interface Boiler
>     {
>         @Plc4x( url="s7://......", period=60000 )
>         Property<Double> temperature();
>
>         List<Double> temperatureHistory();
>     }
>
>     public abstract class HistoryMixin
>         implements Boiler, Scheduled
>     {
>         int maxHours = 24;
>
>         LinkedBlockingDeque<Double> history = new LinkedBlockingDeque<>();
>
>         @Override
>         public void tick()
>         {
>             Double value = temperature().get();
>             history.addLast(value);
>             while( history.size() > maxHours )
>             {
>                 history.removeFirst();
>             }
>         }
>
>         @Override
>         public List<Double> temperatureHistory()
>         {
>             return new ArrayList<>( history );
>         }
>     }
>
>
>     Above, let's say that "Scheduled" is a service to allow something to
> get a
>     tick() upon some period/interval. What I want to draw attention to is
> that
>     the HistoryMixin is implementing only the method(s) it need to, and
> that
>     the Boiler interface can declare such permanent functionality as an
>     annotation, instead of as a start-up declaration in the assembly. The
> fact
>     that the Mixin is abstract is handled by the runtime and it will
> compose
>     all these individual (so called) fragments into a single object (we
> call it
>     a Composite) when you instantiate it from the builder.
>
>     It is a whole new different way of writing software. Some people love
> it,
>     and others have a hard time understanding how it can possibly work.
> Just
>     scratching the surface, and please read
>     https://hedhman.wordpress.com/2017/05/10/introducing-apache-polygene/
> for a
>     larger introduction to the subject.
>
>
>     If you don't want to write the entire project in Polygene "style", you
> need
>     to either use the Spring library bridge (possibly need upgrade that
> one a
>     bit), where each Service in Polygene will show up as a Spring bean, or
>     leverage various points of external hooks for Polygene, such
>     importedServices.
>
>
>     Don't want to bore you too much.
>
>
>     My actual main point was that your suggestion/idea can quickly become
> quite
>     a large undertaking and detract from the primary focus that (I think)
> PLC4X
>     should have. And bringing up Polygene was more to show that what you
>     suggest can be done very easily already in Polygene, and all that work
>     wouldn't be needed.
>
>
>     Cheers
>     Niclas
>
>
>     On Tue, Mar 6, 2018 at 4:35 AM, Christofer Dutz <
> christofer.d...@c-ware.de>
>     wrote:
>
>     > Hi Niclas,
>     >
>     > after recovering from that nasty Flu, that is plaguing Germany at the
>     > moment, I am working on catching up on what I missed.
>     > I tried to follow, but some things I felt to worn out to work my head
>     > around.
>     >
>     > Could you elaborate a little on Ploygene? How would this allow
> extending
>     > our requests with additional magic? Does this work in a simple way:
> No need
>     > to configure plugins, code generation or learn some complex API? I
> would
>     > like to keep PLC4X as simple as possible, but as extendable as
> possible.
>     >
>     > So I'm always open for new ideas (
>     >
>     > Chris
>     >
>     >
>     >
>     > Am 20.02.18, 03:32 schrieb "hedh...@gmail.com im Auftrag von Niclas
>     > Hedhman" <hedh...@gmail.com im Auftrag von nic...@hedhman.org>:
>     >
>     >     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.
>     >
>     >
>     >
>     >     Cheers
>     >     Niclas
>     >
>     >
>     >     On Tue, Feb 20, 2018 at 5:32 AM, Christofer Dutz <
>     > christofer.d...@c-ware.de>
>     >     wrote:
>     >
>     >     > 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
>     >     >
>     >     >
>     >     >
>     >     >
>     >
>     >
>     >     --
>     >     Niclas Hedhman, Software Developer
>     >     http://polygene.apache.org - New Energy for Java
>     >
>     >
>     >
>
>
>     --
>     Niclas Hedhman, Software Developer
>     http://polygene.apache.org - New Energy for Java
>
>
>


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Reply via email to