09 Mar 2004 rev. 10 Mar 2004 rev. 11 Mar 2004 The more one explores, the more overwhelming it appears. Here's a start. I really dont know what #3 & #4 below might look like. At this point I've not the slightest inkling which is less work or more work. RonC says he wants to avoid writing any new VMS code, yet people want to have all the higher-level analysis usable that the SCP can provide. That mostly excludes #3 & #4 below (certainly excludes #3). Yet, speaking just for BPM data acquisition, I'd start by considering some additions in intermediate-level VMS code, especially if one wants to integrate IOC-based BPM data acquisition with our MPG-coordinated method. If on the other hand IOC-based BPM's have only one way of being read out, then one can consider IOC-based BPM data to be generally "sitting there" for anyone to acquire after the fact, and VMS code could be added to merge IOC-based BPM data with iRMXmicro-based BPM data by matching on pulse id, something we havent done anywhere that I know of until only very recently. Then MPG doesnt have to be asked to do any coordinating at all of specifically IOC-based BPM data acquisition. So one basic question is: how will IOC-based BPM's work, and will they be like iRMXmicro-based BPM's in the sense that data acquired in the mode requested by one requestor is generally useless (and hence left unavailable) to any other requestor? In the following four scenario-beginnings I'm OMITTING consideration of the micro's 360-Hz interrupt-driven code and the micro's non-interrupt-driven code that sets up the 360-Hz code's things and takes them apart again. The 360-Hz code includes beamcode choice (the famous camac F19 broadcast = 8-bit micro-specific reduction of 128-bit PNET message (the F19 is what drives the PDU's)); and includes control of beampulse-synchronized operations (e.g., BPM control & readout, sometimes one beampulse, sometimes many, sometimes a "scan" using synchronized stepping of beam-controlling or magnet-controlling devices). 1. iRMXmicro driving IOC as slave: IOC talks to all new non-camac-based, i.e., VME-based, devices. As now, camac commands originate only from iRMXmicro (or "remote" from VMS); either usual MBCD or EJS FECC talks to camac SLC serial crate controllers (SCC's); this choice is independent of IOC involvement. Anything that ordinarily talks to an IOC is able to talk with this IOC. In addition to VME-based PNET receiver, we have to have relatively fast link between given iRMXmicro and given IOC, not necessarily as quick as 360 Hz. Some operations allow distinction between camac and VME to be made on level of individual commands to individual devices (i.e., command package is either an MBCD/FECC package or an IOC message); certainly most BPM operations wont be supportable within that amount of blindness (usually called transparency). For any device, SLC operational database has to somehow indicate whether device is (usual) camac-based or (new) IOC-based. iRMXmicro application code has to be taught (per device) how to distinguish between camac-based device and VME-based device, and how to tell IOC to perform needed operation on given device; IOC has to learn each command which iRMXmicro may send to it. IOC has to learn how to collect data from its BPM's, and how to either a) package & send BPM data directly back to requesting SCP (which has to be taught how to receive it) or b) sends BPM data back to iRMXmicro to be included with data from camac-based BPM's if any. Would we have "virtual IOC" like "virtual camac" (i.e., remote individual commands to make it look like the micro is not in the way, as we have now remote camac commands to make it look like the micro is not in the way)? 2. IOC communicating with VMS SCP much as iRMXmicro does (whether iRMXmicro is SLCnet-based or Ethernet-based is irrelevant here): Kinds of "micros" as now recognized in SLC operational database as possible residence of a given device has to include new kind (namely IOC). SCP has to be taught that now we have IOC's which are sort of like micros, and as a SCP now knows how to deal with things micro-by-micro, SCP will in various places have to learn that so-and-so IOC-based device behaves slightly differently from how a similar-but-different iRMXmicro-based device behaves. IOC has to learn how to answer any of very large number of possible messages that now go between SCP and iRMXmicro. Probably many messages will get only a "not-yet-implemented" response if sent. Maybe IOC also learns how to request & receive its portion of SLC operational database at IOC bootup time (and DBEX has to be taught how to send it), or maybe IOC (in its new code which performs iRMXmicro-like functions) does its dblist's/dblget's/dblput's to a database server process running on Alpha, maybe neither; if neither then SCP has to know to include in any message all database items that will be needed to service that message (making IOC-destined messages look all that much more different from iRMXmicro-destined messages of similar kind). 3. Let Unix-based Epics code do the data integration: DisplayManager asks ChannelAccess for BPM data; ChannelAccess asks IOC's and a SCP for same (if periodically then with easily controllable limit to avoid shutting others (ffeedback) out). (Does this make sense? (I know almost nothing about Epics.)) That SCP responds to such a request by using one of a few canned DGRP's, and sends acquired data back to Unix-based code, which integrates that data with data acquires from IOC's. ChannelAccess learns how to send commands to that SCP to perform other than IOC-based control functions, and SCP has to learn how to service those commands. 4. Let SCP do the data integration: Teach SCP to talk to ChannelAccess to perform IOC-based control functions and to acquire data from IOC's; in other words, teach SCP how to distribute commands to micros as now as well as to ChannelAccess (latter for controlling non-iRMXmicro-based devices). Regarding communication between SCP and IOC, and the "SLC message services": there are currently four "message service" pathways so to speak between SCP and iRMXmicro: one for most request & reply transactions; two for databaase transactions (which are performed by process named DBEX running in prod Alpha and dev Alpha); and one for TIMEX (which is the name of another process running in prod Alpha and dev Alpha). All messages in the first category ("most request & reply transactions") have a header in which a 7-bit field specifies iRMXmicro "subjob": MGNT, TIME, BPM, STAT, ANLG, CAMV, TEST, etc. The second category ("database") includes micro's database download which the micro explicitly requests at its bootup time, and all subsequent updates traveling in either direction. The third category ("TIMEX") includes TMATRIX download which the micro explicitly requests at its bootup time, and possible updates by a SCP of the micro's "regional beamcode" setup (by which I mean possible update by a SCP of the micro's DUPCD conditional expressions), and does NOT include timing value updates (namely "enter TDES", or turns of a timing knob -- these go in the first category to TIME subjob). For any micro, these three categories go either via SLCnet or via IP/TCP, the distinction being invisible anywhere more than a very short distance above the very lowest level. If via IP/TCP then they go through a "proxy" node, which is PX00 for the production network and PX01 for the development network. Thus for IP/TCP, the micro at its bootup time establishes three TCP connections with the correct proxy. Question: should SCP <-> IOC communication go through the respective proxy or never mind the proxy? Probably through the proxy, meaning that the IOC has to learn details thereof, not difficult. Regarding database: If SCP higher-level analysis & display code should have a healthy & active appetite for data from IOC-based devices (e.g., BPM data) then surely (continuing the example) IOC-based BPM's will have to be represented dually, each one in both SLC operational database and in IOC native database. Code in at least the IOC will have to know how to follow 1-1 correspondence in either direction for any such device. More particularly, collections of devices are generally specified by list of micro names with unit number range for each micro; IOC will have to be able to make clear sense of the latter. Further, for supporting IOC-based devices which the SCP will want to control (e.g., a magnet power supply), the IOC's imitation of the iRMXmicro's database receiver will have to (variously) know how to deposit any received update dually, in the IOC's copy of the SLC operational database and in the IOC's native database (and the latter may involve some kind of active signaling none of which is available in the iRMXmicro's database receiver).