Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Thu, 25 Feb 2010 18:14:40 -0600

On Thursday 25 February 2010 17:20:28 Benjamin Franksen wrote:
>
> I absolutely agree. It's just that in this case the language forces me to
> use shared variables instead of message passing *even though the underlying
> mechanism of synchronization is basically message oriented*.

Could you not have used an event flag or two to communicate start/done events 
between your state sets?  If you want to publish whether the slave is busy or 
not as a PV it can maintain that itself, but that shouldn't be the mechanism 
used to control it.  If the slave can accept multiple commands it could wait 
on more than one flag, or read a shared command variable after the command 
event flag goes off.

> My particular problem was directly caused by the (forced) separation (via
> global shared variables) between the synchonization (monitor event, pvPut)
> and access to the value transported. This is something that has bugged me
> ever since I learned about SNL. And it could be fixed by making a number of
> language-level changes (the underlying implementation of the sequencer and
> the generated C-code could remain almost the same):
>
>  o Allow variables local to a state or a state-set. Forbid or at least
>    discourage global variables. (Global constants are of course fine and
>    declaring them should be more directly supported.)
>
>  o All communication between state-sets should be via PVs or event flags
>    (what was the reason, again, not to call them semaphores?) which both
> may be declared at the top-level. One would need some sort of pv or channel
> data type that gets bound to a PV (at the top-level or local to a state
> set) in a way similar to the current 'assign..to' clause.
>
>  o Allow access (write or read) to a PV object only with a procedure call
>    that gets resp. returns a value; events from monitored PVs store their
>    payload into a local variable that must be explicitly bound in the state
>    declaration.

The state notation compiler and sequencer is no longer a bundled part of Base, 
so it could (and probably should) be gradually replaced by something better 
(preferably with a compiler/translator that doesn't use a lex/yacc parser 
written in C).  I would definitely encourage that kind of development...

- Andrew
-- 
The best FOSS code is written to be read by other humans -- Harald Welte

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System