RE: V4 Design: Record Processing

["Liyu, Andrei" <liyua@ornl.gov>]

This is not comments. Just my (maybe incorrect) vision :)

- Motivation page/Example.
	Software structure should have another higher level for some
motors, registration part (=sample data) and so on. That level can take
care about synchronization problem. From my opinion software structure
should be hierarchal (not flat) and has only vertical connections (no
horizontal links, for example, between motors).
	"Wait until CA client has fetched the data". I see another big
problem. Accelerator systems can be split to two types - technologies
(vacuum, power supplies ...) and diagnostics (BCM, BLM, BPM). Main task
of technologies systems control system and sometimes send data to
client. Main task of diagnostic systems catch data and send to client.
Now look what is CAS-server thread priority? 	Also there is
experimental physics system and their behavior.
- Motivation page/Scan, motor, etc records HELP
	I think the best approach is native :) Try to image 
	- no computers! System can be driven locally by handles,
potentiometers and so on. 
	- operator comes and drives
	- ...
	- after that YOU need to reflect in software 
		- how operator splits system on subsystems (=structure)
		- operator's behavior/actions per subsystem.

Have a good day, Andrei Liyu

 
	


-----Original Message-----
From: Marty Kraimer [mailto:mrk@aps.anl.gov] 
Sent: Wednesday, July 13, 2005 7:42 AM
To: core-talk@aps.anl.gov
Subject: Re: V4 Design: Record Processing



Benjamin Franksen wrote:

>On Tuesday 12 July 2005 17:52, Tim Mooney wrote:
>  
>
>>I liked most of the original proposal, and I'm not sure what the Wiki
>>page that replaced it is trying to say.  I don't understand how the
>>PROC field, a blanket command to process the record, is replaceable
>>by a 'processState' field, which seems not to be a command but merely
>>a state indicator.  If it is a command, I don't think it helps very
>>much, because it would require an outside agent to know too much
>>about how the target record operates.  I don't think we can guess in
>>advance all the states a record might actually be in anyway.
>>    
>>
>
>I think the 'processState' is not to replace PROC (a command field) but

>rather to replace PACT (a status field). That is, the record's process 
>routine decides what to do depending on the current processState. Thus,

>whenever record processing would want to suspend operation in order to 
>wait for an event, it would set processState and return to the caller. 
>It's a generalization of the way the PACT field is handled in V3.
>
>Marty, please correct me if this is wrong.
>

You are correct.

Benjamin,

During the developer's meeting yesterday we had a discussion of V4 
record processing.
I am attaching the presentation I prepared. Not the 2nd slide which 
states that this is not even close to final design.
The V4_Design:_Record_Processing wiki needs major major changes based on

the presentation and especially on yesterday's discussion.

Marty