RE: [Embedlets-dev] Re: Device polling and embedlet dependencies/initialization

[Christopher S. <cs...@oo...>]

>
> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> _______________________________________________
>
> Chris postulates a polling scenario:
>
> > 1. An output (embedlet) controls a raw material supply function and must
> > be off on startup. 2. The output is controlled by a threshold Embedlet
> > monitoring the raw material supply level. 3. The threshold embedlet is
> > event driven and fires when the level exceeds an upper value or drops
> > below a lower threshold. 4. When the level is low the output should come
> > on to start the raw material feed. When the upper level is exceeded the
> > output should turn off to stop the supply.
> >
> > The problem occurs when the supply is initially low and not changing
> > because the output is off. The threshold embedlet sees no change so the
> > event is not fired and the output remains off... the
> manufacturing process
> > cannot start.
>
> The way I envision you would handle this scenario is as follows:
>
> 1) The Threshold embedlet would be listed as "dependent" on the Output
> embedlet in the application config/wiring file (this might be
> derived from who
> consumes and who produces events of a particular type).  Using this
> dependency info, the lifecycle service will ensure that the
> Output embedlet is
> started and listening for events first.  We might need to find a
> better word than
> "dependent" here....since the usage is a bit backwards.  From an
> event/messaging paradigm, consumers should be started prior to producers,
> for obvious reasons.
>
> 2) The Threshold embedlet will thus be assured that when it's
> start() lifecycle
> method is called, that the Output embedlet is started and running
> (listening for
> the threshold events).
>
> 3) The Threshold embedlet would be responsible (in the start()
> method) for
> initializing itself.  That is, it should check the raw material
> supply level (likely
> using a JAPL API call to the sensor that measures this), and if
> the level is low,
> it should post a "tart material feed" threshold event.

This is what I am refering to as 'reverse chain' because if the Threshold is
preceeded by other embedlets such as a calibrator the processing flow is
going in reverse, based on demand as opposed to forward based on events. The
Threshold embedlet is 'demanding' the state of the embedlet(s) that preceed
it in the event chain. On startup the preceeding 'producer' embedlets will
not have been started since the 'consumer' needs to start first!

If every embedlet posts an initial event in its 'start()' method the
consumers will be firing events base on incomplete information.

The OopScope OPC container does what you have proposed (minus the reverse
chain):

1. Initialize and link components in event order.
2. Start the components in reverse event order. This enables the event
source/listener chain.
3. Process events as they occur....
4. Stop the components in forward event order to 'dry up' the events.

This straight-forward method has run into the stumbling block that I
outlined, both with boolean and numeric processing. I have worked around it
by making critical logic flows level sensitive, driven by a timer so that an
event is generated every timer cycle. This bypasses the efficiencies of an
event driven system, however.

I am thinking that embedlets that are 'Inputs' need to have a
checkInitailConditions() method that is called prior to start(). This would
allow input embedlets to stage an event to fire when started based on the
expected state of the input relative to actual. Or maybe this is just built
into the start() method of inputs and is a documented not enforced behavior.

>
> 4) The Output embedlet would then receive this event at startup,
> and all would
> be well.
>
> The solution is based on the LifeCycle service controlling the
> sequence in
> which related/dependent Embedlets are started up, based on the config
> information.
>
> Andrzej Jan Taramina
> Chaeron Corporation: Enterprise System Solutions
> http://www.chaeron.com
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Embedlets-developer mailing list
> Emb...@li...
> https://lists.sourceforge.net/lists/listinfo/embedlets-developer
>