Minutes from the 6/30/04 LCLS GSD meeting. I have added additional detail for some things. GSD = Getting Stuff Done for the SLC Aware IOC project (1) Meeting: We will meet at 10:00 every Wed in the B5 2nd floor Shoaee Chalet. ACTION - Steph to take notes and distribute. Update on web page. See: http://www.slac.stanford.edu/comp/unix/package/epics/lcls/slc_ioc/ All (except Bob) can edit the pages in /afs/slac/www/comp/unix/package/epics/lcls/slc_ioc. (2) People's vacation schedules: Diane: 8/2 to 8/13 Dayle: 7/27 to 8/11 Ron: 7/26 to 8/13 (maybe week of 7/19 too) Debbie: Now to 7/12 Tony: Now to Sept Steph: Not sure (3) Prototype: SLC message service on the IOC. Set up virtual IOC for testing. Set up IOC "micro" on the SCP. Test message transfer from the SCP via the proxy to the SLC IOC with reply back (normally just a status return). Test that disconnects/reconnects are handled properly. Test that data types are properly converted. ACTION: Diane and KenU DUE: July 23 (4) Work: CMLOG client on the IOC. Add the CMLOG client to the 3.14 IOC. Add code needed to hook the cmlog client to EPICS error logging using the add/remove log listener function (see chapter 10 of the App Dev Guide). Check tech-talk to see if this has been done already. Steph, Dayle, Ron Mackenzie and James Silva are consultants. Please put this code under $EPICS/site so that all of SLAC can use it (it is not unique to the SLC IOC). Test that error messages make it: IOC errlog -> cmlog client -> dev cmlog server -> dev cmlog frwd browser -> mccdev err_int -> mccdev errlog ACTION: Diane DUE: July 30 (5) Check if JLAB still owns and actively maintains CMLOG. If not, SLAC should consider taking it over. ACTION: ? DUE: Later (6) First Draft of SLC IOC Architecture ACTION: Steph DUE: July 30 (7) Consider alternatives for best place for the IOC's part of the SLC database: (a) Leave it on VMS and update it using some not-too-complicated socket interface (requires that gets and puts be grouped as much as possible) (b) Add it to the SLC IOC and port (a true port) database gets/puts/etc and async/on-demand updates to the VMS copy using the interface to the VMS DBEX process. Ron says this port effort is not too hard. (c) Use a third "gateway" node to hold the SLC database for all SLC IOCs and use some protocol (ie CA) for data transfer with the IOCs and the DBEX interface to update the VMS copy. ACTION: Steph and Ron DUE: July 23 (8) Consider alternatives to the mapping between the EPICS database and the SLC Database: (a) One extra record per primary/secondary instance using INP and OUT as pointers into the SLC database memory (whether the database resides on the IOC or the alpha). (b) One record per primary instance with all secondaries as fields. (c) Develop a special task that uses an automatically-generated table containing the links between EPICS records and the SLC database. This task will transfer data between the SLC and EPICS databases. ACTION: Steph and Ron DUE: July 30 (9) Some standards: (a) use C (b) keep existing VMS-style status codes as needed (10) Start condensing functional requirements based on the messages and what the existing micro jobs currently do. This is best done by examining the micro job source, reading any available write-ups of the micro jobs (POOP, BUG, ?), talking to maintainers. Split this task up between Steph, Dayle, and Ron (or whoever Ron designates). ACTION: Steph to split up the jobs DUE: July 7 ACTION: List of func reqts DUE: Aug 27 (11) Is fastfeedback needed to do SLC operation between IOC and other standard SLC micros? (a) we have all 20-30 bpms and some set of magnets (b) Or can we do fast feedback over dedicated ethernet ACTION: Linda and ? DUE: July 30 Stephanie