RE: [Embedlets-dev] Device polling

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

In regards to event vs state driven control: I see an issue with strictly
event driven Embedlets. The scenario for an industrial control is:

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.

This is a case where reverse chain (state) logic is required. The output
must be able to 'look' back into the logical path to determine its state.

You can specifiy that every embedlet should fire its event(s) on 'start' but
that would create a chaotic, eplileptic firing of events.

This leads to a conclusion that, at least for logical Embedlets, they may
have to process both forward (event) and reverse (state) chained logic. In
addition something has to initiate the reverse logic processing such as a
timer event or the start() method in the output embedlet.

>
> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> _______________________________________________
>
> Re: Outpost_ArchitectureDiscussionDocument_13.pdf
> Page: 12 (bottom)
>
> I'm a little concerned about allowing "device polling and timing" to be
> entirely in the domain of the embedlet service(s), if in its
> domain at all.
>
> I think it would be better if the embedlet service(s) *requested* specific
> polling "properties" from the JAPL, however polling is something
> that can be
> device and processor dependant (sometimes in the extreme).
>
> A processor or JAPL implementation should be allowed to define it's own
> polling rates etc... for instance, most temperature sensors
> require quite a
> bit of time to show any significant changes... the JAPL
> implementation will
> know how fast a device responds, and can tailor itself accordingly.
>
> I think what might be a slightly better approach (though I have
> not entirely
> thought it through) is if the embedlet service(s) could tell a
> JAPL impl. to
> notify it through an event when a change occurred... so for
> instance in the
> Temperature sensor example, the embedlet container would be able
> to give the
> sensor a change window, and receive an event when the actual JAPL
> implementation determined that it was warranted.
>
> In the case where the state of the peripheral was requested from
> the remote
> system, it would be a fairly simple task for the outpost module
> to store the
> last state and return that. Some devices of course should not be event
> driven, but most I can think of off the top of my head would best be
> implemented that way.
>
> What this means, is that the embedlet service(s) have no control over the
> polling or timing rates etc... which is the opposite of the current spec.
> discussion (and why I bring it up).
>
> Thoughts?
>
> - Brill Pappin
>   Rogue Robotics
>   www.roguerobotics.com
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
> are you planning your Web Server Security? Click here to get a FREE
> Thawte SSL guide and find the answers to all your  SSL security issues.
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
> _______________________________________________
> Embedlets-developer mailing list
> Emb...@li...
> https://lists.sourceforge.net/lists/listinfo/embedlets-developer
>