6 July 1986 Support For the 192 Multiwire Controller ------- --- --- --- --------- ---------- There are two types of database devices for the 192: those which retrieve single calculated values for the parameter page and those which support the specialized multiwire programs. These two types of devices have different SSDNs and are supported by different front end device drivers. At the current time this document describes only the parameter page devices. Support for the special application page will be added shortly. Parameter Page Devices --------- ---- ------- Every multiwire paddle ends up with 8 database entries. There is one each for calculated mean, sigma, chi squared, and area. The set of four is entered twice: once for the vertical wires and once for the horizontal wires. A 192 card can support up to 4 paddles, which have 32 database devices. The Reading property addresses the 192 card to retrieve the calculated values, but the Basic Status and Basic Control properties address the 184 card connected to the motors and limit switches. It is possible (it wasn't obvious) to support the motors and limit switches with normal 184 card services. Thus a parameter page multiwire device will have one format for the 192 card Reading property and another for the 184 card status and control properties. We note a potential difficulty here. The 192 card, in addition to the 184 card, also knows the status of the various wires. When we decide whether to return a given calculated datum we rely upon the 192's version of which wires are actually available. However the operator gets to see only the 184's version of the state of the world. I ultimately decided to address the 184 card directly for two reasons: 1) The motors are controlled only by the 184 card, which raises the possibility of the opposite discrepancy if we read the status from the 192 card. 2) The 192 card is run by a microprocessor, while the 184 card is (more reliable) dumb hardware. Neither of these is compelling and I am open to requests to read the positions of the wires from the 192 card instead. Reading Property ------- -------- The SSDN for the Reading property ONLY looks like this: +-------------------------------+ | 0 | +-------------------------------+ | 4B (hex) | OID = 4B (hex)| +-------------------------------+ | crate | slot | +-------------------------------+ | 4B (hex) | sub-code | +-------------------------------+ Where the "sub-code" is 8 bits like this: XXowwwcc c = channel 0 - 3 w = which calculated value: 0 = mean * 10 1 = sigma * 10 2 = area 3 (error) 4 = max ADC value 5 = chi sq. * 10 6 = zero adjustment 7 = out/horizontal/vertical o = orientation: 0=horizontal 1=vertical Although not all the calculated values have been requested the capability exists to define devices to retrieve any of them. When the console requests one of the calculated values on a plot or a parameter page the front end needs to take care of the following issues: 1) Return data from each booster cycle exactly once. 2) Do something meaningful in the periods where there is no beam. 3) Return an error if the requested wires are not actually in the beam. The first problem arises because there is no natural synchronization between beam pulses and front end data collection. Even if the front end tried to synchronize data collection with clock events, there would be no guarantee that the 192 card would complete its calculations in a predictable time. Fortunately the 192 card keeps track of which beam pulses have been collected and processed during the current cycle. The general approach of the front end is to remember the last beam pulse reported to the console and to try to report them all in order. If the 192 gets ahead of the front end then the data remains stored in 192 memory; if the front end gets ahead of the 192 then the front end will delay a bit and simply not return a value for a moment. It is my belief that as long as data is requested at 15hz then this scheme should work famously. If data is requested at some slower rate then values may be missed, but there is no help for it. At least it should behave in a graceful manner. When there is no beam, and the last calculated value has been returned from the previous cycle, then the front end will repeatedly return that last value. This is necessary to get meaningful values onto the parameter page, although it may look funny on a slow time plot. The 192 card helpfully provides two Camac commands, one for horizontal and one for vertical, which will No-Q if the wires are not oriented correctly. I intend to use these commands. The result will be that if you are trying to plot, say, horizontal data, and the paddle is not in horizontally, then you will get an error. Unfortunately the only error the 192 card returns in this case is No-Q, which is too general. It may, for instance, indicate a dead card. Thus when the front end gets this error it needs to disambiguate it by reading the wire status. If, in fact, the No-Q was caused by a wire being out of position, then it will return error code -67. Basic Status Property ----- ------ -------- The Basic Status uses a 184 style SSDN. The important parameters in the SSDN are: A) The MASK identifies which hardware bits are used for this device. The multiwires in Ducar's writeup are therefore assigned masks of: 000F Motor 1 (a.k.a. channel 1) 00F0 2 0F00 3 F000 4 B) The SHIFT bit should be on. This will ensure that the status for EACH of the 4 motors is right-justified, so that they all look IDENTICAL. Using the above convention every parameter page device will have the same 4-bit long basic status. What I am saying here is that the information as to which 184 bits are assigned to which motor is buried within the mask field of the SSDN. There is a systematic difference between the horizontal and vertical orientations which has to be reflected in the PDB for basic status. This shows up, for instance, in the ON mask which will be '80'x for the horizontal devices and '40'x for the vertical devices. Basic Control ----- ------- The SSDN for Basic Control is also a 184 style SSDN. Again, we make use of the MASK and the SHIFT to regularize the data. In this case the masks are: 0003 Motor 1 0030 Motor 2 0300 Motor 3 3000 Motor 4 With the Shift bit set all basic control will be right-adjusted to a small integer. This enables you to set up your PDBs thusly: Horizontal Device ON mask: 1 OFF 0 Vertical Device ON Mask: 3 OFF 0 This will enable you to move paddles into or out of the beam from the parameter page. EMC --- The EMC will be 'attached' to the 184 card. Do not worry about the 192 card not having any labels on page D20: the devices for Glenn's page will take care of it. One reason for attaching the EMC to the 184 card is that digital alarms, if you should desire them, are automatically available. You just have to include a digital alarm property. The first byte of the EMC (the low order byte of the first word) is the front end node number: 16 (hex) Dec-BS 18 Dec-T 1A Dec-S 1B Dec-P The second byte of the EMC (the high order byte of the first word) is a constant 2. The rest of the EMC is an EXACT COPY of the last 3 words of the BASIC STATUS SSDN.