This document is under development. Use at your own risk
This document is under development. Use at your own risk
© 1999, 2001, 2009 S.
M. Wolfe
MIT Plasma Science & Fusion Center
1. Introduction A. What does the PhysOp do? B. Scope of this document 2. Overview of the Plasma Control System A. Engineering Control B. Plasma (real-time) Control 3. Coil and Power Systems Description & Overview A. Poloidal Field Coils B. Toroidal Field C. A-coils 4. Other C-Mod Subsystems Controlled by DPCS A. Gas puff system B. there is no B (yet) 5. Functional Overview of the Digital Plasma Control System A. Concept and general description B. Elements of the realtime loop C. Standard Loadable Procedures D. Details of software hierarchy, interactions E. File locations, software maintenance F. Hardware Configuration G. MDSplus tree \CMOD::HYBRID 6. PCS Interface Software A. PCS Main Screen - Shot Level Commands B. Wires, Segments, etc. - Segment Commands C. Waveforms - All P and All V Screens D. Algorithms, Gains, etc. - the EDIT_WIRE Screen 1. Wire Names 2. Observers (also called "Predictors") and their algorithms 3. Wire level commands 4. PID Gains 5. Controllers (and their algorithms) E. Loadable Procedures 7. Startup - The Black Art A. Basic Procedures - field null, pressure,voltage B. Tuning and Tweaking 8. Shape Control, etc. A. Conceptual Description B. Practical Considerations 9. Runtime Procedures A. Run Plan B. Signing in C. Invoking PCS D. Standard Scope Views E. MFLUX, MFIL and all that F. Alarms and Warnings G. Log keeping and Summary 10. Maintenance, Testing, and Troubleshooting
At Alcator C-Mod, the Physics Operator (or PhysOp) is responsible for producing the plasmas specified by the Session Leader to accomplish the goals of each run. The physop plans and executes the tactics required to carry out the run plan.
The Physics Operator works closely with the Chief Engineering Operator (EO) and the Session Leader (SL), the other two principals involved in the direction of each run. In a formal sense, the PhysOp provides the communication conduit between the Session Leader and the Engineering Operator, although in practice three-way communication is common.
The Physics Operator specifies changes in power supply timing, limit settings, commutation timing, gas fill, etc., to be performed by the Engineering Operator, as necessary, subject to previously defined limits and constraints. These parameters are set by the EO either directly on PLC interfaces, or using the MDSplus interface to the Engineering tree to control CAMAC timing signals. It is also the responsibility of the PhysOp to request opening of specific diagnostic gate valves and shutters, after consultation with the relevant diagnosticians.
Real-time control of the plasma parameters is controlled by the Physics Operator, using the Plasma Control System (PCS) interface software to the Digital Plasma Control System (DPCS), which provides realtime open and closed loop demand signals to the power supplies, gas valves, and potentially other subsystems. In practice, the main part of the PhysOp's job is specifying waveforms and feedback algorithms which control the realtime function of the DPCS.
In addition, in consultation with the Session Leader, the PhysOp requests that the Engineering Operator provide access to the test cell and/or diagnostic labs, and other areas which are normally locked out by the access control system. The Engineering Operator has on-site responsibility for the safe and orderly conduct of the run, including both personnel and equipment safety.
Prior to each run day, it is the responsibility of the assigned Physics Operator, after consultation with the Session Leader(s), to publish (electronically) a Physop Run Plan (under the PO_PLAN topic of the electronic logbook) describing the experimental plan for the day, including technical goals of the run, intended shot sequence (with contingencies) and engineering settings for at least the initial shots. The PO_PLAN must also prescribe any pre-run conditioning or preparation activities to be carried out, such as discharge cleaning.
During the course of the run, the Physop will normally enter a record of changes for each shot along with the results under the PHYSICS_OPERATOR logbook topic.
Following each run, the Physics Operator is required to prepare a summary of the day's activities, describing the conduct of the run from the operational point of view. This summary should specifically include a description of any problems encountered and the measures taken to remedy them, as well as any new techniques or noteworthy events. This summary is to be entered in the on-line logbook under the PO_SUMMARY topic.
Only individuals who have undergone specific training for the task may serve as Physics Operators. At this time, Physics Operators must be professional scientific or engineering staff, including MIT and collaborating personnel; students are not presently eligible to serve as PhysOp. These requirements contrast with those for Session Leader, for which any student, collaborator or staff member is eligible, and for which only minimal special training is required. Engineering Operators are drawn from the technical and engineering staff, and must also undergo detailed training. Physics Operators for each run are assigned (in principle) at least one week in advance. Where possible, available PhysOps are assigned to runs for which they have an interest and have participated in the planning, e.g. by co-authoring the mini-proposal.
This document is an attempt to collect in one place the essential facts, procedures, and practices required by a C-Mod Physics Operator. It is intended as a reference for practicing Physics Operators and as an introduction/text for prospective PhysOp's. Reading this document is NOT considered a substitute for live training and practical experience in running the C-Mod tokamak. An individual may become qualified to serve as a C-Mod Physics Operator only by completing the course of training.
Version 1.0.x of this document provided descriptions of the Hybrid Control Computer hardware, which has now been retired from service. Beginning with Version 2.0, these sections (primarily in Chapter 2, 5, 6 and 10) have been updated to describe the current state of the Digital Plasma Control System (DPCS). Note that many of the concepts and structures developed for the Hybrid system are still present, and are likely to persist in some form as the control system continues to evolve.
For newcomers to the C-Mod control system, or for those wishing a refresher, Chapter 2 provides a conceptual overview.
Chapter 3 provides a description of the C-Mod Power Systems and Coils, including limits of operation. This chapter may be useful in planning runs, especially if the intended operation is an extension of previous practice. Chapter 4 gives a (very brief) description of the gas system, which is the other primary C-Mod subsystem under the Physics Operator's control.
Chapter 5provides a functional overview of the Digital Plasma Control System, which includes the hardware and software used by the Physics Operator to provide realtime control of the C-Mod plasma. The chapter includes a brief discussion of the inputs and outputs to the Hybrid, as well as a description of the associated MDSplus tree \CMOD::HYBRID.
Chapter 6 describes the PCS (Plasma Control System) user interface software, the main operator interface employed by the Physics Operator. This chapter provides detailed descriptions, as in an instruction manual, of the use of the PCS software to perform all the normal functions of Physics Operations. It tells "how to" do things, but not "what to do". Some free advice pertaining to the latter question is contained in Chapters 7 and 8, which deal with Startup and Shape Control.
Chapter 9 is a condensed summary, with specific instructions, of the procedures to be followed by the Physics Operator in setting up a run, carrying out the run, and reporting the results. This chapter can be used as a combination checklist and ready reference for the Operator.
Chapter 10 deals with troubleshooting, and covers the most commonly encountered problems and solutions relating to the operation of the PCS software, the DPCS Computer, and associated signals and instrumentation. Also included in Chapter 10 are maintenance and testing procedures, including procedures for updating the HYBRID tree for configuration changes, and a brief description of test procedures which can be run off-line.
The Physics Operator is mainly concerned with what we may term Real-time control of the plasma, which is handled by the "Plasma Control System". However, this system interacts with, and is constrained by, the pre-programmed Engineering Control System, which is under the control of the Chief Engineering Operator and his assistants. Therefore, we will begin by briefly describing the functionality of the relevant portions of the Engineering Controls.
There are two main aspects of the Engineering Control System, a slow (response times of seconds to minutes) PLC-based system and a CAMAC-based system which controls pre-programmed and event-driven sequencing with time resolution down to 1 microsec, over a shot cycle which typically lasts seconds. The CAMAC system is driven by the MDSplus data system [1] running on the C-Mod Linux cluster; the PLC system uses commercial software (RSView) running on MS Windows PCs to implement a ladder logic, and transmits history and trend files which are then incorporated into the MDSplus data records (trees).
The PLC-based system implements a state machine and is in direct control of power supplies and gas systems, as well as the cryogenic system, vacuum vessel heaters, access, discharge cleaning and boronization, and other major subsystems. During non-run periods, the PLC/State machine system maintains the tokamak in prescribed states, e.g. STANDBY, controls conditioning operations, etc. Power supply and other subsystem testing can be carried out under PLC control alone, or with realtime control provided by the DPCS.
During tokamak operations, the PLC-based State Machine is used, under the direction of the Engineering Operator, to place all the tokamak subsystems in the appropriate states for the shots, energize the power systems, control the limits on voltage and/or current from each of the magnet power supplies, enable and actuate gas puff valves and diagnostic gate valves, monitor all subsystems and take appropriate action in case of several classes of faults, pass realtime control of certain power supplies and gas valves to the hybrid computer, and initiate the pulse, resume cooling and normal between-shot actions after the pulse, and initiate the data acquisition cycle. Coordination between the state machine and the MDSplus DISPATCHER program is via the IGOR module, which relays STATE transitions via CAMAC to the VAX program.
The sequence of state transitions and associated actions relevant to the control problem are summarized roughly as follows:
INIT: The state machine is manually placed in INIT to initiate the shot sequence. Appropriate actions are taken by the CRYO, HEAT, TORVAC, and various other PLC controllers in preparation for the pulse. Simultaneously, the DISPATCHER generates MDSplus pulse files for the shot and initializes all CAMAC and cPCI modules and initializes the DPCS software. All changes to the shot programming must be concluded prior to the transition to INIT. The INIT state typically lasts about two minutes.
CHECK: The state machine is manually placed in CHECK once permissives corresponding to completion of INIT activities and verification of readiness of all conditions monitored by the various PLC's are satisfied. Lack of completion or failure of specified critical initializations by MDSplus will prevent the transition to CHECK. During the CHECK state, which typically lasts 40 seconds, the alternator excitation is ramped up to nominal voltage. Also during CHECK, execution of the DPCS realtime routine is performed. The routine waits for a trigger from the CAMAC timing system, with a timeout interval of about 100 seconds.
PULSE: The state machine is manually placed in PULSE subject to permissives set during the CHECK state. The power supplies and gas system are enabled, and the DISPATCHER initiates the fast sequence, including power supply on signals and the trigger to the DPCS to send waveforms to drive the power supplies, gas valves, etc., as well as running the CAMAC timing highway and data acquisition system. The various power systems are enabled for a pre-set time during PULSE, after which they are forced back to zero output. PULSE state terminates after a pre-set time, typically 12 seconds, by transitioning back to RECOOL.
RECOOL: The RECOOL state is entered automatically following completion of PULSE. During this state, CRYO, HEAT, TORVAC, etc. return the tokamak to a state of readiness for the next pulse. The MDSplus DISPATCHER performs data acquisition and begins analysis tasks.
The fast Engineering Control system operates through CAMAC triggers and gates, which are set using the MDSPlus Engineering tree. The main interface used by the Engineering Operator to control these settings is the Engineering Power Supply Setup screen. This screen provides controls for setting supplies on, defining Start and Invert times, setting commutation switch close, open, and reclose (crowbar) times, setting the "fizzle detector" interval, and setting up timing for the engineering data acquisition CAMAC and cPCI. In addition, some of the editable fields are entered based on settings of the PLC controls, or hardwired settings like the commutation resistances.
The Physics Operator may request that the Engineering Operator set each of the supply parameters individually, or by loading from an earlier shot, and then perhaps editing a few fields. In any case, the EO will provide a printout of the final settings, which should be verified by the Physop.
The primary Alcator C-Mod plasma control system is based on a linearized model, which was originally realized in a Hybrid Analog-Digital Control System [3] which summed a set of analog real-time (analog) signals multiplied by time-dependent programmable (digital) coefficients. This basic linear matrix multiplication is now implemented in realtime software under DPCS. Up to 128 sensor signals are sampled by two D-TACQ ACQ196 digitizers, and up to 32 analog actuator drives are provided by the AO modules on the Rear Transfer Modules of these digitizers. The system therefore emulates a general linear system of dimension up to 128 by 32. Target waveforms for 16 reference parameters as specified by the Physop are generated in software, along with pre-programmed default feedforward waveforms for each of the 32 actuator signals.
The actual implementation employed at C-Mod includes three intermediate stages which may be thought of as three matrix multiplications. This division of the problem may be conveniently be thought of as decomposing the problem into an observer step, which transforms inputs (mainly magnetics signals) into recognizable plasma parameters, a PID gain stage applied to the error signals (relative to prescribed waveforms for the plasma parameters), and a controller stage, which applies the error signals, scaled by the PID gains, to a suitable combination of demand signals to (in general) multiple power supplies or other control devices in a feedback loop. This decomposition may be considered as a physically meaningful diagonalization of the control problem.
Note that while the above-described picture may be convenient, there is nothing about the hardware or software that restricts its use to easily interpretable parameters, or indeed to orthogonal controllers, so the diagonalization analogy is not necessarily apt for all feasible control schemes, including some in current use.
The main components of the plasma control hardware are illustrated in Fig. 2.2, and are summarized below. (This figure is obsolete, and will be replaced when I get a chance).
The DPCS computer, and associated electronics, are housed in the Electronic Interface Room adjacent to the C-Mod Cell. This room has its own ground, located in the C-Mod Cell. It is isolated from machine ground. All inputs and outputs to the hybrid must pass through isolation amplifiers or optical isolators (AFOLs). Network communication is over 1Gb fiber-optic ethernet. As of 2009, the dpcs host computer is a dual quad-core INTEL Xeon X5460, running the Red Hat Enterprise Linux 5.2 OS. The hostname is pcdaqdpcs3.psfc.mit.edu. A live backup system, pcdaqdpcs4, is located in the same rack.
The principal sensor inputs to the DPCS consist of integrated magnetics signals (flux loops, Bp coils, toroidal field measurement, and Rogowski loops) originating at the magnetics racks in the C-Mod Cell. Additional sensors (not shown on the Fig.) include bus rogowski signals from each magnet circuit, an interferometer output, visible bremstrahlung signal, bolometer signals, hard x-ray signal, ECE signals (from FRCECE) and, at one time, an RF loading circuit. Diagnostic signals which serve as inputs to the Hybrid are shown in the MDSplus tree nodes under \HYBRID::TOP.DPCS_CONFIG.INPUTS. For each input, a calibration corresponding to physical units/Volt of input (P_to_V_EXPR) is stored in the tree; most of these are calculated by subroutines which access nodes in sibling sub-trees, so that changes in the diagnostic setup are automatically incorporated. While most of the inputs to the Hybrid are already digitized at their source, all 128 input channels digitized in the Interface room are also stored in \HYBRID::TOP.HARDWARE.DPCS:DPCS2.SIGNALS:INPUT_*.
The first stage of the Hybrid linear system is referred to as the "A-matrix". The function of the A-matrix is to transform the diagnostic signals into physically meaningful quantities which are to be controlled. Examples of controlled parameters include the plasma current, current in a PF coil, plasma density, and shape parameters such as the inner gap or vertical position. Any quantity which can be estimated as a linear combination of the available inputs can be used as a control quantity. The coefficients of the A-matrix are loaded digitally and may be time-dependent. Some rows of the A-matrix are trivial, for example the "matrix" for a coil current consists of a single entry corresponding to the relevant bus rogowski loop; others are quite complicated combinations of magnetics signals and are loaded by IDL routines using specific ALGORITHMs to generate a linear estimator for quantities such as the gaps or X-point height. The A-matrix takes up to 96 inputs and produces up to 16 outputs. Thus 16 independent quantities can be controlled at any one time. One can change the quantities being controlled by changing the coefficient matrix; thus, at different times in the same discharge, a given output of the A-matrix may represent a coil current or the plasma density. Each of the 16 control signals corresponding to outputs of the A-matrix is referred to as a "WIRE".
The restriction of the A-matrix to 96 inputs, rather than the 128 actually available, is a holdover to insure backward compatibility with legacy shots generated under the old Hybrid system, which was limited by hardware configuration to 96 inputs. The dimension of the A-matrix is set parametrically in the DPCS software, and this restriction can be trivially removed when needed. Similarly, the number of WIRES is retained at 16 only for historical reasons. Modification of the PCS User Interface software to allow arbitrary dimensioning of the A-matrix, and the other matrices to be described below, is pending.
In addition to the available diagnostic inputs, the A-matrix also takes 16 prescribed waveforms specified through the PCS user interface. These secondary inputs, called the "P" waveforms, correspond to the desired or programmed values for each of the 16 controlled quantities. In the previous (Hybrid Computer) implementation, these waveforms were generated by a hardware module called the WAVEGEN. In DPCS they are calculated in software. The actual output of the A-matrix is the difference between the (linear estimate of) the control quantities and their desired values, i.e. the error signals.
Some refinements to the control problem, particularly the part associated with interpretation of the plasma shape parameters, are necessary to make the linear approximation satisfactory. In the case of plasma shape control, the observed flux and Bp values can be linearly related to the product of a positional parameter, such as a gap, and the plasma current. Therefore, while it is convenient to program directly in terms of a gap or position, the internal calculation is performed in terms of Ip*X, where X represents the position or gap. This is accomplished by having the coefficients of the A-matrix correspond to estimators for Ip*X, and by having the target quantities, , the "P" waveforms, modulated by the actual instantaneous current signal. In the PCS User Interface, 4 of the “wires” have targets that are permanently set up for "constant" reference, 4 are permanently set to "Ip" reference", and the remaining channels can be switched (in groups of four) from "constant" to "Ip" as a function of time. This grouping into sets of four was originally imposed by restrictions in the hardware implementation, and is currently retained for backward compatibility. The DPCS software treats each wire individually, and a trivial modification to the PCS interface could remove the restriction.
The outputs of the A-matrix and of the "P" signals are calculated in real time and stored by the DPCS software. The corresponding signals are located in \HYBRID::TOP.HARDWARE.DPCS.SIGNALS:A_OUT and \HYBRID::TOP.HARDWARE.DPCS.SIGNALS:P_OUT. (The structure of the HYBRID MDSPlus tree and its sub-trees is described in Chapter 5).
The second stage of the control system is the PID gain stage. This stage has 16 inputs and 16 outputs, but is essentially a diagonal matrix operation, in the sense that the inputs are not mixed. In this stage, the signal on each wire is processed by applying a combination of proportional, differential, and integral gains. These gains are time-dependent and are specified by the operator using the PCS interface software described below. All 16 wires have available proportional and differential gain. There are two integrator gate circuits, A and C, which can be connected to the integral gain stages for the various wires by adding jumpers to a connector on the Hybrid hardware. At present, only six of the sixteen wires have integral gain implemented in hardware.
The output of the PID stage is calculated in real time and stored by the DPCS software, and the 16 signals are available as \HYBRID::TOP.HARDWARE.DPCS.SIGNALS:PID_OUT.
The third stage of the Hybrid Control System is referred to as the "M" matrix. It maps the 16 wires (controlled quantities) onto 16 of the available 32 output demand signals, which presently correspond to voltage demand signals for 10 PF power supplies, the current demand of the non-axisymmetric A-coil power supply, four pulsed gas valves, and a current demand signal to the TF power supply. At present the second set of 16 actuator demands are not available to the M matrix, but can be addressed using loadable procedures in the DPCS software. Information concerning all of the outputs is found under \HYBRID::TOP.DPCS_CONFIG.OUTPUTS... The coefficients of the M-matrix are referred to as "controllers", and (logically) have units of Volts per unit error of the physical quantity being controlled. The controllers are time-dependent, and may be entered manually through the PCS interface software, but are more typically calculated by special purpose algorithms which are invoked by PCS. Since the DPCS software implements a feedback loop for each controlled quantity, it is not essential that the controllers be mutually orthogonal; however, it is desirable that they interact as little as possible, and the algorithms currently in use are designed with a sort of orthogonality in mind [4].
The outputs of the M-matrix, corresponding to the feedback demand signals to each power supply (or gas valve, etc.), are summed with pre-programmed "feed-forward" waveforms, referred to as the "V" waveforms. These "V" waveforms are the demand signals applied to the power supplies in the absence of any feedback signal, i.e. when the error is zero or when all of the controller gain coefficients for a given output are zero. These default output waveforms are intended to reduce the demands on the feedback system, which is rather low gain, and to provide a mechanism for open-loop programming. Note that the V signals are typically voltage demands, either to the power supplies or the gas valves; the exceptions in the present configuration are the TF_CURRENT and ACOIL_CUR signals, which directly controls the toroidal field and A-coil currents. The output of the M matrix and V waveforms are calculated and stored by the DPCS software; these signals are available in the tree in \HYBRID::TOP.HARDWARE.DPCS.SIGNALS:M_OUT and \HYBRID::TOP.HARDWARE.DPCS.SIGNALS:M_OUT. In addition, the actual outputs from the Analog Output modules are separately digitized in the interface room by a DTACQ DT196 digitizer; these signals are also stored in the tree as \HYBRID::TOP.HARDWARE.DPCS.SIGNALS:M_OUT:OUTPUT_*.
T. W. Fredian, J. A. Stillerman, et al., http://www.pfc.mit.edu/mdsplus/mdsplus.html
Paragon Software ?
S. Horne, et al., "Performance of the C-Mod Shape Control System", Proc. 15th Symp. Fusion Engineering, Hyannis, Massachusetts, October, 1993, Vol. 1, p. 242, Institute of Electrical and Electronics Engineers (1994).
I. H. Hutchinson, et al., "Plasma Shape Control: A General Approach and its Application to Alcator C-Mod", Fusion Technology 30, p137 (1996).
The major part of the job of the plasma control system is concerned with plasma shape (equilibrium) and current control, which requires real-time control over the C-Mod magnet systems. In this chapter we provide a brief description of the relevant coil and power supply parameters.
The poloidal field system consists of a three-segment ohmic-heating (OH) solenoid and ten ring coils, which together provide inductive current drive, shaping capability and axisymmetric stability. These thirteen coils are driven by ten independent power supplies. The coil set is illustrated in figure 3.1. All of the PF coils, including the OH, have an influence on shaping; there are no de-coupled coils like the DIII-D E-coil, and there is no one-to-one correspondence between a given shape parameter, such as triangularity, and a given coil set. The C-Mod control problem is therefore inherently a multiple output system (non-diagonal) system.
The five inboard coils, OH1, OH2U, OH2L, EF1U, and EF1L, are all driven by Robicon brand twelve-pulse line-commutating thyristor (SCR) supplies, taking prime power from the MIT Alternator, at a nominal voltage of 13.8kV. The line frequency varies from near 60Hz (typically 58.5Hz) at the beginning of the pulse and to perhaps 10% less at the end of the TF flattop. These five PF coils are also provided with independent solid-state interrupter circuits which are used to provide a voltage blip at the beginning of the plasma pulse for discharge initiation. Typically a one-turn loop voltage of 8-10V is used for break-down, while the voltage during current rise and sustainment is less than 3 V.
The central solenoid consists of three separate coils, OH1, OH2U, and OH2L. The main coil, OH1, provides the majority of the flux swing and also contributes to the shaping. The coil has 129 total turns, distributed in two layers over the full 1.08m height of the solenoid with an additional two layers near the midplane. This "belly" design, used in conjunction with the OH2U and OH2L coils which contain 27 turns each, occupying the outer two layers of the solenoid stack above and below the midplane, permits flexible shaping of the inner (small major radius) plasma boundary, and also affects the elongation and x-point locations. Each of the OH coils has a nominal 50kA design current rating. The present administrative limit is +/- 30kA.
The OH1 power supply is a four-quadrant line commutating supply rated at 930V open circuit and 500V full load (in rectification). This supply has a lock-out dual design, which requires a dead-zone around zero current to prevent a shoot-through fault, resulting in a significant loss of control at cross-over. To provide additional voltage at startup, the OH1 circuit includes a solid-state (SCR) interrupter, which is used to switch a resistor in and out of the current path. In the present configuration this interrupter is rated at 2KV and 50kA; previously, the SCR's in this circuit were seriesed, so that the rating was 4kV at 25kA. The available commutation resistance can be varied by tap changing between 11.3 and 345 mOhm.
The OH2U and OH2L coils are powered independently. They provide part of the flux swing, have shaping function in conjunction with the OH1 and also provide some vertical control. They also influence the x-point location. Like the OH1, these coils are designed to operate with current up to 50kA and presently have an administrative limit of +/-30kA. They are driven by four-quadrant line-commutating power supplies rated +/-240V open circuit and +/-100V full load. These supplies are "circulating dual" design, so they have no crossover distortion problem. Each of the OH2 circuits includes a solid-state interrupter rated at 2kV, 50kA; the range of commutation resistance is 3.6 to 145mOhm. While the commutation circuits on OH2U and OH2L are independent, they are usually set identically to avoid rapidly changing radial fields at commutation.
The EF1U and EF1L coils, located at the upper and lower inside corner of the vacuum vessel, affect the elongation and x-point location, while also providing some flux swing. These ring coils have 84 turns each, and are nominally rated at 15kA. However, the administrative limit on the EF1 currents is presently +7.5kA and -5kA, where the positive sign corresponds to the initial (or co-current) direction; this limit has been determined based on stress calculations including other coil sets. The EF1 coils are driven by independent Robicon line-commutating four-quadrant supplies with a nominal rating of 420V open circuit and 200V full load. The EF1 circuits include independent solid-state interrupters rated at 2kV, with commutation resistance variable between 17 to 600 mOhms.
The EF2U and EF2L coils influence triangularity, x-point location, and divertor strike-point location. The difference current between these coils contributes to the slow vertical position control. These coils have 80 turns each, and are nominally rated for 7kA each; the present administrative limit is 5.5kA, and is set by stress limitations. These coils are typically in compression due to oppositely directed current in the adjacent EF3 coils. The EF2 coils are powered by independent two-quadrant (i.e. bipolar voltage, unipolar current), six-pulse line commutator supplies which use the 480VAC line for prime power. These power supplies consist of four "TMX" modules each, two in series and two in parallel. The series combination is rated at 680V open circuit, 560V full load. No interrupter circuit is provided for the EF2 coils, but each coil is in series with a ballast resistor, presently set at 45.6mOhm, and a series SCR switch.
The EF3 coils, EF3U and EF3L, are connected in series and driven by a single power supply. (Very early in the history of Alcator C-Mod the EF3 coils were connected in parallel.) Each EF3 coil has 75 turns, for a total of 150. The EF3 coils primarily provide vertical field for the equilibrium, although this coilset has some shaping effect. The nominal design rating of the EF3 coils is 22kA, and the present administrative limit is 15kA. The EF3 coils are driven by a single two-quadrant thyristor supply, formerly used as OH3 on the Alcator-C tokamak. This supply is rated at 3645V open-circuit and 2400V full load. Due to the high supply output voltage, no commutation circuit is required for this coil.
The EF4 coils, located outside the cylinder, provide nearly pure vertical field, and are used to provide a slow bias field during breakdown and to aid EF3 in providing equilibrium vertical field later in the pulse. Changing the ratio of EF4/EF3 current produces subtle changes in the triangularity and D-ness of the plasma shape. The current in these coils is therefore in the co-current direction at initiation, and reverses to the counter-current direction as the discharge evolves. The coils have 84 turns each, and are presently configured in parallel. Prior to August,1996, they were connected in series. These coils are presently powered by two Robicon six-pulse line-commutating supplies (formerly used as part of the Alcator-C Toroidal Field supply), connected as a four-quadrant lock-out supply. As on the OH1 supply there results a significant dead-zone around zero current, which can affect plasma response. These supplies are rated at +/-1000V. The coupling of the coils to the cylinder and structure limits the effective response time of the plasma to these coils.
The EFCU and EFCL coils are connected in anti-series, and are used to provide fast vertical control. They have 10 turns each, and are designed for 3kA. The EFC coils are driven by a General Atomics Chopper supply which has a nominal frequency of 3kHz, with a voltage of +/-1000V. The EFC coils are normally run at a bias current of 1500A, with a rail-to-rail range of 0 : 3000A.
Influence Coefficients (i.e. mutual inductances and green's functions) for each of the PF coils with respect to flux and field components at the nominal plasma center are summarized in the following table, where the units are MKS and are given per amp for each coil; self-inductance L is listed, although the mutuals to other coils and to the passive structure cannot be neglected in figuring responses. Notice that this is an old table, and the values for the EF4 coils are for the original series configuration.
psi bz dbz/dR br L(H) oh1 3.9743e-05 -1.1127e-05 4.0633e-05 8.9048e-08 5.8e-3 oh2u 6.8205e-06 -1.5975e-07 -6.0672e-06 -3.7043e-06 5.7e-4 oh2l 6.8205e-06 -1.5975e-07 -6.0672e-06 3.7043e-06 5.7e-4 ef1u 2.0365e-05 5.7074e-06 -3.2150e-05 -1.1549e-05 11.2e-3 ef1l 2.0365e-05 5.7074e-06 -3.2150e-05 1.1549e-05 11.2e-3 ef2u 4.1027e-05 2.3640e-05 -4.1909e-05 -1.8760e-05 24.6e-3 ef2l 4.1027e-05 2.3640e-05 -4.1909e-05 1.8760e-05 24.6e-3 ef3u 4.8942e-05 3.3391e-05 -2.2856e-05 -1.8625e-05 22.1e-3 ef3l 4.8942e-05 3.3391e-05 -2.2856e-05 1.8625e-05 22.1e-3 ef4 8.9192e-05 6.6536e-05 1.3042e-05 0.0000e+00 119e-3 (series) efc 0.0000e+00 0.0000e+00 0.0000e+00 -6.7062e-06 7.5e-4 (anti-series)
The toroidal field magnet current can also controlled by the Physics Operator using the Hybrid, although it is often run under the direct control of the engineers using PLC control. The determination of which way to control the TF is part of the engineering setup specified by the Physop prior to each run. In the case of PLC control, the physop will specify a current level to be set on the PLC by the engineer, as well as the initiate and invert times, and the PLC will run the coil current up to that specified level. In the case of Hybrid control, the initiate and invert times are specified, along with a current level which is slightly higher than the maximum value actually intended; this serves as a backup or safety limit. The actual current waveform for the TF, which in this case can contain different ramps and plateau values as a function of time, is then specified by using the corresponding "V" waveform, which in the case of the TF controls the current rather than the voltage output of the power supply.
The Alcator C-Mod toroidal field magnet consists of 120 turns constructed in a rectangular shape with sliding joints at each corner. The inner legs are bonded together into a monolithic central column, while the radial arms and vertical legs are bundled into twenty groups of six turns each. Because there is no return bus, the TF magnet effectively incorporates a net toroidal turn as the current transfers from one turn to the next. This effective toroidal turn is located near the inner corners, comprising symmetric "half-turns" at the top and bottom. The poloidal field produced by these effective half-turns is non-negligible, and must be considered when computing plasma shapes as well as breakdown nulls.
The TF magnet is rated for 250kA, which would correspond to about 9 Tesla on axis. The present administrative limit is 225kA, for a maximum of 0.7sec. Operation above 200kA (approximately 7 Tesla) requires prior review and involves special procedures. The TF magnet is powered by a twelve-pulse Robicon line-commutating supply which features an auto-tap changing transformer, which reduces the output voltage when the current exceeds a preset level (typically around 100kA). The high-tap voltage is about 1400V, and the low-tap voltage about 700V. Prime power for the TF is taken from the MIT alternator.
The non-axisymmetric coils, also called the A-coils and sometimes the C-coils or Correction Coils, were added to C-Mod in 2003. They consist of a set of eight windings located on the outside of the igloo, which provide non-axisymmetric fields, at the mTesla level, for the purpose of compensating intrinsic error fields from the other magnet systems. They are also used to intentionally impose external non-axisymmetric fields for specific experiments, including magnetic braking and low m/n island generation. Each of the eight modules consists of 27 turns of 4/0 welding cable in an aluminum coil case. They are located above and below the midplane at B, D, G, and J ports .
The A-coil configuration is set at a patch panel in the cell, on the mezzanine adjacent to the bus tunnel. Typically four of the coils are connected in series to produce the specified field pattern. Changes to the A-coil configuration are performed by the Engineering Operator, or technicians acting under his direction, and are recorded in the Engineering tree using the Engineering Control Interface. This configuration can be read from the tree by algorithms invoked by the PCS interface software.
The A-coils are driven by a pair of TMX power supplies which provide up to 3700A at 600V (unipolar). Unlike the EF2 system these supplies use current control, and the regulator has a significant offset threshold, such that the demand must be about 600A above the actual desired output. When the coils are controlled using feedback this issue may be ignored, but it must be considered when using open-loop control. Since the actuator is connected to the current regulator, effective feedback will normally use Integral gain along with Proportional gain.
At this time the only subsystem besides the coil and power systems under the direct control of the Physics Operator by means of PCS is the main gas puff system, used for fueling the plasma. As in the case of the power systems, the setup of the gas control is accomplished by a combination of PLC settings, under the control of the Engineering Operator, and the Hybrid/PCS system, under the control of the Physics Operator.
The C-Mod Gas system includes a total of five piezo-electric valves, each connected to a plenum which can be filled with mixtures of up to five gases under PLC control. The associations between Hybrid Outputs and valves (as defined on the PLC screen) are:
Hybrid Output Output Name Location ------------ ----------- -------- 19 Pulse_gas5 H_bottom (formerly J-bottom) 13 Pulse_gas4 BTOP 14 Pulse_gas3 B_main (formerly C-side, before that K-side) 15 Pulse_gas1 B_side_lower 16 Pulse_gas2 B_side_upper
These valves are not all equivalent; some have special uses and driver circuits, and some are restricted to use with particular gases. The normal configurations, as of this writing, are given below.
The BTOP valve (Pulse_gas4, on output 13) is normally used for the pre-puff, which provides the initial gas on which the plasma breaks down. The (amplified) waveform from the Hybrid is applied directly to the Piezo valve. A full amplitude (100V) pulse of width between 10 and 20 msec is normally applied at about t=-0.5 sec, using the V13 output of the wavegen. Typically, no feedback is applied to this valve, and it is normally not used after the initial pre-puff. A typical fill setting for the BTOP valve, specified to the Engineering Operator in the run plan, is 6psi of D2, with Hybrid control enabled. The BTOP valve is also used (under PLC control) to provide the gas fill for discharge cleaning.
The B_main (Pulse_gas3, output 14) valve is typically used as the main density feedback controller. Unlike most of the other piezo valves, the driver for Pulse_gas3 uses a duty-cycle modulating circuit designed by W. Burke. Full amplitude pulses are applied with a period of approximately 6msec, with the pulse width varied to provide an approximately linear response to the input signal (in a time-averaged sense). Note that because of the use of this driver circuit the time response of this gas valve is uncertain at the 5msec level. Also, it is inadvisable to use this valve for long term (i.e. hours as opposed to seconds) duty, as in discharge cleaning. Typical fill setting for the B_main valve is 40psi of D2, with Hybrid Control enabled.
The B_SIDE_LOWER (Pulse_gas1, output 15) valve is normally used to provide a short puff of Argon for use by the HIREX diagnostic. Typical fills are between 1 and 4psi of Argon.
The B_Side_Upper valve (Pulse_gas2, output 16) is normally reserved for He3, which serves as the minority species for some ICRF heating scenarios, particularly using 80MHz at B=8Tesla. The plenum fill and pump-out connections are typically disconnected from this valve once it has been filled, to prevent accidental loss of He3, which is expensive.
The J_bottom valve (Pulse_gas5, output 10) was added late in the FY1998 campaign to permit feedback of impurity gas puffing in support of dissipative divertor experiments. This valve was later removed, following a malfunciton, and output 10 was reassigned to the A-coil Current actuator. In 2009 a replacement piezo valve was installed on the H-bottom flange, and connected to output_19. Like the Pulse_gas3, this valve features a duty-cycle driver with a 6msec period. At this time, the H-bottom piezo valve cannot be configured for feedback within the standard PCS system; that is, it is not one of the actuators available to be selected as an element of a CONTROLLER on the EDIT_WIRE Controller screens because these are restricted to output_01 through output_16. However, it is possible to define a loadable procedure to use this valve in a controller for any desired set of wires.
In addition to the Piezo valves listed above, there is a separate gas system called NINJA which is not under the Physics Operator's control. This system consists of a large number of capillary lines which inject gas (either working gas or impurities) at various locations on the inner wall and in the divertor. These valves are normally controlled by the Edge/Divertor group. They can be used to supplement the piezo valves if requested.
The Digital Plasma Control System (DPCS) provides real-time control of Alcator C-Mod subsystems, principally magnet power supplies and pulsed gas fueling, during a plasma pulse. Both open-loop and feedback control of multiple parameters (up to sixteen at a time) are available. The DPCS was originally developed as an all-digital emulation of the old Hybrid (digital/analog) Computer Control System, described in the Appendix. That control scheme is inherently linear, in the sense that the controllable parameters are linear combinations of real-time input signals and the output demands are composed of linear combinations of (PID) amplified error signals and pre-programmed waveforms. The DPCS retains this linear model as the core of the process, but adds additional capabilities and extensions, as described below. The realtime control process was originally constructed as a single synchronous loop, although provision has been added for additional asynchronous slave processes which communicate with the master process. The current implementation of the DPCS incorporates the linear system as well as additional “loadable procedures”, which can include arbitrary computational steps. The DPCS system also provides for adaptive asynchronous procedures, which never developed beyond the vaporware stage under the Hybrid Control system.
At the highest level, the DPCS consists of hardware (mostly commercial) and software (IDL and MDSplus applications) which convert analog sensor signals to analog actuator demands. The sensors confer information about the state of the system (plasma) and the actuators modify (control) that state.
A note about terminology is in order here. In common control engineering parlance, the sensor signals are outputs of the system and the actuator demands are inputs. However, for historical reasons (aka ignorance), this documentation is written from the point of view of the control system itself rather than that of the tokamak, and therefore we will refer to the sensor signals as the inputs and the actuator demands as the outputs throughout this document. While on the topic of aberrant terminology, it is noted that we may sometimes refer to the product of the first stage of the computation, which converts sensor signals into an estimate of the value of a parameter of interest, as an observer, an estimator, or a predictor; these terms are not actually synonymous, but we will use them here interchangeably. Similarly, we misuse the term controller to mean the weighted combination of actuator demands used to correct an error in a given parameter, but not including the (PID) gains which relate the magnitude (and phase) of the demand to those of the error.
The entire DPCS hardware set is contained in a single 42U high rack enclosure in the Electronic Interface Room (NW21-156d). Input signals are provided either on copper twisted pair cables originating from isolation amplifiers or over fiber optics driven by Analog Fiber Optic Link (AFOL) transmitters at various locations; these fiber signals are converted by AFOL receivers located in two Eurocard crates in the DPCS rack. Up to 128 diagnostic sensors are digitized by two DTACQ model DT196 16-bit cPCI digitizers operating in low-latency mode at a standard clock rate of 10kHz. The cPCI crate is connected to the host computer pcdaqdpcs3 PCI bus over a PCI/cPCI Bus extender (SBS). Demand signal to up to 32 actuators are provided through the analog output channels of these same modules, which in turn drive a set of AFOL transmitters which connect the demands over fiber optics to the relevant actuators in the power room and tokamak cell. The actuator demands are also separately digitized by another DT196 module, using standard transient capture mode. The host computer runs a standard Linux operating system (RHEL 5.2). During real-time control operation the operating system interrupts are disabled and code is locked in memory (no page faulting) by kernel-level software in the low-latency driver library. The control system software is written in IDL, a high level interpreted language with efficient vector/matrix operations, well-interfaced to MDSplus.
DPCS is a data-driven process which is fully integrated into the C-Mod MDSplus data acquisition and control cycle. The Physics Operator specifies the control targets and procedures using the PCS User Interface, which is described in Chapter 6 . This shot programming information is stored in the HYBRID MDSplus tree for use by DPCS. The heart of the DPCS software, written in IDL, comprises three main procedures, each active during a different phase (state) of the C-Mod shot cycle.
DPCS_INIT Invoked by the DISPATCHER during the INIT state, this routine reads the necessary shot programming and setup information from the HYBRID MDSplus tree and initializes the variables and procedures used by the realtime procedure.
DPCS_REAL_TIME Invoked by the DISPATCHER during the CHECK state, this routine first takes a single pass through the control loop to fault all the code into memory, then issues calls to lock memory and turn off interrupts and awaits a hardware trigger from the C-Mod timing system, issued on entry into PULSE state, or a preset timeout. On receipt of a trigger, the realtime control loop is initiated and continues for the number of steps specified by DPCS_INIT or until an exception is encountered. On exit from the loop, interrupts are reenabled and the routine exits.
DPCS_STORE Invoked by the DISPATCHER during RECOOL state, this routine writes the records of the control system operation to the HYBRID MDSplus tree, frees memory used by the realtime procedure, and exits.
Normally, the Physics Operator will not need to be concerned with the details of the DPCS software. The description in the following sections is provided for the benefit of those who don’t like dealing with “black boxes”, or who may wish to troubleshoot or contribute to further development of the system. The discussion proceeds from inside-out, beginning with the computations in the realtime loop, and emphasizes functionality over implementation.
Each iteration of the main control loop is, somewhat artificially, constructed as a series of discrete steps, each consisting of a default operation and a set of optional computations carried out by “loadable procedures”. Nominally these steps are carried out sequentially and the loop iterations are synchronized to the digitizer clock.
Input/output operations At the start of each iteration, the input data and current timing are acquired by a call to the dpcs_input procedure. Simultaneously, the actuator demands (outputs) calculated during the previous iteration are passed to the analog output modules of the digitizers by the same procedure. Further processing of the input data is then optionally performed by calls to the class of loadable procedures designated input_pros as specified by the PO using PCS. At present, the procedure baseline_sub is normally turned on. This routine determines any baseline offset that may be present by examining the data values during a preset interval, specified in the tree, and thereafter subtracting that offset from the acquired data.
Asynchronous procedures Operations which may cause a deviation from the nominal synchronous sequence of target waveforms and control processes, based on the newly acquired input data, are optionally invoked. These async_pros will have been specified by the PO using PCS. One example that is normally turned on for every plasma shot is the dpcs_fizzle routine, which is described in detail elsewhere in this document. Briefly, the function of this procedure is to detect the absence of plasma current and force the magnet systems to shut down in a specified manner, rather than continuing to try to control a plasma that no longer exists. This operation is controlled by branching to an alternative sequence of targets and controls that is asynchronous in the sense that it can be initiated at any time during the discharge. Other possible applications of asynchronous procedures would include intentional plasma terminations (soft landings) in response to off-normal or unexpected conditions. Potential interactions among different asynchronous procedures, and between async pros and other procedures which expect to be invoked in synchronous time, can be problematic, and no general solution has been established at this time.
Target (P) waveform The target or reference value for each controlled parameter (wire) for the given timestep is selected. As noted above, in the case of some parameters the value specified by the operator is scaled by the instantaneous value of the plasma current.
Observer operations The default observer step consists of multiplying the vector of scaled and conditioned inputs by the “A-matrix” of linear observers. This operation is optionally followed by invocation of any observer_pros specified through PCS. These may include both additional non-linear observers for various parameters, or conditioning operations such as filtering to be applied to the output of the linear observers.
Error evaluation The observer is combined with the reference (target) value to produce the current error vector. The derivative and integral of the error are also computed. No loadable procedures are provided at this stage
PID step The Proportional, Integral and Derivative gains, as specified in PCS, are applied to the error signals, resulting in a scaled and conditioned error vector. Optionally any pid_pros specifed in PCS are then invoked.
Feedforward (V) waveform evaluation The vector of feedforward waveforms (or open-loop demand) for the present timestep is evaluated. No optional loadable procedures are provided at this stage. Note that this evaluation does not depend on any of the preceding calculations, beyond the establishment of the current timestep, and so could have been (and in an earlier version was) accomplished as part of step 3.
Controller operations The default linear controller (“M-matrix”) is multiplied by the output of the PID step to produce the feedback part of the actuator demand vector. Optionally, any controller_pros specified through PCS are invoked to augment the feedback demands.
Output operations The feedforward (V) demands are added to the output of the controller step. Optionally, two sets of loadable procedures specified in PCS may be invoked at this point, the test_pros and the output_pros, in that order. The distinction between these is unclear, but one convention presently in force is that the output_pros should not be disabled by the action of an asynchronous procedure like dpcs_fizzle, while the test_pros can be (and are). The idea is that the output_pros are intended to directly affect the actuator demands, while test_pros may carry out a range of computations that impact the next iteration step, as well as possibly modifying the demand vector. Finally, the output vector is clipped to limiting values before being passed to the hardware.
Record keeping Intermediate values computed during the iteration are stored in arrays to be output to the tree during the STORE phase.
The above loop is repeated up to a preset step count determined during by the INIT procedure, or until an abort condition is encountered as determined by one of the loop procedures.
This section covers the functionality of DPCS Loadable Procedures which are used routinely, essentially in every shot. At present, there are two of these, input_pros/baseline_sub and async_pros/dpcs_fizzle. Both of these procedures are shown on the PCS Main Screen and can in principle be turned off or have their parameters modified. The status and parameters of these routines are stored in the DPCS tree, and may be different depending on the origin of the pulse file to be loaded. In particular, doing a load_from operation on shots from before the use of the baseline_sub routine became standard, in 2006, is problematic.
It should be noted that provision does exist to install loadable procedures directly into the parent HYBRID tree which are not subject to editing or elimination using the PCS Interface software. This is possible because the runtime DPCS software actually obtains the loadable procedure data from \HYBRID::TOP.HARDWARE.DPCS.LOADABLES.PROCEDURES:* while the PCS Interface deals with nodes in the DPCS subtree \HYBRID::TOP.HARDWARE.DPCS.LOADABLES.PROCEDURES:* . For each class of procedure, ASYNC_PROS, INPUT_PROS, etc., the Hybrid tree nodes presently include four members with names like PROCEDURE_0 through PROCEDURE_3, of which 1-3 contain node references to the corresponding DPCS tree nodes, while the PROCEDURE_0 nodes can contain data loaded manually which will always be used directly, without reference to the “volatile” DPCS subtree. In the past, this feature was employed to insure that the dpcs_type2_fault procedure, which was used to provide some level of protection from off-normal events that could have resulted in coil overstress situations before a hardware protection circuit was implemented, would always be present and active. At the present time there are no such installed procedures in use.
Since it is the Physics Operator’s responsibility to insure that the standard procedures are used, when appropriate, and may need to decide to modify or eliminate their use if this becomes advisable, a description of their functionality is provided here.
The real-time baseline_sub routine calculates initial baseline offsets based on a sampling interval during which each signal is supposed to be zero, and subsequently subtracts them from the input values. As a side-effect, the routine tests the observed offsets on certain “critical inputs” against an allowable range, and takes preemptive action if this range is violated, by forcing the DPCS actuator demands to zero; if this feature is activated the associated STORE action causes an Abort message to be logged to the DPCS logfile.
Most of the parameters used by baseline_sub are derived from data in the Hybrid tree contained in \HYBRID::TOP.DPCS_CONFIG.INPUTS:INPUT_*:OFFSET and subnodes. The only parameters settable from the PCS EDIT_PROCEDURE window are
The time during the shot at which the routine begins to function, set in the field SWITCH_TIMES; the current value is Build_With_Units([-3.4],"sec")
The names of the DPCS outputs to be forced to zero if an initial input offset value is out of bounds, set in the field OUTPUTS; the default values are all the power supply demands: ["OH1_VOLT","CHOPPER","OH2_U_VOLT","OH2_L_VOLT","EF1_U_VOLT","EF1_L_VOLT","EF2_U_VOLT","EF2_L_VOLT","EF4_VOLT","ACOIL_CUR","EF3_VOLT","TF_CURRENT"]
For each input listed in \HYBRID::TOP.DPCS_CONFIG.INPUTS:INPUT_nnn the following members control the behavior of baseline_sub
:OFFSET – Type Numeric. If present, a fixed offset (Volts) which is subtracted from the signal. This level is used at times before application of the calculated offset, or throughout the shot if no “live” offset calculation is performed.
:OFFSET:BASE_INTRVL – Type Axis. A range of times (sec) between which the actual signal is expected to be zero. For magnetics sensors and bus rogowski signals, this interval is typically the first 100msec after the start of the integrator gate. For the TCI signal, it is the period before t=0 when the fringe counter is reset to zero. If present, the average value in this interval is evaluated and subsequently subtracted from the input signal for the remainder of the shot. If no range is present, then the contents of OFFSET are used.
:OFFSET:BASE_LIMIT – Type Numeric. If present, a limiting value (Volts) such that if the absolute value of the offset calculated during the BASE_INTERVAL exceeds this level then an error condition is flagged and the selected actuator demands are forced to zero. The purpose of this feature is to guard against an observed fault condition that resulted in several sensor inputs running to spurious DC levels, which were then interpreted as baseline offsets and effectively zeroed, leading to seriously inappropriate feedback behavior. If no value is entered for BASE_LIMIT for a given input, then no action is taken with respect to that input.
The action of the baseline_sub routine can be observed by comparing the traces on the scope_dpcs_inputs_1.dat or scope_dpcs_inputs_65.dat, which show the signals with baselines subtracted, with the raw digitizer inputs on scope_dpcs2_inputs_1-64.dat and scope_dpcs2_inputs_65-128.dat . On a typical processed trace, the use of three “baseline” levels should be visible at the beginning of the shot: the raw level before the first SWITCH_TIMES value; the fixed level from \HYBRID::TOP.DPCS_CONFIG.INPUTS:INPUT_nnn:OFFSET until the end of the :OFFSET:BASELINE_INTRVL; and the live computed value, which should result in a near-zero baseline following the averaging period.
There are in fact two systems
referred to as "the fizzle detector". These are
inter-related but distinct both in functionality and control. I will
refer to the first as the "Hardware Fizzle Detector"; it is
essentially under the control of the Engineering Operator, who will
normally set its parameters, at the request of the Physics Operator,
using the Engineering Control Panel and the power system PLC screens.
The second, which I will call the "Software Fizzle Detector",
is implemented as part of the Digital Plasma Control System (DPCS)
and is under the control of the Physics Operator. The software fizzle
detector is implemented by the DPCS loadable procedure dpcs_fizzle.
The principal function of the "Hardware Fizzle Detector"
is to provide a signal, via fiber optics and DFOLs, which changes
level when the plasma current falls below a pre-set threshold during
a specified gate (window in time). The threshold is set by adjusting
a pot on an analog circuit and the window or gate interval is set by
the Engineering Operator using the Engineering Control Panel. The
normal settings for this interval during plasma operations are:
On=0.080 sec, Off=1.80 sec. The output of the Hardware Fizzle
Detector is used as a permissive by numerous C-Mod subsystems,
including the magnet power supplies, the RF systems, the DNB, and the
pulsed gas system. In general the effect is to turn off the
subsystem in a safe manner when the plasma is lost during the gate
interval. For most of the magnet power supplies the effect of the
fizzle detector is to send, through the PLC, a command to perform a
forced invert to remove current from the magnet once the plasma is
lost.
In the case of the TF and OH supplies there is an extra
feature implemented through the PLC which provides a delay between
the triggering of the hardware fizzle detector and the application of
the Invert command. The length of this delay is entered on the PLC
screen by the Engineering Operator. The purpose of this delay is to
allow the Software Fizzle Detector to take control of these supplies
for a period of time after the loss of plasma.
Before
describing what action the Software Fizzle Detector is designed to
take during this interval, I need to explain briefly the motivation
for this arrangement. Several years ago it was noted that following
"fizzles", i.e. unsuccessful plasma startups, the measured
resistance of the connection between the OH coils and the coaxial
buss which feeds them was observed to be higher on the subsequent
startup, and indeed to ratchet up to levels of concern after a number
of such fizzles. The cause of this behavior is believed to be
associated with the motion of the contact assembly under the JXB
forces during the course of a shot. The contact assembly involves
conducting feltmetal pads and a spring-loaded "foot" which
can flex slightly in response to the large forces. The normal contact
resistance is of the order of 1 microOhm, but values of several
microOhms have been observed following sequences of successive
fizzles or short plasma shots. Full length shots do not typically
exhibit this behavior. The explanation is believed to be that on a
full length shot the current in the OH coils double-swings, i.e. goes
from a large negative value to a large positive value and then back
to zero. Since the sign of the toroidal field does not change, this
means that the forces on the coax foot reverse during a full length
shot, causing a rocking first in one direction and then back to the
other. On the contrary, after a fizzle or a short plasma on which the
hardware fizzle detector acts with no delay, the
current in the
OH coils will typically be only in the original, pre-charge
direction, and then be commanded back to zero by the effect of the
fizzle detector. As a result, a rocking force in only one direction
is felt, and the contact can be left in a rocked or tilted condition,
and subsequent fizzles can continue to act to displace the contact in
the same direction.
Furthermore, it was found that simply
turning off or adding a delay to the Hardware Fizzle Detector tended
to alleviate this problem for the OH1 and one of the OH2 coils, but
made it worse for the other OH2. This occurs because in the absence
of a forced invert command to the power supply, the normal response
of the plasma control system would be to command a large voltage on
the OH1 supply, in the direction to force it double-swing, in a
futile effort to increase the plasma current to its target value.
However, the commands to the OH2 supplies tended to drive these in
opposite directions in an effort to make the vertical position of the
plasma zero when there was no actual plasma there to respond. In
addition to exacerbating the forces on one of the OH2 coaxes, this
reponse also leads to large forces on the OH stack which arise when
the OH2 coils are driven to opposite sign currents at their PLC
limits. This behavior was determined to be unacceptable.
The
solution that was adopted is implemented in what I refer to as the
"Software Fizzle Detector", specifically in a procedure
loaded into the DPCS control computer called dpcs_fizzle.
The function of dpcs_fizzle
is to independently sense the
loss of plasma current during the same gate interval set by the
Engineering Operator for the Hardware Fizzle Detector, and change the
target waveforms for the TF and OH1, OH2U, and OH2L supplies from
what they would normally be doing for plasma control to a
pre-programmed set of
waveforms. Specifically, when the Software
Fizzle Detector is activated by detecting loss of plasma during the
gate interval, the response presently programmed is for the TF
current to be at -150kA until 0.4 sec after the fizzle, and the OH1
and OH2 currents to go to +15kA and +20kA respectively, and hold at
that level until 0.4 seconds after the fizzle, and then to ramp down
according to a prescribed waveform. The intent is to provide a
reversed restoring force to the coax at the end of the shot, which
requires continued toroidal field and OH currents of the appropriate
sign. These specific waveforms and levels were established
semi-empirically, and can be changed by the Physics Operator, after
suitable consultation. Because the function of the Software Fizzle
Detector involves machine protection these waveforms should not
normally be altered, or the dpcs_fizzle routine disabled, without due
consideration. A description of the process to be followed if the PO
in fact
determines that such an alteration is desirable is
provided below.
It is important to note that the function of
the Software Fizzle Detector is also dependent on the Fizzle Delay
settings and PLC current limits set by the Engineering Operator. The
DPCS control of the power supplies lasts only as long as the relevant
delay settings, or until the normal supply Invert setting, whichever
comes first, after which a forced invert is applied and the current
forced to zero in any case. Also, if the PLC current limit is set
lower than the programmed waveform, for instance if the TF current
limit is set for 100kA while the waveform target level is 150kA, then
the PLC limit overrides the programming. Again, such a modification
will override an intended machine protection function and should be
implemented only after due consideration and consultation.
A
common source of confusion occurs when a plasma terminates after the
TF begins to ramp-down, usually at 1.6 seconds, but before the end of
the fizzle gate, typically at 1.8 seconds. The resulting TF current
behavior looks peculiar, but is consistent with the programming. The
TF ramps back up toward 150kA because that is the target value.
Whether simply maintaining the reduced current that it had already
reached would provide sufficient restoring force is not known, and
would also depend on the actual currents in the OH coils. Always
commanding the TF to at least try to go to the 150kA target was
easier to program, and expected to provide reliable protection.
Similarly, when the TF is programmed for a flattop at a field lower
than 5.3 T (corresponding to 150kA), as was the case last Friday, the
resulting response to fizzles or disruptions of rising toward 150kA
looks peculiar, and understandably produced some consternation on the
part of some who were not fully aware of either the origin of the
behavior (the Software Fizzle Detector) or the reason for it
(described above), or both.
Under some circumstances, notably
experiments involving Lower Hybrid current drive, the voltage
requirements from the plasma are so low that even a full length shot
does not result in double-swinging the OH currents. In these
circumstances we frequently find it useful to extend the end of the
fizzle gate interval so that the off time is after the normal end of
the discharge, e.g. to something greater than 2sec; in this case it
is also necessary to extend the power supply invert time settings.
When this is done, the Software Fizzle Detector will operate on every
shot to force a double swing on the OH's. This has been found to be
beneficial in keeping the coax resistances from ratcheting up during
these runs.
In the event that the Physics Operator wishes to
modify the dpcs_fizzle
target waveforms, or if
he just wants to examine them in detail, the following instructions
should suffice. The parameters controlling the dpcs_fizzle
procedure can be accessed by
clicking on the button labeled dpcs_fizzle
in the box near the lower left
corner of the DPCS Plasma Control System Interface. The
Edit_Procedure Pop-up Window that
appears when the [dpcs_fizzle]
button is clicked contains two user inputs of note: the "Source
Shot" which for normal field operation is presently set to a
value of 1090731017, and the "Segments" field, which is set
to [4]. These refer to the shot number and PCS segment in which the
dpcs_fizzle
sequence is programmed.
The
fact that this programming actually resides in an old shot, rather
than being copied into the current pulse file for every shot, would
be inconvenient if frequent changes to these targets were required,
but this has not in fact been the case, and this way saves some space
and preserves all four available segments in the current pulse file
for possible plasma sequences. It also provides a measure of security
against inadvertent modification or elimination of the desired
functionality. In what follows I will explain how to use a segment in
the current tree for this purpose instead.
To examine and
possibly modify the fizzle programming, note down the shot number and
segment values and dismiss the Edit Procedure window. Then go to an
unused segment in the current working model (it doesn't have to be
Segment04, but if that one is available it probably makes sense to
use it), and click the [Import
Seg] button and fill in
the number and segment being used by dpcs_fizzle
(in the default case, 1060308026
and segment 4 (you don't need the [] brackets), then click OK. It
will likely bring up the usual warning display about mismatched PCS
configurations and magnetics predictors needing changing. Acknowledge
that after reading it. It may also bring up a warning about the DPCS
configurations. This one actually deals with the dpcs_fizzle
function, but as long as
you're operating with the same polarity fields as the source you're
importing from it should be recommending a NOOP; otherwise, it
gives
the shot number you should be looking at for the other sign of field.
Acknowledge this one too.
You should now see a segment with
the title "fizzle", and active wires for all the PF power
supplies. There are also unused wires for several magnetics and
plasma quantities, readily identifiable because the buttons are in
lower case. This segment has a Start Time=-0.1 sec, which refers to
the drawn waveforms and gains in this segment. The dpcs_fizzle
procedure will asynchronously begin to apply the commands in this
segment starting at the values drawn from -0.1 sec, from whatever
time the fizzle actually occurs. The Segment State boxes will be
whatever they were in your working tree, since these don't get
imported. The On/Off box had better be "Off" if you don't
intend to use this. Most likely the Sync box will be checked, but if
you do want to use it you will need to Uncheck this to set the
Segment to "Async", and you'll need to set the segment
"On". You'll also need to make some changes in the
dpcs_fizzle
Edit Procedure window, as
described below.
To look at the PF waveform programming, you
can bring up the All_p's screen or look at the individual wires one
at a time by pushing their buttons. Note that only programming after
the segment start time of -0.1 sec will be used, and this programming
will be inserted beginning at the start of the fizzle sequence, i.e.
the first instant within the gate interval at which the absolute
value of the plasma current falls below the threshold value. All of
the OH currents are set to be at +15kA or +20kA at that time, and to
stay there until +0.3 seconds and then ramp down to zero. Similarly,
on the All_V's screen you can see that the TF is programmed to be at
-150kA at -0.1 sec, then rampdown to a backporch of -50kA starting at
0.3sec and then go to zero. Again, note that these waveforms will be
followed by the supply only for as long as the end of the PLC setting
for the fizzle delay, or until the synchronous Engineering power
supply invert time. The feedback gains, predictors, and controller
gains are also visible and settable in the usual way from the Edit
Wire screens that appear when the individual wire buttons are pushed.
There are also (zero level) waveforms drawn for the times
after -0.1 sec for the other PF supplies: IC_EF1U, IC_EF1L, IC_EF2U,
IC_EF2L, IC_EF4U, and IC_EF3U. Since normally these supplies do not
have a fizzle delay programmed in their PLC's, these controls are
never in effect, but if we were to change this behavior, or if for
some reason the hardware fizzle detector failed to act on any of
these supplies, setting these targets to zero mimics the normal
hardware fizzle detector function. Note that the wires 1-7 have been
“zeroed” in this segment. We don’t want to try to feedback on
any plasma quantities, only on the coil currents.
If you do
decide to modify the fizzle sequence, make your changes in this
segment in the usual way, then:
1) Uncheck the Sync
button and verify that it
changes to "Async".
You'll get a warning that you've done this that you'll need to
Acknowledge.
2) Check the On/Off box so it reads "On"
3) Go back to the [dpcs_fizzle]
button under “Async_Pros"
to bring back the Edit Procedure window.
4) Change the shot
number in the "Source_Shot" field to $shot. Verify that the
check box to the right of this field says "MDS Expression"
rather than "IDL value"; click it if it doesn't.
5) If
you've used segment 04 then you can leave the Segments field alone.
Otherwise, change the [4] to whatever segment you've programmed the
new fizzle sequence in. The square brackets are probably not needed,
but they don't hurt, so leave them. The check box to the right of
this field should also say "MDS Expression".
6) Click
the "OK" button in the bottom row of buttons. To verify
that the changes have loaded, push the [dpcs_fizzle]
button again and check the
entries. Alternatively, you could use "APPLY" followed by
"RESET" to verify the changes before exiting the Edit
Procedure window.
7) Click on “Build Segment” in Segment
4.This is probably superfluous, but it can't hurt.
You can
now load the shot, and the next shot will use your new fizzle
settings. The "$shot" entered as the source_shot means that
each shot will expect to find an asynchronous fizzle sequence in
segment 04. This can be somewhat dangerous, because if an
unsuspecting or forgetful physics operator inherits or loads from
this model, and then imports another segment into segment 4, or turns
it off, bad things will happen! It is much safer to revert to the
previous arrangement by which the fizzle sequence lives invisibly in
a different shot, referred to by an explicit shot number in the
"Source_Shot" field. Therefore, once you are satisfied with
the new behavior, it is strongly advised that you do the following:
1) Again bring up the dpcs_fizzle
Edit Procedure window and fill
in the shot number of any shot (not -1) that has your modified
sequence loaded, and OK that.
2) Either Import a new segment over
the one containing your modified fizzle sequence or, even better,
Zero it.
3) Still in that segment, Change the title to "Zeroed"
or whatever you like other than "fizzle".
4) Turn the
segment OFF and set it back to "Sync"
5) Change the
start time to 0.1 sec (or something later), just to make sure it
doesn't get turned on and start being used during the precharge
sequence.
These steps should erase all traces of the modified
fizzle sequence from that segment of the working model tree, but
subsequent shots will continue to use that programming as long as the
new shot number appears in the dpcs_fizzle setup. When you or anyone
else does a "Load From" a shot using the default
dpcs_fizzle Source_Shot the behavior will revert to that program.
Importing segments from old shots however will not change the
dpcs_fizzle Source_Shot setting.
For those who really
want to see how the
dpcs_fizzle functionality is implemented, the source code can be
found in
/usr/local/cmod/codes/dpcs/user_algs/async_pros/dpcs_fizzle_init.pro
. Some (actually quite a lot) of
familiarity with the dpcs software is required.
The organization of software associated with the Digital Plasma Control System is rather convoluted, with programs located in several different directories invoking each other. The following discussion begins with the boot sequence of the host computer.
In /etc/inittab on the host
computer pcdaqdpcs3 is found the line:
m3:345:respawn:/usr/local/cmod/codes/dpcs/dpcs3
which causes the shell script
dpcs3
to be executed (with
no arguments) at boot time, and to be executed again if and when it
is stopped for any reason. This script defines some path variables,
using /usr/local/mdsplus/setiup.sh, sets up the low-latency
digitizers using calls to /usr/bin/acqcmd,
sets the and sets IDL_PATH to:
IDL_PATH="+/usr/local/cmod/codes/dpcs/user_algs:+/usr/local/cmod/idl:/usr/local/cmod/codes/dpcs:+/usr/local/mdsplus/local/idl:+/usr/local/mdsplus/idl:<IDL_DEFAULT>"
and invokes
/usr/local/cmod/idl/dpcs2/dpcs2.pro
The dpcs2.pro
IDL batch script compiles the
routines in /usr/local/cmod/idl/dpcs2/dpcs_startup.pro
and
/usr/local/cmod/idl/dpcs2/real_io.pro
and
then does a resolve_all
to
compile the remaining dependencies. These two files, plus
/usr/local/cmod/idl/dpcs/fifo_serve.pro
contain
the IDL procedures used by the generic dpcs2 device, including
dpcs_startup.pro :
dpcs_output which saves the realtime input and output values to arrays in memory, called by dpcs_real_time
dpcs_store which writes the input and output arrays to the tree and calls the user_store_procedure during the STORE cycle (RECOOL)
dpcs_init which initializes the parameters used by dpcs_real_time, dpcs_input, and dpcs_store
dpcs_real_time which executes a generic real-time loop consisting of calls to dpcs_input, the user_rt_procedure, and dpcs_output; on the first pass it calls dpcs_disable_ints to turn off interrupts.
dpcs_startup which sets up memory locking, initializes the hardware by calling dpcs_ll_init, and returns the filename of the fifo (named pipe) through which the mdsip server on pcdaqdpcs3 communicates with the IDL process.
real_io.pro :
dpcs_run which calls fifo_serve (located in /usr/local/cmod/idl/dpcs/fifo_serve.pro )
dpcs_input which acquires data from the digitizers and passes the calculated outputs back to the digitizer analog output modules.
dpcs_disable_ints
dpcs_enable_ints
dpcs_set_ecm
dpcs_done
dpcs_lock_memory
dpcs_ll_init
real_io which just prints a message to the logfile
Note that /usr/local/cmod/idl/dpcs2/ also contains a package simulated_io.pro, which provides dummy routines for most of these, and substitutes dpcs_run and dpcs_input routines which communicate with the Alcasim MATLAB/SIMULINK simulator routine for running software-in-the-loop plasma simulations.
The dpcs_input and other modules in real_io.pro (except dpcs_run) all work by doing call_external() into the DTAQC low-latency library /usr/local/cmod/lib/2.6/libllshr-poll.so.outputs_nostats.
fifo_serve.pro :
fifo_open_input
fifo_open_output
fifo_serve
Fifo_serve opens the named fifo’s and manages communication between the mdsip server and the IDL process. After doing a resolve_all to compile all of these dependencies, the dpcs2.pro script calls dpcs2_startup and then dpcs_run, which in turn invokes fifo_serve to establish the communication link.
The mdsip server on pcdaqdpcs3 uses the funs in /usr/local/cmod/tdi/dpcs2/dpcs2__*.fun , which correspond to actions dispatched during the cycle. These TDI funs use Idl->execute() to invoke /usr/local/cmod/idl/dpcs/fifo_send.pro to cause the dpcs IDL process to run the dpcs_init, dpcs_real_time and dpcs_store procedures.
The generic dpcs_init, dpcs_real_time and dpcs_store prodecures invoke the specific procedures identified in tthe tree nodes \HYBRID::TOP.HARDWARE.DPCS:DPCS2.PROCEDURES:USER_INIT, :USER_RT, and :USER_STORE, which, for the Digital Plasma Control System instance point to /usr/local/cmod/codes/dpcs/dpcs2_init_procedure.pro, /usr/local/cmod/codes/dpcs/dpcs2_rt_procedure.pro, and /usr/local/cmod/codes/dpcs/dpcs2_store_procedure.pro. These procedures in turn call into the DPCS-specific routines used for plasma control, located in /usr/local/cmod/codes/dpcs/ and its subdirectories. Note that the only generic procedure located in /usr/local/cmod/codes/dpcs/ is the dpcs3 shell script invoked through /etc/inittab; this is probably a mistake.
All of the software used for the Digital Plasma Control System are maintained in the C-Mod CVS Repository, which is hosted on alc-software.psfc.mit.edu:/software/cvs_repositories/cmod_system . Note that the active directories /usr/local/cmod/codes/pcs/ and /usr/local/cmod/codes/dpcs/ are actually CVS working directories, as are /usr/local/cmod/idl/ and /usr/local/cmod/tdi/ .
In general, the best way to modify software in these directories is to do the modifications and testing in personal CVS working directories, and then upload the tested modules to CVS. Downloading to the active public directories should normally be done between runs. Note that both the PCS user interface and the DPCS software test environment are set up to use their local working directories for the IDL path, so, for example, invoking
$ /home/wolfe/cvswork/pcs /safe
will look in /home/wolfe/cvswork/pcs/user_algs/ for algorithms, rather than in the active area under /usr/local/cmod/codes/pcs/
Once new software has been downloaded from CVS into the active /usr/local/cmod/codes/dpcs/ directory, it is necessary to restart the IDL process on pcdaqdpcs3 in order to have a consistent set of procedures compiled. This is done by logging onto pcdaqdpcs3 using ssh and invoking /usr/local/cmod/codes/dpcs/dpcs_restart at the bash prompt. This script forces the process to exit, and the respawn feature then starts it up again as a fresh sesion.
The following report dated 5/28/2009 contains most of the information, which needs to be edited and amended based on developments since this was written.
Report on Reconfiguration of DPCS and Associated Hardware ---------------------------------------------------------- Reconfiguration of the DPCS hardware in preparation for the 2009 C-Mod experimental campaign is essentially complete. The control system hardware has been relocated from the three equipment racks formerly used for the old "Hybrid Computer" system into a single new (42U high) black enclosure in the Interface Room. The AFOL receivers comprising input_065 through input_096 have been consolidated in a single Eurocard crate with a customized backplane providing electrical connection through a pair of 37-pin D-connectors. The AFOL transmitters providing the DPCS outputs (01-32) have also been consolidated in a second Eurocard crate, also with a custom backplane provided by the Electronics Shop. The original AFOL cards have been transferred to the new housing, preserving the same channel associations, so any inconsistency in calibration should be maintained. Note that output_01 to output_16 use old-style (Rev 1) AFOL transmitters, while the output_17 to 32 employ the newer Rev 2 design, which has a different ordering for the fiber connections. The DPCS digital electronics consists of two cPCI dt196 realtime digitizer cards with analog outputs, a cPCI DIO2 timing module, (both previously used in the "development system"), and a new 96 channel cPCI dt196 digitizer used for recording the output waveforms. These modules are housed in a cPCI crate connected to the PCI bus of the host computer. All the DTACQ realtime modules have been upgraded to the firmware appropriate for the Linux 2.6 kernel. The host has been upgraded from a single cpu system (pcdaqdpcs1 running Red Hat 9 (Linux 2.4 kernel) to a dual quad-processor (8 cpu) system (pcdaqdpcs3) running the Linux 2.6 kernel. This platform executes the control computations about 2.3 times as fast as the previous system, as well as providing capability for multiple time scale parallel computations using the additional processors, as demonstrated in Marco Ferrara's experiments last year. The installation also includes a complete development (shadow) system, comprising a second host computer (pcdaqdpcs4), 2 realtime dt196 digitizers with analog outputs, and DIO2 timing module in a second cPCI crate. The development system inputs are connected in parallel to the primary DPCS, and output waveforms are digitized separately using additional channels on the diagnostic digitizer (a separate dt196 digitizer for this purpose is on order). The development system can be run independently either in concert with the C-Mod shot cycle or "off-line", for testing new algorithms or techniques. It also serves as a backup system with complete redundancy if needed. The network interface to the host computers has been upgraded from 100Mb to a 1Gb link. Both hosts include separate ethernet RAC connections for remote cycling. Each also provides private network connection for communication with the digitizers. All electronics in the new enclosure are powered through an ethernet controlled AC source (ALCPWR16) and can be power cycled remotely via a web interface. The host computers are connected to an in-rack KVM monitor and keyboard for local interactive access. In addition to the DPCS functions, the reconfiguration also included the analog fizzle detector and the interface to the realtime control room display of power system currents (bus Rogowskis). These functions are now also housed in the same enclosure, in a mini-Eurocard crate (6 slots), formerly used for DPCS outputs 17-32. The original AFOL transmitter cards (Rev 1) for the control room display have been transferred to this minicrate, but because of a different interface it was not feasible to preserve the channel associations. The calibrations of some of these AFOL transmitters, particularly the DC offset, appears to be rather coarse, so there may be some change in the appearance of traces on the display. As part of the reconfiguration, the gate for the fizzle detector has been transferred from the CAMAC J221 (\HYBRID::TOP.HARDWARE.CAMAC:J221:OUTPUT_04) to Channel 5 of the DPCS DIO2 (\HYBRID::TOP.HARDWARE.DPCS:DIO2.CHANNEL_5). The programming of this gate pulse has been set up to mimic that of the J221, using values from the Engineering tree node \TOP.POWER_SYSTEM:FIZZ_DETECT . This gate pulse represented the last CAMAC-based signal employed in DPCS and associated systems, with the exception of the main C-Mod timing highway, which still originates with the ENGINEERING ENCODER in the control room. The Interface Room CAMAC crate has therefore been removed from the serial highway, and will be retired. The functionality of the re-housed AFOL receiver and transmitters has been verified along with the DPCS digital electronics and host computer functions (see logbook entries from 1090524 and 1090525). All input and output fiber bundles and cables have been re-routed into the new enclosure and reconnected. All of the original outputs and functionality of the DPCS and associated systems have been preserved, EXCEPT for the following: a) The fiber from DPCS OUTPUT_31 to the "Type 2 Fault" interface, employed for several months during the 2008 campaign and then discontinued once Bill Burke's hardwired interlock became operational, has not been reconnected. This DPCS function is now deprecated. b) The interlock from one of the BP coils to the DNB, using a circuit developed by Bill Burke and Dave Terry and connected to a patch panel on the old Hybrid Computer system, has been disconnected. Bob Granetz has informed me that this function is no longer required. The original circuit is still in the middle blue rack of the old installation, and the fiber is hanging loose nearby. If necessary, this circuit could be installed in the new enclosure and reconnected; a suitable breakout panel is available. The new installation should be fully functional now. Some additional work remains to complete the reconfiguration: 1) One (of two) DC power supplies providing ±15V, +5V for the AFOL transmitters and receivers has been temporarily located in the upper portion of the front of the rack because the available DC power cords were too short. This supply will be repositioned to the bottom of the rack when new cabling is available. Done. 2) One fan (out of ten) in the main DPCS cPCI has malfunctioned and will be fixed when a replacement comes in (Tech Request Pending). 3) Cover plates for empty slots in the cPCI crate are on order. Now in house, not yet installed. 4) Routing of various fiber bundles and cables from the cable trays to the new enclosure needs to be neatened up. This will be easier when the old blue racks holding the obsolete hybrid hardware, camac crates, and other associated hardware, have been removed, affording ladder access to the overhead cable trays. 5) The doors and sides of the new enclosure need to be re-installed. 6) Cabling and some hardware from the old installation should be harvested. Some diagnostic patch panels and instrumentation can be installed in the front of the new enclosure for trouble-shooting. The remaining contents of the old blue racks, and the racks themselves can then be transferred to storage. (The Swiss may have some interest in the original Hybrid Computer System).
All of the setup information, as well as the shot programming, for the Digital Plasma Control System is contained in the HYBRID MDSplus tree and its PCS and DPCS subtrees. Volatile data associated with shot programming is stored in the PCS and DPCS trees, and referenced in the HYBRID tree. Static and Configuration data is stored directly in the HYBRID tree. Under normal circumstances, the main Physop interaction with the tree structure is to the PCS and DPCS subtrees, using the PCS.PRO software described in Chapter 6. Changes to the configuration, including changes in inputs or outputs, and modifications to the machine setup (such as reverse-field operation) require updating of the contents of the HYBRID tree, as noted in Chapter 10.
The continued existence of a separate PCS tree is a lingering consequence of the transition from the old Hybrid computer to DPCS. All of the present DPCS software deals directly with the DPCS subtree or the parent HYBRID tree. However, the PCS interface software still operates primarily on the PCS subtree, and while corresponding nodes exist in the DPCS subtree many of these presently contain node references to the data actually stored in the PCS subtree. Most of this is transparent to the user, and is presently necessary to maintain backward compatibility and access to legacy shot programming. The intention is to upgrade the PCS interface software to allow direct access to the DPCS subtree for all operations, and to implement a translation application that will correctly import data from old PCS trees into the corresponding DPCS model. At that point it will be possible to eliminate the PCS subtree completely from new shots.
The top-level nodes of the HYBRID tree are shown in the TRAVERSER display in figure 5.1. Some of the nodes are obsolete. Among the ones that are still in use, the following branches (CHILD nodes) are noteworthy and will be described in more detail below:
CONFIG and DPCS_CONFIG contain information about the system configuration, including hardware status, calibration data, software revs, etc.
DPCS and PCS Subtrees contain the volatile information including shot programming performed through the PCS interface.
DPCS_DEVEL branch contains nodes that control operation of the second “development” dpcs system. This system consists of a second host computer, presently pcdaqdpcs4, and a second cPCI crate containing hardware that essentially duplicates that in the “live” DPCS system. The inputs are connected in parallel with the main DPCS, while the outputs are separately digitized but are not connected to the output AFOLs. Further description of the development system, which can also serve as a hot spare, is beyond the scope of this document.
HARDWARE.DPCS contains the MDSplus device nodes that correspond to the hardware and software functions of the DPCS system. Note that the BITBUS child, which contained the device nodes for the original Hybrid system, is turned off. The only CAMAC function still in use is the C-Mod Encoder which provides the “START” event for C-Mod shots and the “HYBRID_START” and “DPCS_START” event for test pulses. Note that the child \TOP.HARDWARE.DPCS.DIAG_HW contains the separate digitizer used to record the outputs of the DPCS system.
Each of the 128 inputs to the DPCS (A-inputs) is described in a node under \HYBRID::TOP.DPCS_CONFIG.INPUTS:INPUT_nnn. The first 96 of these presently contain references to the parrallel structure under \HYBRID::TOP.CONFIG.INPUTS:INPUT_mm. The structure of these nodes, as described in \HYBRID::TOP.DPCS_CONFIG:AAAINPUTS is
.INPUTS:INPUT_nnn = Unique NAME identifying the input, eg 'BP01_BC' TAG = \HYBRID::HYB_INPUT_NAME_nnn INPUT_nnn:STRUCTURE = Unique description of type of measurement and means of obtaining further information. eg 'FLUX_FULL' INPUT_nnn:QUANTITY = Name of the quantity measured by the signal INPUT_nnn:P_TO_V_EXPR = evaluates to the calibration of the input, in physical units/volt. Most of these nodes contain an expression that invokes a shareable image made from Fortran subroutines that "know" about how to extract calibration information from the tree for given values of STRUCTURE and NAME Each of the 32 OUTPUT signals is described by a node under \HYBRID::TOP.DPCS_CONFIG.OUTPUTS of the form OUTPUT_nn, with underlying structure .OUTPUTS:OUTPUT_nn = Unique name describing the output, e.g. OH1_VOLT GAIN = Calibration of the output in Volts of output/Volt out of supply. This is a signed quantity, for example a typical value for OH1_VOLT is -.01. Note that this actually corresponds to the inverse of the gain of the output device, considered as an amplifier applied to the hybrid output. LIMITS = Max and min allowed values (in Volts), to which the output will be clipped. As for the inputs, the first 16 output nodes and their subnodes contain references to the corresponding nodes under \HYBRID::TOP.CONFIG.OUTPUTS.
\HYBRID::TOP.CONFIG:CONFIG_ID is a text node containing a STRARR which contains the history of the hybrid configuration. The load date of this node is put into \PCS::TOP:CONFIG_ID by PCS.PRO at load time, and the contents copied to \PCS::TOP:CONFIG_TXT. These nodes are used to check the compatibility of old PCS trees or segments with the current state of the hybrid control system. Any change to the hybrid configuration should be appended to the array of text values in \HYBRID::TOP.CONFIG:CONFIG_ID. A node with similar function appears under the parallel branch \HYBRID::TOP.DPCS_CONFIG:CONFIG_ID, which contains information relevant to structures local to the DPCS subtree, including the loadable procedures and additional input and output nodes.
Nodes under \HYBRID::TOP.DPCS_CONFIG.WAVEGEN:REF_10 and :REF_IP contain information about the wire references in a cryptic and convoluted form which references the equivalent nodes under \HYBRID::TOP.CONFIG.WAVEGEN. As noted above, the references for the 16 wires (feedback parameters) are controlled in 4 groups of four channels each. The PCS.PRO software now calls WRITE_P_OUTPUT.PRO, which identifies the reference for each segment as either "10" or "IP", and evaluates the P_TO_V_EXPR in either \HYBRID::TOP.CONFIG.WAVEGEN:REF_10 or \HYBRID::TOP.CONFIG.WAVEGEN:REF_IP accordingly.
The \HYBRID::TOP.HARDWARE.DPCS child node includes two pseudo-devices, DPCS and DPCS2, as well as a real cPCI timing module and INCAA DI02 as shown in the figure (the DT200_1 device, shown OFF, refers to a digitizer that is no longer in use). The two pseudo-devices control the operation of the DPCS software, while the DIO2 module provides the clock and trigger functions for the DPCS digitizers and several associated systems.
The existence of two pseudo-devices, \HYBRID::TOP.HARDWARE.DPCS:DPCS and \HYBRID::TOP.HARDWARE.DPCS:DPCS2 is due to an implementation detail that may have been mentioned above (in a section I haven’t written yet). The software that controls the DPCS is in two parts: a generic code associated with a defined MDSplus pseudo-device type designated DPCS2 which is also used for at least one other system (the RF Fast Ferrite Tuner); and the specific Plasma Control software described here and called “DPCS”. The overloading of those four letters with all these different meanings and node names, child names, tree names, not to mention filenames in various directories, is probably sufficient cause to stop reading and but a new control system!
Perhaps some clarity can be added by looking at an expansion of the DPCS2 device node shown here. The INIT_ACTION, RT_ACTION, and STORE_ACTION are dispatched at the appropriate state transitions of the C-Mod cycle to the mdsip server on pcdaqdpcs3, as described in Chapter 5, where they result in invocation of the correspondingly named procedures dpcs_init, dpcs_real_time and dpcs_store. These procedures are completely generic. Each (optionally) calls a user-specified procedure specified in the child .PROCEDURES in nodes USER_INIT, USER_RT, and USER_STORE which perform the specific control functions required. The .SETTINGS child contains the data pertinent to the operation of the low-latency hardware and the generic software, including the cPCI address used for the digitizer cards, the name of the driver library, details of the triggering and clock, etc. In the present case several of these .SETTINGS nodes contain references to values actually set in nodes under the \TOP.HARDWARE.DPCS:DPCS device. In particular, the cycle time is set by the value in \TOP.HARDWARE.DPCS:DPCS:DELTA_T and disabling of interrupts is controlled by the value of \TOP.HARDWARE.DPCS:DPSC:DISABLE_INTS. Finally, the .SIGNALS child contains the data stored by the generic dpcs_store procedure, namely the raw input data and the final output data. All intermediate values resulting from the calculations of the USER_RT realtime procedure are written by the USER_STORE procedure to nodes found under the parent branch in \TOP.HARDWARE.DPCS.SIGNALS.
As mentioned previously, the device node \TOP.HARDWARE.DPCS.DIAG_HW:DT196_1 is used to digitize the output of the DPCS Analog Output modules (Input_01 to 32). This is a 96 channel digitizer and the second input connector (input_33 to 64) are presently connected to the outputs of the second (DPCS_DEVEL) cPCI crate.
The child branch \HYBRID::TOP.HARDWARE.DPCS.LOADABLES.PROCEDURES contains (by reference to corresponding nodes in the DPCS subtree) the information concerning the various Loadable Procedures. The structure of these subnodes is rather complicated, and is normally dealt with only through the PCS User Interface. More information can be obtained from the description of the structure of loadable procedure software (if I ever get around to writing it).
Finally, the child \TOP.HARDWARE.DPCS.PERFORMANCE contains performance and status information for evaluating the operation of the DPCS. Two actions under this child provide broadcast information to the responsible parties in the event a system problem is detected.
This section needs to be written. Include material about structure of the DPCS tree, segments, loadables, ...
Programming of the DigitalPlasma Control System, or equivalently, programming the shot, is accomplished by means of the PCS software package. This package is written in IDL and maintained by Steve Wolfe and Josh Stillerman. All of the actual shot programming is stored in the PCS and DPCS trees under the MDSplus data system, and input to the DPCS control process during the INIT cycle. The PCS interface provides the means of loading the desired information into these trees.
This chapter is intended to comprise a fairly complete manual for the use of the PCS interface, organized on a screen-by-screen basis. By necessity, some features will be left out or incompletely covered. Hopefully, later drafts will improve on this situation. Figures display the screens under discussion in each section; note that in Firefox clicking on a link with MB2 allows the reader to view the figure in a separate browser window or tab. For the first-time reader, it may be best to go through this chapter with the PCS interface running (in /SAFE mode!) and try the operations as they are introduced.
To invoke the PCS interface, click on PCS or PCS (safe) in the C-Mod Operations submenu of the Gnome or KDE Main menu, or from the Bash prompt type
/usr/local/cmod/codes/pcs/pcs
and follow the directions on the screen. Details on obtaining the necessary resources and invoking the software may be found in Section 9C.
The more experienced user should proceed directly to the relevant section of this document for specific information by clicking on the appropriate link in the following outline.
A. PCS Main Screen - Shot Level Commands B. Wires, Segments, etc. - Segment Commands C. Waveforms - All P and All V Screens D. Algorithms, Gains, etc. - the EDIT_WIRE Screen 1. Wire Names 2. Observers (also called "Predictors") and their algorithms 3. Wire level commands 4. PID Gains 5. Controllers (and their algorithms)
The main PCS screen contains information about the current configuration, a few user-modifiable value fields, and a large number of buttons which provide access to the various editing and control screens which perform the main operations of the interface. With the exception of the table of “DPCS Loadable Procedures” and the row of control buttons along the bottom of the screen, which control shot-wide functions, the PCS controls are contained in panels (columns) corresponding to the segments, which may be considered as relocatable blocks valid in particular time intervals. Further discussion of the segment concept, and of the meaning of the term "wire", are found in the following section.
The left-most column of the main PCS screen contains configuration information. In the illustration, we see that wires 1-4 are hard-wired to have Ip reference, while wires 13-16 have reference '10'. These are the standard settings, and can only be changed by making the appropriate change to the configuration nodes in the HYBRID tree. Also in the left column are listed the integrator channels (A, C, or N) and differentiator time constants for each of the 16 wires. Again these values are only changeable by modifying the HYBRID tree.
The table headed “DPCS Loadable Procedures” with column heads ASYNC_PROS, INPUT_PROS, etc., provides an interface to the user-defined procedure feature of the DPCS, which is discussed below.
The buttons along the bottom of the main PCS Screen relate to operations on the whole DPCS and PCS Pulse File, and to operation of the PCS Operator Interface. From left to right we have:
The "Quit" button is self-explanatory. It exits the widget interface.
The "Reset" button refreshes the information on the main screen with that from the working PCS tree. It effectively performs a RESET_SEGMENT on each segment of the shot.
The "Save As" function allows the user to save DPCS and PCS trees that have been modified using PCS in a location other than the public PCS_MODEL files. This is the only output available when PCS has been invoked with the /SAFE option, or for a user with no write privilege to the public MDSplus directories designated by pcs_path and dpcs_path. The SAVE AS popup that appears when you push this button requires specification of at least one directory and a shot number. It is a bad idea to use a potentially valid C-Mod shot number, even when specifying a local (private)directory; using a valid year and date code with a three digit shot number not in the range 001 to 099, e.g. 1091105666, is acceptable. Note that "Save As" does not force a build.
The "Load From" function permits importing programming for an entire shot, either from an actual past shot or from a tree that has been prepared off-line and stored using the "SAVE AS" feature. The LOAD_FROM operation will copy both the DPCS and PCS trees from the designated shot into your working copy, provided both exist. It you try to LOAD_FROM a shot older than 2004 or so, you will get a pop-up complaining that no DPCS tree exists and the dpcs_model files in your working directory will be retained; this is usually ok, but you should pay attention to what DPCS features are enabled (and ask yourself if you really want to try to reproduce such an old shot). If the specified source shot is sufficiently old it is likely that something in the configuration of the Hybrid, or of the tokamak, will have changed. PCS tracks configuration changes by comparing the nodes \PCS::TOP:CONFIG_ID and \DPCS::TOP.CONFIG_ID to the store time of \HYBRID::TOP.CONFIG:CONFIG_ID and \HYBRID::TOP.CONFIG:DPCS_CONFIG:CONFIG_ID. If these do not match the code generates a complaint widget containing the history of the Hybrid configuration, with advice on what actions need to be taken to make the old tree or segment conform to the new configuration. It is important that these remedial actions be taken before the new tree is loaded, since the configuration tracking information in \PCS::TOP:CONFIG_ID and \DPCS::TOP.CONFIG_ID will be updated at load time, and the warning will not be generated on future access to that tree. In the case of "Load From", which imports and entire shot, it is necessary for the user to take the indicated actions for all of the segments, even unused ones, since the subsequent CONFIG_ID update will apply to the whole shot.
The configuration history of the current HYBRID tree can always be viewed using the "Show HYBRID Config" button at the bottom of the main PCS screen. The adjacent buttons "Show PCS Config" and “Show DPCS Config” display the same information for the PCS and DPCS trees.
The "Build All" control forces the PCS software to update all of the bit-level and loadable data for which the sources have changed since the last Build. If we think of the user inputs as source code, then doing a build is analogous to using MAKE (or DEC MMS) to perform a compile and link operation. Use of the "Build All" command is not necessary, since doing a "Load" includes a Build operation, but it is sometimes useful to do one anyway, to pick up incompatibilities or bounds violations. Note that since the Build will not force recall of algorithms, inconsistencies in input configuration will not be detected by this procedure. It is fairly common practice, although technically wrong, to ignore nearly-transparent changes in inputs, such as substitution of one Bp loop with another from a different toroidal set, rather than re-calculating all of the algorithms for the sake of negligible modifications in the observer coefficients and factors.
The button labeled "Load" has the function of performing a build, updating the PCS and DPCS configuration data, and copying the PCS_MODEL and DPCS_MODEL trees in the working directory into the public models directories, where they become the "live" models from which the next shot will be taken. (When PCS is invoked with the /SAFE switch, this buttons is inactive.) This operation must be completed before the transition into INIT state; trying to load a shot after INIT has begun can cause serious difficulties. Note that the LOAD operation echoes the time the load completes to the calling terminal window; this can be helpful when you aren't sure whether you loaded the last changes or not.
The "READY" button causes a distinctive sound effect to be broadcast over the control room and alternator house speaker system (provided the Engineering Operator is running the CMOD_ANNOUNCE program). This may be used to alert the Engineering Operator (and anybody else within earshot) that the shot has been loaded and the Physics Operator is ready for the transition to INIT state. Excessive use of the "Ready" button can be annoying and should be avoided.
The “Simulate” button at the right of the bottom row invokes the ALCASIM simulation program, a MATLAB/SIMULINK application written by Marco Ferrara. Use of this feature is beyond the scope of this document. Interested parties are advised to consult the Alcasim User Manual.
As described above, the Observer Stage has sixteen total outputs, which correspond to quantities being feedback-controlled by the Digital Plasma Control System. Each of these signal lines is referred to as a "WIRE". Depending on the contents of the A-matrix the physical meaning of each wire can change in time. An important concept in using the PCS software is the SEGMENT. A segment consists of a time interval during which each of the 16 outputs of the A-matrix (called "Wires") has a fixed meaning. Within each Segment, the scale factor mapping the physical quantity to the internal units of the calculation, corresponding to the -10V to +10V range of the old Hybrid Computer hardware, is fixed. Furthermore, the reference (either the Ip signal or a constant 10V) applied to the corresponding target waveforrm can be switched only at a change of segment. The number of segments is defined in the PCS and DPCS trees, and for recent shots is fixed at four; typically, fewer than the maximum available number of segments are active during a given shot.
Four panels in the PCS Main Screen correspond to the four segments; the structure of these are identical. Underneath the segment number are two check boxes indicating whether the segment is On or Off and whether it is Synchronous or Asynchronous. While DPCS now supports the use of Asynchronous segments in conjuction with certain Loadable Procedures, we will defer discussion of this feature until later. Almost all C-Mod shot programming employs Synchronous segments, for which things are programmed to happen at specific absolute times during the shot.
A writable text widget below the check boxes contains a name or description for each segment. In the case illustrated, Segment 1 is "2008 startup-baseline subtract" and Segment 2 is labeled "1.35 MA, quasi-ITER SNL"; these two segments are turned on, so they will be active for this shot. The inactive segments 3 and 4 contain programming for alternate shot sequences, a "1MA, Upper Null" shot and a "1.2MA, 5.75Tesla, SNL". The naming convention is arbitrary, but it is helpful to give each segment a reasonably descriptive title. Unfortunately, nothing enforces the name to be consistent with the actual shot programming, and PhysOps often forget to change the title when they modify the program, so that a title indicating a 1MA Upper Null may get attached to a segment with a different current programmed; it is never a good idea to rely on the segment title without checking the actual waveforms. The next row below the title contains a read-only text window that gives the Source of the segment. This field is filled in following a LOAD_FROM or IMPORT_SEG operation and refers to the origin of the segment as known within the current PCS session. This information is not stored in the tree, and does not reflect any changes that may be made to the segment after loading or importing. It does however serve as a reminder of the starting point, which can be useful.
To run either of these alternate segments with the startup programming in segment 1, it is only necessary to click segment 2 OFF and either segment 3 or segment 4 ON (but not both!). The start time for each segment is given in the value field below the name, -3.5 seconds for the startup segment, and +0.1 seconds for the other segments. Note that the programming of each (Sync) segment is in effect from its start time until the start time of the next active (ON) segment. It is a mistake to set two or more Synchronous segments with the same start times both On! The final programming is formed from the union of the active segments, with extra control points being inserted at the transition times if necessary. In the case shown, there is no programming until -3.5 seconds, when Segment 1 turns on, and the programming in segment 2 is in effect from 0.1 seconds until the end of the shot. This example illustrates a typical use of the segment concept. The startup sequence is essentially independent of the later evolution of the shot, but may need to be adjusted frequently; the main part of the shot requires control of different quantities than startup, and a given run may involve several types of "flattop" segment, which are conveniently programmed as separate segments and switched in and out as needed. Another option is to program a rampdown sequence in segment 3 or 4.
Continuing down the panels, we find another feature of the segment structure, the designation of the waveform reference signal for wires (channels) #5-8 and #9-12. These references are software setable (in the groups of four indicated), and can be changed in each segment. In the example, the startup segment uses a “10V” constant reference for all eight of these wires, while the later segments use Ip reference for wires #5-8 and the constant reference for #9-12. The choice of waveform reference of course restricts what quantities may be put on a given wire; it would be a mistake to put a density control on an Ip-referenced wire, for example (unless you really wanted to control a quantity proportional to plasma current times density). We will return to the issue of assigning plasma parameters to wires in our discussion of the EDIT_WIRE screen below.
Below the reference selection check boxes are buttons corresponding to the sixteen wires, each bearing the names of the assigned parameter for that segment. Pushing any of these buttons pops up an EDIT_WIRE screen, from which essentially all of the programming associated with that wire can be accomplished. The buttons in which the names are in lower case indicate wires with zero gain, i.e. For which no feedback is to be applied. The case display convention can be somewhat misleading, since a wire with zero gain within the segment active time interval, and non-zero gain at earlier or later times, will still show up with an upper case name on the main display; this is probably a bug.
Note that in the example shown, in both segments 1 and 2 the names on the second and third wire are the same, "ZCUR", and there are asterisk (*) symbols surrounding the name. The asterisk marks wires which have linked waveforms within a given segment. That is, the programming waveform for ZCUR on wires 2 and 3 in segment 1, and also in segment 2, are forced to be identical (within each segment). Editing the S waveforms on any of these wires also changes the programming for the other wires. However, the Controllers, Gains, and even the Observers associated with the different wires are not restricted. It is usually a good idea to have the Observers for linked wires be the same, but this is not enforced. The purpose of using different wires to feedback on a single quantity is to enable different controllers to act simultaneously with different gain schemes. In the case of the vertical displacement ZCUR in this example, wire 2 is used for slow control, using multiple coils, while wire 3, the "fast" control, drives the CHOPPER supply, which is connected to the EFC coils. Any set of wires within a segment which have identical names will have their waveforms linked in this manner. Note that the waveforms are only linked vertically, not horizontally; changing a waveform in segment 1 has no effect on waveforms in segment 2.
The next row of three buttons "All Ps", "All Vs", and "Integrators" provide graphical editing capability for segment-wide parameters. We will consider these capabilities in detail in Section C below. Continuing to examine the buttons in each SEGMENT panel of the main PCS Screen, we come to the "Import Seg" function. This button implements one of the principal features of the segment-based organization of PCS, the ability to load a portion of a shot, either based on an old shot or on off-line development, while retaining other segments intact. Pushing the "Import Seg" button pops up a widget that prompts for a source shot and segment number.
Like "LOAD_FROM", the "Import Segment" function performs configuration checking to determine if the source shot is consistent with the current HYBRID configuration. If the complaint widget appears, the user should determine from the history what actions are necessary to bring the imported segment into conformance, and take them before proceeding to further modify or Load the shot. If the specified segment is from before 2004, then likely the corresponding DPCS tree will not exist, and a complaint widget will pop-up informing you of this fact. The nodes in the dpcs_model tree in your working directory will not be modified, which will generally be what you want, since most of the segment-wise entries just contain references to the PCS tree anyway. One exception is the V#17-32 waveforms, which will still have whatever values were present before the import, while these were of course not present in the imported segment.
The COPY_SEGMENT routine copies all of the segment data from the source shot into target segment in the current working tree, except that the on/off status of the working tree is retained. Note that copying the contents of all the nodes in a given segment is considerably more time-consuming than simply copying whole files, so the Import Segment function takes several seconds, unlike the LOAD_FROM function which only does file copying. COPY_SEGMENT does not include a build, i.e. the loadable nodes are not immediately updated. However, doing a LOAD (or Build All or Build Segment) will cause the loadables to be updated.
The "Zero" button in the segment panels causes all of the wires to be renamed to zero_nn, and all the waveforms, gains, and matrix elements to be set to zero. This operation does execute a build to zero the loadables as well.
The "Build Segment" button forces a recomputation of all the loadable elements in the segment for which the sources have changed since the last build. While this operation is carried out automatically during the LOAD operations, it is often a good idea to try building a segment if the observers or controllers have been changed. This step will often pick up incompatibilities and out-of-bounds errors so they can be corrected, rather than waiting until just before a shot to find out the LOAD operation fails.
The "Reset" button refreshes the segment parameters visible on the main screen from the values in the tree. Basically, this includes mainly the ON and SYNC status, the segment name, the start time, and the wavegen reference selections.
We will consider the EDIT_WIRE screen in detail below. First, let us look at some of the buttons below the sixteen wire buttons, which deal with multiple wires. The first row contains buttons for "V#01-16", “V#17-32”, and "All P's". First, consider the "All P's" screen, which appears when the corresponding button in segment 2 is pushed. The display consists of 16 panels containing the program waveforms (the "S" traces) for each wire, in a format similar to that of DW_SCOPE. In addition to the standard Point, Zoom, and Pan mouse mode controls familiar from DW_SCOPE, there are additional options "Add", "Control", "Stretch", and "Paste" for manipulating the waveforms, using the control points indicated on the traces by small squares. Mouse operations for buttons MB1 and MB2 are displayed for each mode in the line of text below the selection options. MB3 pops up a menu with additional options. Note that the title bar displays the name of the segment, but not the segment number. The functions of the various drawing modes are summarized briefly as follows. "Select" provides operations on existing knots (control points); these can either be moved by dragging or by entering values in the Set windows. "Add" provides similar operations to "Select" with MB1, and MB2 creates or deletes knots. The "CONTROL" function is obsolete; it blanks a portion of the trace, but does not perform any useful purpose. The "Stretch" mode allows the user to drag or stretch/shrink the waveforms. The "Paste" mode is essentially the same as COPY mode on DW_SCOPE, with the added feature that special coding is used to reduce the number of points in the imported trace to a number consistent with the allowable number of control points; this allows importing of data traces (for example, from a SCOPE) with potentially thousands of data points as the basis of target waveforms. Of course, one can also copy traces from panel to panel or from one segment to another. The "INSERT" and "REMOVE" buttons are active only in "Point" mode, and, on this multi-trace screen, provide a mechanism for simultaneously inserting control points at the crosshair location on each trace. This can be useful for adding an inflection point at a common time on multiple parameters. The popup menu under MB3 includes an autoscale function and a "Set at Limits" function, which relies on limiting values for each trace obtained from the P_INFO function (or from defaults). These limits are presently implemented only for display purposes, and are no longer enforced. Aside from the print functions, the other useful item on the popup menu is the "FLIP" function, which provides a fast method of multiplying a trace by -1; this is especially useful for setting up reverse-field runs. The OK, APPLY, and RESET buttons along the bottom of the window become active (not gray) when any trace is modified. RESET reloads the data from the current state of the tree, while OK and APPLY have the obvious functions.
The "V#01-16" and “V#17-32” screens are the same as "All Ps" except that they deal with the V (feedforward) waveforms. Unlike the S (or P) waveforms, which can also be edited on the EDIT_WIRE screen, the V waveforms can only be programmed using one of these screens. While the V waveforms are programmed in the same manner as the P signals, it is important to recognize that their function is quite different. The 32 V signals are associated not with the wires, which represent the parameters being controlled, but with the output devices, i.e. the power supplies and gas valves. The V signal is the output that will be demanded from the output device in the absence of any feedback signal. As such, these signals serve two purposes. For outputs with no non-zero controller coefficients, the V signal is an open-loop programming demand. For example, the pre-puff gas valve is often run in this open-loop manner during startup (segment #1), and the TF current is run with only a "V" program when hybrid control is used for the TF. For outputs "connected" to the controllers for one or more wires, the V programming acts as a default output, which should appear when all the error signals are at zero. This feature can be used to reduce the dynamic response needed in the feedback loop, which can be important since the effective loop gain of the Plasma Control System is typically quite low. One possible way of programming the feedforward V signals is to use the Paste function to copy in the actual output voltage, including the part due to feedback, from a successful shot, for example from the PHYS_M_OUT scope. In practice, this turns out not to be as good an idea as it sounds.
The "Integrators" screen allows setting of the integrator gate interval (in each segment) for each of the available integrator “circuits”. At present, there are two gates, referred to as "A" and "C", which are assigned to wires as indicated in the left-most column of the main screen. The integral gains for each wire can be set on the EDIT_WIRE screen. Note that the integrator gate trace on the EDIT_WIRE screen is read-only; the gates are set only from the "Integrator" screen at the segment level. Note that the Integrator screen uses "step mode", such that the value of the trace following a knot is constant at the value at that knot, rather than being interpolated between adjacent knots.
We now return to the individual wires and the functions available on the EDIT_WIRE screen, which is obtained by clicking on one of the sixteen wire buttons under each segment. Note that only one EDIT_WIRE screen is available at a time, which restricts somewhat the user's ability to use graphical copy methods; however, this can be circumvented by use of the "All Ps" screens on the one hand and various IMPORT and COPY functions described below on the other.
The EDIT_WIRE screen offers a lot of functionality, and we will go through most of it here. The novice reader is advised to refer to the figure or run PCS/safe or both, to better follow the descriptions in this section. The non-novice user probably knows all this stuff, and may wish to skip this section entirely.
Note that the EDIT_WIRE screen is headed by an identification of the wire and segment displayed. This is a handy feature, since it is easy to lose track of what you are doing. Note that some of the IMPORT options described below will offer choices of wire/segment to use as a source.
The P Name field is editable, and can be used to change the name of the quantity represented by the wire. The name is used to identify the signal to the observer and controller algorithms (see below) as well as on the display. In principal, there are no restrictions on the names that may be assigned to the wires. Since the contents of the observer (A-matrix coefficients) are what actually determine what a given wire represents, the name is in some sense arbitrary; if a Physop wants to call a wire "TURNIPS", it is allowed. In practice, it is standard to use names that have some meaning; for example, RCUR is intended to be the radius of the current centroid. Commonly used names are "registered" by including some basic information about their usage, such as limiting values, units (SI preferred), an expression to be appended to the drawn waveform before passing to the wavegen, and the wavegen reference ('IP' or '10'), in the IDL function /usr/local/cmod/codes/pcs/p_info.pro, which returns a structure containing these quantities. It is not essential that a wire name appear in P_INFO, which will return default values for unknown names.
The fields labeled "Abort" to the right of the Name field are presently non-functional. They are related to the adaptive programming (vaporware) features.
The three-row table below the name, and the adjacent EDIT and Call buttons, deal with the observers (sometimes referred to as predictors or estimators) which consist of vectors of coefficients to be applied to the inputs to provide a linear approximation of the quantity of interest. These observers can be time-dependent; at present each wire is restricted to three observers per segment, as represented on the three rows. In general, the observers are generated and returned by IDL procedures called "algorithms". The particular algorithm invoked at each time is specified by name in the third column of the table.
User-supplied algorithms are contained in the directory /usr/local/cmod/codes/pcs/user_algs/, which appears in the !path defined by the shell script that invokes the PCS User Interface. The calling sequence for the observer algorithms must conform to the following standard.
STATUS = algorithm(version_id,wire_name,observer,Input_Names [,keywords=keywords]) where STATUS is a longword output where a value of 1 indicates success Version_id is an output string variable containing an identifying code for the routine. This string is displayed in column five of the table on the EDIT_WIRE screen. It could be a simple date or include information about the switches used by the algorithm to calculate the observer. wire_name is an input string variable containing the name of the wire observer is a FLTARR of length N containing the vector of coefficients for the non-zero elements of the observer. The observer is returned in Physical units, i.e. the coefficient of a flux-loop corresponding to the wire_name RCUR (which is Ip-referenced) would be in units of amp-meters/Wb. Input_Names is a String array of length N containing the names of the corresponding hybrid inputs. These names must match the inputs listed in \HYBRID::HYB_INPUT_NAME_%%
Optional algorithm-specific keywords may be supplied in the appropriate field (fourth column) on the EDIT_WIRE screen.
On exit, the function must not have modified the default location in the tree, nor have closed the currently open tree. User algorithms often report progress and error messages to the terminal window. It is often of use to the algorithm function to know what inputs are available to the hybrid, which will involve doing MdsValue() evaluations in the HYBRID tree. This is straightforward, since the HYBRID tree is open when the algorithm is called from PCS.PRO. Use of full pathnames rather than mdssetdefault is encouraged, but the latter can be used as long as care is taken to set the default location back to where it was at the point of algorithm invocation. Similarly, if an algorithm needs to look at other trees (that is, other than the current HYBRID and PCS model files), then the default location must be evaluated on entry and reset on exit (including abnormal exits). Any trees opened within the algorithm should be closed using the explicit syntax
mdsclose,tree,shot rather than the generic mdsclose, which would close the HYBRID tree and cause PCS to fail.
An algorithm function may be used for a number of different parameters, with the return being determined by recognizing the value of the wire_name argument. Obviously, if an algorithm is passed a wire_name unknown to it, it should return an error. An example of a user-supplied algorithm is FLUXIHH, provided by Ian Hutchinson. This algorithm is used to provide observers for a number of shape parameters, based on a filament model of the plasma and flux differences between specified points in space. Other algorithms provided as part of PCS are CLEAR.PRO, which returns an observer of all zeros, and CUSTOM.PRO, which brings up an edit screen for manual entry of coefficients; this is the same screen brought up by pushing the Edit button to the left of the table. User-supplied Observer algorithms are located in the directory /usr/local/cmod/codes/pcs/user_algs/ and its subdirectories, and presently include
FILAMENT.PRO
FLUXIHH.PRO
ROGOWSKI.PRO
VACUUM.PRO
The remaining editable field in the table is labeled "Offset" and is used to provide a correction for DC offsets that may be present as a result of the hybrid hardware or to compensate for non-linearities or other inacurracy in the observer. These are typically determined empirically. The effect of a number entered in the Offset column is to insert a coefficient on INPUT_096, "MINUS_ONE_VOLT". The value should be in physical units. Note that calling the algorithm zeros this coefficient, so if a suitable value has been established it should be noted before hitting the Call button, and then re-entered.
The time column contains the start times after which each observer will be switched in to the calculation. Of course, time values earlier than the start time of the given segment are mapped to the appropriate segment boundary; times after the start time of the next active segment are never loaded. Clicking the SORT button (on the row beneath the table) causes the rows to be re-ordered in temporal sequence.
The algorithm routines may be invoked one row at a time, using the adjacent Call button, or for all rows using the "Call Algorithms" button.
The second button on the row below the observer table is used to set the "factor", the calibration for each wire in terms of “Volts”/physics unit. In the original Hybrid Computer implementation of the control system, this scaling represented the actual voltage level of an analog signal in hardware. Since the control computation is now done in software, this quantity is irrelevant as long as single precision round-off and overflow criteria are satisfied. The Factor Screen presents the maximum scale factors for each row, based on setting the maximum voltage gain coefficient of the corresponding observer (i.e. the physics predictor times the P_TO_V_EXPR value for the input) to the former hardware maximum value of 2.5. This restriction is no longer meaningful, and limitations on the value of factor are no longer enforced. This window will be eliminated in a future release of PCS.
Proceeding along the row of buttons below the observer table and above the draw widget, we find three controls for importing information into the current wire: "Load Wave", "Load Wire", and "Load Gains". The first of these will load any waveform, i.e. any signal, into the current P waveform; this function is not restricted to PCS trees. The "Load Wire" will import the contents of a specified wire in the current or any other PCS tree; everything associated with the wire will be imported, including gains, controllers, etc. The "Load Gains" button copies the PID gains from another location in the current tree only. Note that it is possible using this switch to import gains which include finite integral gain onto a wire with no integrator. This is probably a bug.
The next button, marked "ZERO All" is rather dangerous. It has the effect, as advertised, of zeroing out all the gains, waveforms, observers, etc. However, it does so by writing zeros directly into the tree, without waiting for an APPLY or OK. The Wire_name is reset to ZERO_nn, with nn the wire number. The fact that it pops up a Warning announcing this fact is of little help, since it provides no backout mechanism. The Zero All button should be used only if you are sure that is what you want. The same can be said (in spades) for the "ZERO" button located at the bottom of each segment, which provides a completely zeroed segment for those wanting to start from scratch.
The last button in this row invokes the Controller screen, to which we shall return below. First, let us consider the draw widget on the EDIT_WIRE screen, which permits graphical editing of the waveform and the PID gains. The controls are the same as on the ALL Ps screen. The bottom panel contains the S waveform, as on the ALL Ps screen. Note that if both an EDIT_WIRE screen and All Ps screen are active simultaneously, changes on one are not automatically reflected on the other, and the last one to be APPLY'ed or OK'd will control the final state of the tree. This can have unwanted consequences.
The top panel of the draw widget shows the integrator gate timing for the current wire, if any. This panel is read-only; changes must be made on the segment-level Integrators screen. The second panel is the integrator gain trace, which is editable in EDIT_WIRE. When the integration function was implemented in circuitry, it was advisable to turn on the integral gain before the corresponding gate switches on, to avoid unwanted influence of integrator drifts; this is no longer important. The derivative and proportional gains are provided on the next two panels. Note that all of the gain traces are controlled as step-wise signals, maintaining the level at each not until the level switches at the next knot. Internally, the PID gains are in a range -10 to +10 (volt/volt), and this is the scale displayed by default. Two buttons below the display allow the PID gains to be shown in "physics units", which are effectively 1/sec for the P gain, non-dimensional for the Derivative gain, and 1/sec^2 for the integral gain. Evaluation of these physical gains depends on the existence and accuracy of an effective time constant associated with the controller. The actual values displayed are therefore somewhat suspect.
We now return to the Controller Screen which appears in response to clicking on the "CONTROLLER" button on the EDIT_WIRE screen. This screen consists of a time-ordered table similar to that used for the observers on the EDIT_WIRE screen. Like the observers, the controller calculation (M-matrix elements) is algorithm-driven; up to five switch times are allowed for controllers on each wire. The syntax for the functions implementing the controller algorithm is similar to that for the observer:
; STATUS= algorithm(VERSION,WIRE_NAMES,CONTROLLER,C_NAMES[,Optional_Keywords=ok]) ; where the mandatory arguments are: ; Inputs: ; WIRE_NAMES STR or STRARR containing the NAMES of the wire ; quantities for which controllers are to be ; returned. ; Outputs: ; VERSION Scalar string identifying the code ; CONTROLLER FLTARR of dimension (nc,nw) where ; nw = n_elements(WIRE_NAMES) and ; nc = n_elements(C_NAMES). Nominally, ; the units of CONTROLLER are Physical_output/Physical_error, ; e.g. Volt(at power supply)/ Amp-meter. ; C_NAMES STRARR consisting of the names of the outputs, ; as given in \HYBRID::HYB_OUTPUT_01 to \HYBRID::HYB_OUTPUT_16, ; corresponding to the elements of CONTROLLER(0:nc-1,*) in order. ; ; Return: Longword status return, 1 == Success ; 0 == UNspecified failure ; < even integer> == User-defined error ; ; Optional Keywords: Any other information required, as defined by the ; supplier of the algorithm. ;-----
By convention, the controller algorithm returns a controller in physics units scaled to a 1 second time constant. The PCS software then scales the coefficients to 80% of the maximum allowed and calculates a new "controller factor" and an effective time constant for each row of the table. These can be adjusted using the "Time Constant" button on the Controller Screen. Like the “Predictor factor”, to which it is related, the restriction to a particular range for the controller factor is no longer meaningful, and has been (mostly) removed. If the user encounters any error messages or warnings related to this quantity a bug report should be filed.
The controller on each row of the table can be edited using the adjacent "Edit" button. The pop-up screen contains editable fields expressing the coefficients. The column headings on this table are seriously misleading (i.e. wrong). The editable fields, headed "Hybrid", are in fact in physics units, e.g. V(from the power supply)/amp-meter in the case of RCUR. The second column gives the limiting values (corresponding to a hardware gain of 2.5) in the same units. Note that this limit depends on the predictor factor as well as the output gain of the hybrid. The column labeled "Physics" in fact contains the equivalent coefficients corresponding to a nominal time constant of 1 second, i.e the values which should have been returned by the controller algorithm. The time constant field near the bottom of the screen contains a value (for the rate, in sec-1, not the time constant) based on the return from the controller algorithm; this value should only be adjusted if the user knows the value to be incorrect. Note that the immediate effect of changing this number is to modify the physics controller column, not the actual coefficients used in the computation. The "Time Constant" screen, accessible from the Controller screen should be used to adjust all of the coefficients for all the rows proportionally. Note that the value being adjusted is actually the rate in inverse seconds, not the time constant; a larger value corresponds to higher gain (faster response).
The controller screen also provides the possibility of importing a set of controllers from an existing pulse file using the "Read From" command. A directory location (defauted to $pcs_path) as well as segment and wire designation may be specified.
Also available from the Controller Screen is a graphical "Display" of the time-dependent controller. Note that this screen provides no editing capability, and given the relatively small degree of time variation the display is of dubious utility.
It is important to note that clicking APPLY or OK on the Controller Screen writes directly to the tree. This operation cannot then be reversed by using the RESET button on the EDIT_WIRE screen.
A new and extremely powerful addition to the Plasma Control System afforded by the implementation of DPCS is the ability to supplement the linear matrix multiplication paradigm for Observers, Gains, and Controllers with arbitrary realtime code in the form of “Loadable Procedures” which can be executed as part of the software-based control loop. The role of the various classes of such procedures in the realtime loop is described above. In this section we describe the PCS interface for controlling the use of these functions.
At present, use of loadable procedures is a shot-wide function controlled by global (i.e. not under individual segments) nodes in the DPCS tree under \HYBRID::TOP.DPCS.LOADABLES.PROCEDURES. A future release of the PCS interface may support a segment-wise implementation of these procedures, but this feature is not yet available.
Access to the loadable procedures associated with the given shot is provided by the table of columns and buttons near the bottom of the main PCS screen. The columns correspond to the different “classes” of the procedures associated with their position in the DPCS realtime loop. The procedures themselves are to be found in the correspondingly named subdirectories of /usr/local/cmod/codes/dpcs/user_algs/ . Each procedure associated with the shot is represented on the main screen by a button with the name of the procedure adjacent to a check box which indicates whether or not it is active, i.e. if it will be called during the realtime loop. In the example screen two procedures, the ASYNC_PRO called dpcs_fizzle and the INPUT_PRO called baseline_sub, are turned on, while the ASYNC_PRO dpcs_xjump and the TEST_PROS dpcs_ftae2 and dpcs_jet_trigger are available but presently turned off. Each column with fewer than three named procedure buttons also includes a button labeled “New” which will bring up a dialog box to enable the user to add a procedure from among the available routines in the relevant directory.
If
you click on one of the named buttons, for example dpcs_fizzle under
ASYNC_PROS, an Edit_Procedure widget
should pop up. At the moment all the available procedures use a
generic form, with a dozen fields, not all of which are used by any
particular procedure. In the case of dpcs_fizzle,
the relevant fields are the "source_shot" and "segments"
values. These identify a shot number and segment to be used as the
source of the waveforms to be used for the fizzle sequence. Fields
can be designated as "MDS Expression" or "IDL Value";
since the shot number is listed as an "MDS Expression" it
is legal to put the quantity $shot in this field, which would
indicate that the fizzle programming is to be taken from a segment in
the actual shot. The value that is actually entered at the moment is
1090731017, a shot from this year that contains the programming we
have been using lately. Most fields on the EDIT_PROCEDURE screen can
be safely left as MDS Expressions, which is the default. An exception
is in the case that a required parameter to the procedure is in the
form of an IDL structure, normally written as a set of tagname:value
pairs between curly brackets, e.g. {THRESHOLD:
1.00000e+14,GATE:[0.120000,0.600000],JUMP_TO: 1.60000,TAVG:
0.0100000}, which must be formatted as an IDL Value.
At
the top of the Edit_Procedure widget is a button to turn the
procedure On or Off. This is the usual way of enabling or disabling a
routine for a given shot or sequence of shots; turning a procedure
Off leaves the setup information in place for future use, but
disables the routine so that it will not run. Clicking the REMOVE
button actually clears the nodes from the DPCS tree, and re-enabling
the procedure would then require that it be restored by clicking on
the "New" button on the procedure menu and going through an
additional dialog. Using On/Off is preferable, unless it is
necessary to remove a procedure to make room in the tree for another
one. There are three procedure slots allowed for each class of
routine (ASYNC_PROS, INPUT_PROS, etc.)
Startup is the most basic and the most frustrating task facing the C-Mod Physics Operator. For whatever reason, Alcator C-Mod suffers from significant difficulty in maintaining a reliable startup scenario. In this section, we review the basic approaches, and the available tools. In considering the advice presented here, keep in mind that:
It is free, and possibly worth what you paid for it.
The author has, at one time or another, held the records for both most consecutive successful startups and most consecutive unsuccessful startups.
Fundamentally, all you need to do is to generate an initial poloidal field null, provide the appropriate fill pressure to generate an avalanche with the applied voltage, and then let the fields evolve so as to maintain an equilibrium as the current rises. What could be simpler?
A quantitative discussion of breakdown requirements can be found in [1]. There is also a package [2] of (mostly) hand-written notes on the subject by Ian Hutchinson floating around.
The startup sequence consists of a pre-charge phase, lasting 1-2sec, during which the coil currents are ramped up to preset values intended to produce a field null, followed by an initiation blip, in which the PF currents are swung rapidly, using a combination of supply voltage and the resistive drop across commutation resistors switched into circuit by solid state interrupters, which induces a substantial loop voltage. The time at which the OH1 interrupter fires is nominally t=0.0. Gas is introduced using a pre-puff at about t=-0.5sec.
Startup scenarios have been developed at several pre-charge levels. At present, the standard startup uses OH1 current of approximately -20KA, which corresponds to an initial flux linkage of about -1.7 Wb. In this section, we will consider tuning about an existing startup scenario to optimize breakdown and current rise. Development of a new scenario, for example with different pre-charge currents, is in principle not that difficult, but is rarely done. We tend to stick with what (sort of) works until an obvious need presents itself. Therefore, we will not consider development of new startup scenarios in this document. Those interested should consult the logbook and Physop_Summaries.
We will use a specific startup scenario, namely segment 1 from 980220004 to illustrate the main features of programming this phase of the shot. This example has no special features to recommend it beyond the fact that it did work at the time, and is typical of startups used during the 1997-1998 Campaign.
The power systems setup for this shot is shown here, and is fairly typical of recent shots. The start times (and switch close times) for the power supplies involved in forming the field null are chosen to allow enough time for the currents to reach their target values and to minimize the effects of mutual inductance. For this shot all the supplies are under hybrid control, including the TF. Note that "EFC" on this panel refers to the TMX DC supply which provides static voltage for the GA chopper; it runs under PLC control with the timing and voltage setting (700V) shown. The chopper itself turns on 50 msec after the TMX, i.e. at +0.045 sec, and is under hybrid (i.e. DPCS) control.
As noted in Chapter 3, the OH and EF1 coils are configured with commutation circuits. The coils begin to charge up with the solid state switch open, so the current flows through the commutation resistor until the switch close times, after which it flows through the SCR. These times are taken long enough after the power supply start to insure that a positive voltage will be seen across the SCR when the gate pulse fires. At the switch open the current in the SCR is forced to zero, and the current again flows through the resistor, providing a large voltage blip which, hopefully, results in plasma initiation. The commutation resistors (shown in mOhms), are sized to provide adequate voltage and proper evolution of the fields. At the crowbar times, the SCR is re-fired, again closing the switch and shorting out the resistor. In this case, the crowbar is not fired until .12 seconds for the OH's and .2 seconds for the EF1's, which is well after the end of the startup phase. The EF3 power supply is turned on at -0.05 sec, and is programmed in PCS to provide a large voltage swing around t=0.
Looking at the PCS Main Screen for this shot, we note that Segment 1, "Startup", is in force from -3.5 sec to +0.1 sec, and there are apparently twelve active wires (upper case labels), controlling eleven quantities (ZCUR is associated with both wires 2 and 3, as discussed above). The wavegen reference for wires 5-8 and 9-12 are set to "10" (although in this example wires 5-8 are unused). According to the wire names, the quantities being controlled are
RCUR and ZCUR (on Ip reference)
BR_0
Coil currents IC_OH1, IC_OH2U, IC_EF1U, IC_EF1L, IC_EF2U, IC_EF2L, IC_EF4U
Plasma Current IP. Actually, in this case the gain on wire 16, IP, is zero for t<0.1 sec, i.e., throughout segment 1, so plasma current is not actually being controlled during startup; the button shows upper case because the gain trace at later times has been drawn with non-zero values, which would only be in effect if the second segment were delayed.
Next we examine the waveforms on the ALL_P screen, keeping in mind that only times between -3.5 and +0.1 are meaningful for Segment 1. The right-hand column shows all the power supply waveforms. These call for currents to ramp up to constant levels before t=0, followed by a rapid decrease after that time. As we will see shortly, the gains on these 7 wires drop to zero at t=0, so the feedback will not respect these current waveforms during the commutation interval.
It will be noted that the wire names as given include IC_OH2U and IC_EF4U, but not the corresponding LOWER coils. In fact, the names do not reflect what is actually being done; the display is lying to us! In the case of the OH2 coils, examination of the Observer and Controller screens would reveal that the Observer for "IC_OH2U" has in fact been modified to correspond to the average of the OH2U and OH2L coils, while the Controller has equal weights on the OH2U and OH2L power supplies. In the case of EF4, the coils are physically connected in parallel, and again the Observer has been set up to give the average of the two coil currents. The Controller for this wire is just the EF4 supply, since there is only one. The difference current of the OH2 coils is controlled by the BR_0 and ZCUR wires. Since the EF4 coils are now in parallel, it is not possible to directly control their difference current, which must be bucked out by the other radial field controllers.
The bottom panel in the right-hand column controls the plasma current, which is programmed to rise beginning at t=0. However, as noted, there is actually no feedback gain applied to this wire until Segment 2.
Looking at the left-hand column of the All_p's screen, we see programming for RCUR and ZCUR, which are Ip referenced quantities. The RCUR programming is drawn to start with the plasma centered well inside and move out; this waveform does not begin until t=0. The ZCUR waveform starts at zero, and begins to move down at about 70 msec. These waveforms are active after t=0, when the plasma current is expected to be non-zero. Note that there is a waveform drawn for NL_04, although the gain is set to zero, so no density feedback will be used in this startup. The remaining active waveform in Segment 1 is BR_0, which is set to exactly zero, since we want the startup to be up/down symmetric.
We next consider the gain programming for the startup sequence. The gains are set wire by wire using te EDIT_WIRE screens, but we can get a better idea of the overall scheme by examining the PIDGAINS scope. First we turn our attention to the coil current controls on wires 9-15. Nothing terribly fancy is going on here; the gains turn on in a stairstep fashion to avoid large voltages early in the supply turn-on, when the currents may be far from their targets. Some of these time histories are tuned to avoid problems associated with one coil inductively driving others. Note that for the EF1 coils, some integral gain is turned on for the last 100 msec before t=0, to improve the conformance of these coils to their target values. All of the coil current gains are dropped to zero at t=0 (commutation), although the EF1 gains are brought back up at t=+58 msec. As mentioned earlier, the gain on wire 16, IP, does not rise above zero until after t=0.1 sec, which means this wire has no feedback in Segment 1.
The gain on wire 7, BR_0, rises to a nominal value in a series of steps and stays at that level until after t=0, when it drops by a factor of two, and then drops to zero at +0.06 sec. between t=0 and t=0.06, part of the radial field control is shared with the ZCUR controllers (wires 2 and 3), which takes over completely after 0.06 sec, when there should be plenty of current to feed back on.
The ZCUR programming on this shot is somewhat obscure. If we first look at wire 2 (the so-called "slow" ZCUR) we find that the P and D gains switch on at 34 and 38 msec, respectively, followed by integral gain at +76msec. By 34 msec, we expect to have over 100kA of plasma current, so the ZCUR Observer should be reasonably accurate, and it makes sense to control this quantity rather than BR_0, which nevertheless retains some gain until 60msec. From the PIDGAINS scope it appears that Wire#3, the "fast" ZCUR, is feeding back from t=-0.80 sec. However, the Chopper supply which is the sole element of the fast ZCUR controller does not turn on until, t=+0.045sec, so this gain programming is superfluous.
The RCUR gains turn on quite soon after t=0, and are important in controlling the early current rise. Indeed, we start using RCUR feedback at times when the current is so low it is not clear that the Observer signal is meaningful. We can get a clearer picture of the programming by examining the edit_wire screen. The proportional gain switches on at a moderate level at t=6msec, followed by the derivative gain at 10msec, and a proportional gain step at 40msec. The point of the early P and D gains is to control the rate of rise of the vertical field during the early current rise. The Offset value of 6300 has been determined experimentally to give satisfactory results in startup (for this particular day), not necessarily because it is the correct value for the observer offset. Using the offset value in this manner requires some care to avoid introducing a large jump in the effective target position at the time of segment switch.
There is a significant element of pre-programming, or feed-forward, in the startup scenario, as can be seen from the All_V screen. All of the hybrid outputs are used in this startup segment except for PULSE_GAS1, PULSE_GAS2, and PULSE_GAS5. In general, the power supplies have modest pre-programmed voltages before t=0, reducing the dynamic range required for the feedback to satisfy the IC_xxx target waveforms. Ideally, the V waveforms would correspond to the resistive drop of the coil circuits.
The chopper programming voltage starts at 1000V at large negative times. However, this is misleading. The chopper gets its DC voltage from a TMX supply, which turns on at -.005 sec. The chopper itself turns on 50msec later, so this supply is not actually on until t=0.045 sec. At this point the bias ramps down to zero, allowing the fast ZCUR feedback to control this supply.
The EF3 supply is not energized until t=-0.05 sec. Close examination of the EF3_VOLT waveform shows a small "front porch" programming applied to force a positive voltage demand when the supply turns on. This has been found to give more reproducible response from this supply when the voltage comes on hard at around t=0.
This shot uses hybrid control on the TF current, so the TF_CURRENT waveform is required. In order to get maximum voltage from the TF supply during rampup, the current demand is set to the desired value from the time the supply turns on, rather than drawing a waveform that looks like the actual current pulse. When using hybrid control of the TF, it is important to match the demand values at the segment switch. This is most easily accomplished by pasting the wavrform from one segment to the other.
The active gas valves in this startup segment are PULSE_GAS4 (B-top) and PULSE_GAS3 (K-side). PULSE_GAS4 is used for the pre-puff, which provides the initial fill pressure on which the breakdown takes place. This pre-puff is drawn at about -0.5 sec, and in this instance has a pulse width of 15 msec. PULSE_GAS3 is used for fueling during the shot, in this case starting at t=+25 msec. Early gas puffing can have a substantial effect on the startup. Bringing the gas in too early can choke the current rise and result in a fizzle, while waiting too late can produce a runaway discharge. Some physops like to use early gas puffing to affect the rate of current rise.
If we examine the V traces just after t=0, we see that some of the power supplies have rather complicated waveforms. All of the supplies are programmed for a sharp positive voltage swing around t=0, which is also the nominal time for commutation. For the supplies with solid-state interrupters, the power supply voltage adds to the drop across the commutation resistor. The timing of the voltage swings on the EF2 and EF4 supplies are intended to compensate for the rather slow response of these systems. The strange looking waveforms on the OH1 and OH2 voltages are hand-tuned to try to control the vertical field ramp rate and decay index in order to optimize the current rise.
The startup problem has two parts, breakdown and current rise. In Alcator C-Mod we have found getting breakdown, i.e. a flash indicating a Townsend avalanche process, to be relatively easy. Subsequent current rise, in which equilibrium is maintained as the plasma current increases to the 50kA level and closed flux surfaces form, is somewhat more problematic. In our terminology, a shot without breakdown, on which no visible flash is observed, is called a "dud", while a shot which has a flash but the current does not rise to >50kA is termed a "fizzle".
Diagnosing the null
The first requirement for getting a
breakdown is obtaining a satisfactory poloidal field null. How good a
null is satisfactory depends on vacuum quality as well as the applied
voltage, working gas, and presence or absence of a pre-ionization
source. An example of a satisfactory null (as determined from the
fact that the shot was successful) is shown in this MFLUX
plot for shot 980220004. An acceptable, but by no means perfect
field null is seen in the frames for t=0.002 to .004 sec. Note that
the flux contours are at 1 mWb intervals. The INIT2_SCOPE
display shows light signals beginning at 5.6 msec on the Z-meter,
H-alpha and CII traces, which is consistent with an avalanche time of
about 3 msec. Note that the scope traces for Br0 and Bz0 do not
indicate zero values, but rather values around 10mT and 3mT
respectively; this is typical of the offset errors on these signals,
and is one reason the MFLUX patterns are preferred for analyzing the
quality of the null. Another reason is that the flux plot contains
more information and provides a better guide for improving the null
than do the local time traces. An example of an unsatisfactory null
is seen in the flux plots for shot
980217019, which in fact was a dud. In this case, there is
substantial positive vertical and radial field present at the crucial
early times.
Adjusting the null
Small adjustments to the vertical
field are usually made by tweaking the EF4 current (IC_EF4), which
provides a fairly pure vertical field bias. Typical tweaks are of
order 15amps, which, according to the table of
influence coefficients given in Chapter 3, should result in a
change of Bz of about 1 mT. If the field index also seems
to require tweaking, then IC_OH1 may be adjusted. Note that these
changes in current are usually made for the flattop values up to t=0.
Changes to the dynamic evolution after t=0 are often made by
adjusting the corresponding feed-forward voltages.
Tweaks to the radial field are usually made by adjusting the offset on the BR_0 wire. A typical tweak would be 0.5mT (.0005). Note that the normal startup programming actually specifies the average of IC_OH2U and IC_OH2L, although for historical reasons the wire is called IC_OH2U. The difference current in the OH2 coils is controlled by the BR_0 feedback. The BR_0 controller after t=-0.35 sec also includes the EF2 coils. (These comments are valid for shots in Feb, 1998. The setup of course may change.)
Setting the Breakdown Pressure
The pressure at
breakdown is controlled by adjusting the width of the pre-pulse,
which is normally done from the B-top piezo valve (PULSE_GAS4). The
correct pressure is a function of a number of variables, many of them
unknown. Typical values are in the range of 0.04-.09 mTorr
(calibrated to D2), as read on the Ratiomatic gauge. The
corresponding time settings are roughly in the 15-30 msec pulse width
range. When the cryopump is in use, the width of the fill puff must
be approximately doubled to get to the same pressure.
If the null looks good, but there is still no breakdown, many Physop's will try varying the pressure. This sometimes works. In general, if there is no breakdown at all, going to the higher end of the pressure range is indicated. This will often produce a fizzle, which at least gives something to work with.
Fixing the fizzle
The most common startup problem is
not duds but fizzles, i.e. shots that break down but die before
getting to significant current. There are two principal causes of
fizzles, radiative decay (failure to "burn through") and
bad position control ("threw it away"). Unfortunately, it
is not always obvious which problem is present (maybe both), and even
when the cause is determined the cure is not always straightforward.
We return to the INIT2 scope display for shot 980220004, as an example of what should happen. Note that the breakdown, as seen in the Z-meter, CII, and D-alpha light signals, occurs around t=5.6 msec, while the loop voltage is rising. This is a typical time; breakdowns earlier than 4msec or later than 8msec rarely lead to successful current rises because the pre-programmed field evolution is too far from optimal. Incidentally, it should be noted that there is finite signal on the Ip trace even before the light appears; the rogowski coil links some conducting divertor hardware, and also has a small pickup, such that even a dud shows about 20kA of signal on this trace.
Notice that the light signals all show a peak followed by a decrease (burnout). In cases with a dirty machine, or too much prefill or early gas puff, the light signal may rise and stay high and the current will fizzle. This can also be a sign that the plasma is sitting on the inboard limiter and "choking" on adsorbed gas. The rise on both the CII and D-alpha signals after 30 msec is probably indicative of the plasma riding the inner limiter, but by this time the plasma current is well-established. Also notice the breakdown spike on the CII signal, which peaks at about 0.002 mW/cm2/ster. This level is indicative of a clean machine; dirty conditions often have CII at the 0.01 mW/cm2/ster level or higher.
Returning to the current trace, we note that this shot exhibits a rapid increase with no hesitation, and reaches Ip>100kA by 0.03 sec. This is characteristic of a good startup. The BZ_0 signal, which is derived from a vacuum reconstruction (assuming no plasma current) also rises, though not quite as smoothly. During this phase, the rise of the Bz is not as fast as the current rise; the average plasma position is moving out, and li is dropping.
For currents less than 50-100kA, the absolute values of the traces labeled FLUX RCUR and FLUX ZCUR are suspect, but trends may be more reliable. In the case of shot 980220004, the plasma seems to be moving out, although the early location inside R=.5 may not be real. The initial position claims to be low, but this is probably not reliable. That the plasma is moving out is confirmed by other data. For example, in the Bounce scope the left-hand column shows the ECE grating polychromator signals aranged from the inside out. The outward motion is clear.
A less successful, but still acceptable startup, is shown by the Bounce Scope for shot 980122029, which exhibits several pathologies. The pause in the current rise at a level of 40kA between 12 and 17msec is known as a "hesitation". This effect is usually caused by an incorrect rate of rise of Bz. During the hesitation in this case is a small spike on the visible light signals, probably indicating a "bounce", with the current channel striking a limiter and increasing the recycling momentarily. This shot also exhibits what used to be a relatively rare phenomenon for C-Mod plasmas that has become more common in recent years, a significant runaway population. The early rise in the "Neutrons/Hard X-ray" signal, peaking at 0.15 sec, is due to runaways. Increasing the pre-puff and/or the early PG3 gas puff is often effective in preventing runaways. Another trick that seems to help is to increase the Bz by making IC_EF4 more positive by 10-15 amps. The hesitation can sometimes also be dealt with by increasing the vertical field, either by changing the initial value with IC_EF4 or by adjusting the ramp rate. The latter effect can be accomplished in a number of ways. Tweaking the V_OH1 and V_OH2 feedforward voltages, and/or the EF3 voltage, affects the rate of rise of Bz. Another way is to adjust the RCUR offset in segment 1. In the case of 980122029, an IC_EF4 tweak eliminated the runaways and helped the hesitation. However, later in the run a fizzle that appeared to be too far inside was fixed by undoing the IC_EF4 tweak, with no return of runaways.
As noted, it is commonly concluded that the vertical field rate of rise is too fast or too slow, relative to the current rise. We have touched on the techniques to alter the field ramp rate, namely tweaking the OH voltages and/or the EF3 voltage. The former is more popular. The alternative, of course, is to try to change the current rise rate to match the field rise. Since we do not normally have feedback control over the plasma current in the early startup (or for that matter any time in segment 1), the techniques are indirect. The obvious way to increase (decrease) the current ramp rate is to increase (decrease) the voltage, say by making V_OH1 and the V_OH2's more positive (negative). This also has the effect of reducing (increasing) the rate of rise of Bz, so it is consistent with the former approach. A completely different technique, favored by the Gas-head faction, for slowing the current rise, is to increase the early gas, either by raising the pre-puff or the early PG3.
A common culprit with fizzles is a drift in BR. It is tempting to blame this effect on the fact that the EF4 coils are now in parallel, and therefore subject to unbalanced currents that may vary with coil temperature, but probably only a minority of radial field problems can be accounted for by this effect. Nevertheless, it is important to make sure that the engineers are letting the EF4 coils get completely cold (to LN2 temperature) before each shot. Temperature imbalances, and associated current imbalances, are sometimes seen early in the run day before the cooling is complete. The COMPARE_VOLTS scope (see below) has a trace composed of the difference between the EF4U and EF4L Rogowski signals.
For unknown reasons, the radial field tends to drift during the day, and it is a good idea to keep an eye on it, using either the BR_0 signal on one of the scopes or by monitoring the MFLUX plots. How proactive to be in correcting apparent variations in radial field is a matter of taste. The knob is the offset field on the BR_0 EDIT_WIRE screen; making the offset value more positive makes BR_0 more positive. A typical adjustment is .0005, i.e 0.5mTesla.
Successful startups have been obtained on C-Mod with a large variation in field index. Nevertheless, there is often a strong temptation to tweak up the curvature when simpler fizzle fixes fail. We certainly have observed cases where too negative a field index (vertically unstable) leads to fizzles. An example of a case with quite a negative early index (and not a very good null) that nevertheless had a successful current rise is 950331002, which used a low (-1.3Wb) pre-charge.
Adjusting the index can be accomplished by altering the ratio of OH1 to OH2 currents, either with the current programing or, it dynamic variation is required, by tweaking the voltages. The EF1 coils also provide a substantial handle on the index, without having too much vertical field. It should be noted that the TF toroidal half-turns contribute to the index, in a manner similar to the EF1 coils; therefore, operation with non-standard toroidal field, i.e. not close to 5 Tesla, in principal require compensating changes in the EF1 and/or OH2 currents. In practice, raising the TF usually increases the robustness of the startup sufficiently that no change is required. Startup at reduced field however is sometimes aided by a compensating increase in the EF1 current.
Plasma shape control on C-Mod is primarily based on a flux projection method, employing linear obervers (or estimators) to infer the flux (and field) at points in space, and constructing controllers based on the influence of current in the active coils at (usually) the same points. Actual shape programming is done in terms of shape parameters which are expressed as linear combinations of the fluxes and fields at a set of fiducial points. A typical set of shape parameters and corresponding fiducial points is shown in figure 8.1. The constants of proportionality, which are basically of the form (RBpol/Ip), are taken from an actual equilibrium, which however need not be particularly similar to the equilibrium being controlled. In fact, the default equilibrium used for essentially all C-Mod shots is taken from shot 930817004, a very early 400kA marginally limited plasma. The scheme is described in some detail in [1], and we follow the outline of that paper, with some differences in terminology and notation, in the following discussion. Comparing to the wire names in segment 2 on the PCS Main Screen, we note that Rg corresponds to RCUR, Ci to CLEARIN, rso to strkpsi, etc. The observers for these parameters are calculated by the FLUXIHH algorithm, and the controllers by CONTIHH. The exception is the parameter ZCUR, for which the observer actually corresponds to the current-weighted Z position of a model set of filaments, as calculated by the FILAMENT algorithm, rather than Zg, which is related to the projected flux difference between the top and bottom fiducial points; the controller, however, is calculated in CONTIHH based on this flux difference (ytop-ybot).
The average R and Z positions are clearly fundamental candidates for control, and their definition in terms of either projected flux differences or current moments is fairly intuitive. Gap control is also a basic concept, and on C-Mod is usually implemented for the inner gap, which is referred to in PCS as CLEARIN. Some attention should be paid to the definition of CLEARIN, which is not identical to the intuitive concept of a gap. CLEARIN is defined as proportional to the difference between yin and yxl, where the fluxes are projections to fixed points in space, not to the actual boundary. An important consequence of this definition is that it does not depend on the discharge being bounded by a separatrix passing through the point identified with yxl, and also does not depend on that point being the location of the x-point. The linear construct represented by CLEARIN is well-defined and smoothly varying as the plasma goes from limited to diverted, with negative values corresponding to limited plasmas. It is literally the signed distance between the flux surface passing through the point (Rx0,Zx0) at which yxl is defined and the inner midplane reference point. Since the flux gradient (poloidal field) vanishes near an x-point, if (Rx0,Zx0) is close to an x-point, then that flux surface will be close to the separatrix location at the midplane. Then the controlled parameter will be something very close to the EFIT quantity SEPLIM, which is more amenable to a linear control system than the actual gap OLEFT.
Control of the x-point location depends on higher derivatives of the flux, and is slightly subtle. If we expand the magnetic field (or flux gradient) about a fixed reference point (Rx0,Zx0) in the vicinity of the actual saddle point (Rx,Zx), and solve, we find
|
|
where the determinant is D = (dBR/dR)(dBz/dZ)-(dBR/dZ)(dBz/dR), and all the fields and derivatives are evaluated at the reference point. But BR and Bz can be linearly estimated from the measurements, and the coefficients are pre-calculated constants based on a reference equilibrium.
In some cases it is preferable to control the strike-point position, rather than the x-point position. As in the case of the gaps, the flux value yxl at the reference point (Rx0,Zx0) is taken to be an excellent approximation to the boundary flux, and the difference between that value and the projected fluxes yso and ysi at reference locations on the inner and outer plates must be scaled by the flux gradient to give a distance. If the local flux gradient along the plate is used the result will be a distance along the plate from the reference point. However, if the (outer) midplane flux gradient is used instead the result will give the flux surface mapping of the reference point to the midplane relative to the separatrix. This r coordinate is convenient because it is the normal way of referencing positions in the scrape-off layer.
The flux projection paradigm lends itself particularly to the development of controllers, as it is straightforward to construct coil current combinations (or, with a little more work, voltage demands) which map directly to the flux differences corresponding to the shape parameters. It is also mathematically possible for a given set of shape parameters of rank less than or equal to the number of control coils to construct a set of orthogonal controllers, such that each has a non-zero response in exactly one of the shape parameters. As it turns out, this strategy is perhaps a bit too ambitious, and a less restrictive approach is in fact adopted for the Alcator C-Mod control system.
Leaving aside the EFC coils, which are dedicated to fast vertical position control, there are nine independent coilsets which in principle can independently control nine shape parameters (actually eight shape parameters plus the plasma current). The EF4 coils are located outside the cylinder, and therefore have a rather slow response time in terms of fields at the plasma; therefore, it has been decided to treat these coils separately, leaving only eight independent controls.
If we attempt to construct controllers for the plasma current and seven shape parameters of interest, choosing for example the set RCUR, ZCUR, CLEARIN, and the R and Z coordinates of the upper and lower x-points, we get rather non-intuitive and unsatisfactory results. Forcing the average position controllers to be orthogonal to the x-point location, for example, leads to substantial shape perturbations and requires significant cancellation (bucking) of currents in the EF2 and EF3 coils, for example. While the solution is mathematically correct, it is unlikely to be what we want.
The approach, due to Hutchinson [1], which we have adopted is to establish a hierarchy of controllers, in which some are more orthogonal than others. Specifically, we define a set of three major controllers, IP, RCUR, ZCUR which are constrained to be orthogonal only to each other, and to a parameter called KSYM related to the elongation, as well as to the EF4 current; the IP controller is constructed to control y0, the flux on axis. The flux patterns corresponding to these controllers are intuitive, resembling a field null, a nearly pure vertical field, and a dominant radial field, respectively, and the coil currents are well-behaved. We expect these controller sets to be robust; however, applying these controllers will result in changes in the gaps and x-point locations.
The controllers for the remaining shape parameters are constructed to be orthogonal to each other and to the major controllers. Therefore, they will not fight with the current or position control, although the converse is not true. In practice, this scheme has given satisfactory results on C-Mod, with the feedback providing good control on even the minor controllers provided the gains are sufficiently high. Examples are presented in Reference [1].
Most C-Mod operation over the past few years has been accomplished with feedback control on RCUR, ZCUR, CLEARIN, RXL, ZXL, RXU, ZXU. This vanilla control set suffices for most equilibria of interest, including lower and upper single null and limiter discharges. For some experiments, control of the strikepoints, particularly on the outer plate, is more important than x-point control, and STRKPSI feedback is turned on. The gain programming for these wires has been developed by trial and error over the course of years, and probably could benefit from some review.
With the exception of RCUR, which is specified as an actual major radius, and ZCUR which is referenced to zero (the vessel midplane) each of the standard shape parameters is specified relative to a reference location, as illustrated in Fig. 8.1. The nominal reference points for these are
|
CLEARIN |
0.450 m |
|
RXL |
0.564063 m |
|
ZXL |
-0.393750 m |
|
RXU |
0.564063 m |
|
ZXU |
0.393750 m |
These default values can be modified using keywords to the FLUXIHH and XCONTIHH algorithms. The default reference point for the x-point used by CLEARIN is (.564063,-.39375) and is controlled by the keywords RXA, ZXA.
The combination of CLEARIN and RCUR suffice to determine the outer gap, which is important for RF coupling. While a CLEAROUT wire_name is available, the RCUR/CLEARIN combination seems to work well and is probably more robust. Note that to increase the outer gap by, e.g., +.01m, while leaving the inner gap the same, it is necessary to reduce RCUR by 0.005 m. Conversely, to increase the inner gap CLEARIN by 0.01m without changing the outer gap, it is necessary to increase CLEARIN by 0.01m and simultaneously increase RCUR by .005 m; increasing CLEARIN while leaving RCUR alone will increase both inner and outer gaps by the same amount.
An RF loading signal is provided by the RF group on \HYBRID::HYB_INPUT_NAME_81, and is used to adjust the outer gap to try to maintain a target loading for the antenna during H-mode transitions. This is accomplished by using this input RF_LOAD_E as an element of the RCUR observer, with a typical weight of -1500 (amp-m/ohm); note that the p_to_v_expr for this input is (-10 ohms/volt). The effect is to fool the RCUR observer into putting the plasma where the loading is good instead of where it is programmed to be. It is essential that the signal on this input be checked before modifying the observer in this way, as spurious input signals can drive the plasma into an unpleasant position. The circuit providing the loading feedback signal is supposed to limit the value to prevent large adjustments, but it has been known to fail. It is also a good idea to check whether the RF loading is included in any imported programming.
For standard lower single null discharges, the RXU and ZXU wires are used to control the upper triangularity. This control is somewhat less precise than for the position of the active lower x-point.
Since the set of shape parameters listed contains only seven elements, there is still some freedom in specifying the eight independent coil currents. As pointed out in section A, the controllers by default are set up to be orthogonal to the EF4 current, which is then free to be separately specified. This can be done directly, using a wire assigned to IC_EF4U. The current in EF4 has a subtle influence on the plasma shape, and a substantial influence on the currents which are required in EF2 and EF3 to produce a given shape at a given current. It is often convenient to make use of this fact to provide a feedback signal based on keeping the EF2 currents near the middle of their range, using the EF4 as the controller. This is the function of the EF2_by_EF4 wire, which feeds back, with relatively low gain, on the average of EF2U and EF2L currents.
STRKSPI feedback is used to control the outer strikepoint, at the expense of x-point control. There is also a STRKIN parameter corresponding to the inner strikepoint, although it is used less frequently. These observers are scaled to the midplane distance between the separatrix and the target point on the plates, i.e. the r coordinate. The nominal target point for STRKPSI is (0.62,-0.52) and for STRKIN (.47,-.45). The defaults can be changed using the keywords RSOUT, ZSOUT, RSIN, and ZSIN, respectively. The usual way of setting up strikepoint control to hold the strike fixed is to set (RSOUT,ZSOUT) to the desired location and program a zero waveform. When using STRKPSI control the gains on RXL and/or ZXL must be reduced, since there is not enough freedom in the control system to specify all three quantities independently. Moreover, the controller for STRKPSI is specified using keywords to be orthogonal to the standard shape parameters except for RXL and ZXL.
Upper x-point discharges are run infrequently on C-Mod, because there are fewer diagnostics at the top of the machine and there is no inclined-plate divertor structure, and power loading on the flat-plate geometry is problematic. However some experiments do call for this configuration, and the setup is instructive, and relatively straightforward. Examples may be found in the run of 950322. The main thing to do is to change the reference x-point for all wires that use one (CLEARIN, STRKPSI, etc.) from lower to upper. This is done by setting the keyword ZXA=+0.394, overriding the default value of -0.39375. This must be done for both observers and controllers. Upper x-point discharges are normally run using STRKPSI control in order to prevent the strike point from moving over to hit the gusset; the relevant keywords for the STRKPSI observer and controller are RSOUT=.685,ZSOUT=.600. In addition, the controller call needs to be changed to be orthogonal to RXL and ZXL, but not to RXU and ZXU. The controller keywords are thus: ALL=['PSI0','RCUR','ZCUR','CLEARIN','STRKPSI','RXL','ZXL'], ZXA=.394,RSOUT=.685,ZSOUT=.600 .
Having re-referenced the relevant observers and controllers, it remains to program the target waveforms. Here we assume that the starting point is a normal lower single null plasma. Normally the V feed-forward waveforms will not need to be changed, since these are usually up-down symmetric. The S waveforms for RCUR and CLEARIN will be unchanged (but of course the observer and controller on CLEARIN need to be modified as noted above). The ZCUR waveform can simply be inverted, using the "FLIP" button. The waveforms for upper and lower x-point position are basically swapped, although some adjustment to the lower RXL may be needed to keep the plasma off the lower divertor structure.
C-Mod normally operates with negative plasma current and toroidal field, i.e. both are directed in the clockwise sense when viewed from above the torus. The field and current must be kept parallel; that is if the field is reversed the current must be also. This restriction is imposed because internal hardware near open vertical ports is designed for one sign of helicity, and the D and E port ICRF antennas have slanted faraday shields that also assume fixed helicity. Running reversed (positive) field requires hardware changes, basically a reconfiguration of the TF and PF bus work, and modifications to the HYBRID tree to reflect these changes.
The following notes concern the modifications to the HYBRID tree required to operate with positive TF and plasma current. Basically, the signs of the gains for the power supply outputs get reversed. The grayed-out lines below refer to the original procedure, and are retained here for reference. As of Nov 6, 1999, the HYBRID tree includes two nodes \HYBRID::TOP.CONFIG:PF_POLARITY and \HYBRID::TOP.CONFIG:TF_POLARITY which control the signs of the PF and TF supplies. Changing the value of these nodes from -1. to +1. accomplishes the field reversal requirements of the HYBRID tree.
Change \HYBRID::HYB_OUTPUT_*:GAIN values as follows:
OH1_VOLT: \HYBRID::HYB_OUTPUT_01:GAIN from -.01 to .01 CHOPPER:\HYBRID::HYB_OUTPUT_02:GAIN from -.0025 to .0025 OH2_U_VOLT: \HYBRID::HYB_OUTPUT_03:GAIN from -.04 to .04 OH2_L_VOLT: \HYBRID::HYB_OUTPUT_04:GAIN from -.04 to .04 EF1_U_VOLT: \HYBRID::HYB_OUTPUT_05:GAIN from -.02 to .02 EF1_L_VOLT: \HYBRID::HYB_OUTPUT_06:GAIN from -.02 to .02 EF2_U_VOLT: \HYBRID::HYB_OUTPUT_07:GAIN from -1. / 100. to 1. / 100. EF2_L_VOLT: \HYBRID::HYB_OUTPUT_08:GAIN from -1. / 100. to 1. / 100. EF4_VOLT: \HYBRID::HYB_OUTPUT_09:GAIN from -.01 to .01 EF3_VOLT:\HYBRID::HYB_OUTPUT_11:GAIN from .0025 to-.0025 TF_CURRENT: \HYBRID::HYB_OUTPUT_12:GAIN from -25E-6 to 25E-6
Update \HYBRID::TOP.CONFIG:CONFIG_ID to indicate reversed field setup! This is important.
That takes care of the HYBRID tree. To modify a normal shot in PCS for reverse field operation, something like the following procedure should be followed (these notes are taken from the Logbook entries for Feb 28 1996.)
On invoking PCS for the first run (or doing a LOAD_FROM or IMPORT_SEG) PCS should bring up the configuration warning screen. Read what it says and note all changes since the date of the shot you are loading. You can review this information by pushing the "Show HYBRID Config" button at the bottom of the main screen.
For each segment (it is best to deal with all of them, even the unused ones, to avoid future accidents), bring up the ALL_P and ALL_V screens and use the "FLIP" menu item (on the pop-up menu under the right mouse button) to invert the following waveforms:
ALL_Ps (seg1): IC_OH1,IC_OH2U,IC_EF1U,IC_EF1L,IC_EF2U,IC_EF2L,IC_EF4U,IP note: all of the traces in the right-hand column ALL_Vs (seg1): OH1_VOLT,CHOPPER,OH2U_VOLT,OH2L_VOLT,EF1U_VOLT,EF1L_VOLT, EF2U_VOLT,EF2L_VOLT,EF4_VOLT,EF3_VOLT,TF_CURRENT note: everything but the pulse gas lines. ALL_Ps (seg2-4) EF2_by_EF4,IC_EF4U,IP (and any other IC_* that may be there) ALL_Vs (seg2-4) OH1_VOLT,CHOPPER,OH2U_VOLT,OH2L_VOLT,EF1U_VOLT,EF1L_VOLT, EF2U_VOLT,EF2L_VOLT,EF4_VOLT,EF3_VOLT,TF_CURRENT note: everything but the pulse gas lines, same as for seg1.
Now we're almost done. The remaining issues have to do with offsets and "pseudo-inputs" on Ip-referenced wires.
The only places offsets are used are BR_0 in seg1 and RCUR in all segments. Experience indicates these may need to be adjusted for reverse field operation, but it is not a simple sign change. The right value needs to be determined by trial and error. Br is straightforward: run a shot, note the Br as indicated by the \RECON_VAC:BR_0 signal or MFLUX, and make the appropriate change in the offset to compensate. As usual, to make the radial field more positive, make the offset number more positive.
Dealing with the RCUR offset values is less clear. These numbers have been hand-tweaked for best (?) performance in the various segmments, and will probably have to be tweaked up again, but starting from where they are now isn't unreasonable. The last time we did this, it was found that an offset of 1000. (not 10000.) worked in all segments, so that's another possibility.
The remaining issue is the "pseudo-input" RF_LOAD_E used in RCUR. The sign of the gain on this input needs to be reversed, e.g. from -1500 to 1500. To do this, look in each segment under RCUR, press edit next to each active predictor row (the ones that say "FLUXIHH" under algorithm), and change the sign of the entry under RF_LOAD_E, then ok the edit screen. When you have done this for each row, then ok the EDIT Wire screen, and the factor screen when it pops up.
That's all that should be required, except that the startup will undoubtedly require tweaking. All the usual procedures apply (as well as they ever do). Note that the interpretation of flux plots and scope traces (like PHYS_A_OUT) must take into account the change of sign.
I. H. Hutchinson, et al.,"Plasma Shape Control: A General Approach and its Application to Alcator C-Mod",Fusion Technology, 30, 137 (1996).
S. M. Wolfe, et al.,"Quasi-orthogonal Plasma Shape Control on Alcator C-Mod", Bull. Am. Phys. Soc.,40 (1995).
This chapter describes in some detail the main activities carried out by the Physop in the course of preparing for and executing a run. The emphasis here is on the mechanics, including such nitty-gritty as where the relevant command files are found, the expected formats for documentation and responses from routines, etc. This is the "HOW", "WHEN" and "WHERE" section. In most cases, it is assumed that the reader is familiar with the "WHAT" and "WHY" from the preceding chapters. Examples and sample printouts are included where relevant. The style of these reflects the prejudice of the author, and (in most cases) is not intended to constrain the creativity of the reader.
Run schedules including Session Leader and Physop assignments are normally posted at least a week in advance. Once the assignments are known, the Physics Operator will normally consult with the Session Leader and other interested parties to finalize plans for the experiment. Designing control strategies and setting up PCS models will generally be done (off-line) ahead of time.
With the exception of preparing the Run Plan (Section A), this chapter deals with activities carried out by the Physop on the day of the run. C-Mod runs typically begin at 9:00AM and end at 5:00 PM. The pre-run activities of the Physop will normally take about 30 minutes, and the preparation of the post-run summary (Section G) can take up to an hour. The workstation (presently cmodws50) closest to the power room door, i.e. the station at the left of the front row of desks facing the Big Board, is reserved for the Physics Operator. While the software can be run from any workstation, even one 3000 miles away, the Physop will normally use this location. The adjacent workstation (cmodws48) is reserved for the Session Leader, while the Engineering Operator works at the stations (cmodws35 and cmodws44) located diagonally across from the Physop, on the facing row of desks.
The Physics Operator is responsible for preparing and posting a PhysOp Run Plan to the logbook topic PO_PLAN prior to each run. The Session Leader should also post his plan to the SL_PLAN topic, and the PO_PLAN may refer to this entry concerning the intended shot sequence, etc. The Run Plan should be posted by the end of the preceding work-day, and should include all necessary information for the engineers to set up systems for the run, including requests for discharge cleaning procedure, initial power system settings, auxiliary systems such as cryopumping or RF, and gas system setup, as well as an outline of the proposed shot sequence, with contingencies, if this is not separately detailed in the SL_PLAN. It is the Physop's responsibility to insure that the Plan is available online in time for engineering setup.
A sample annotated Run Plan is shown below. The format is optional, but all essential elements should be included. There is a logbook template available written by Jim Irby, which many people have been using.
Run Plan for Friday, 980220 1 MP166 Density Limits (with pellets) 2 SL: Greenwald 3 PO: Wolfe ECDC overnight in D2. 4 Engineering setup: 5 ------------------ PF Power supplies as on 980217005. TF on hybrid control with current limit 165kA Gas: B-top 6psi D2 Hybrid enabled B-side lower 1psi Ar Hybrid enabled K-side 30psi D2 Hybrid enabled Run Plan 6 -------- Start with a fiducial (e.g. 980217005). The object of the run is to test density limits with pellet injection. We'll try to explore both the L-mode disruptive limit and the H/L transition limit. Given the limitations on power, the H-mode work will probably have to be at 0.6 MA. We could do the L-mode work at .8 or 1.0 MA - the higher value gives us more headroom but bigger disruptions. We should probably start at 0.8 Bt = 5.65 to give us a chance of getting Te profiles. 1. starting with OH plasmas, Ip=.8 MA, ne targets ~ 1.5-2 e20 The pellet size, number and timing will be varied to give a maximum density in quasi-steady state. 2. next turn on RF heating ~ 2.5 MW, Ip= .8 MA, ne targets ~ 1.5-2 e20 The pellet size, number and timing will be varied to give a maximum density in quasi-steady state. We may get intermittent H-modes until the density gets above 3-4 e20 3. As above but at .6 MA, In this case the density limit is down to 4e20 where we can sustain H-modes
The following elements should be present in any Run Plan:
Normally, the Physics Operator works from the Linux workstation (presently cmodws50) on the far left forward-facing desk (Desk#30) in the C-Mod Control Room. The PCS software works on any workstation, so it is not essential that this station be used, but the READY/HOLD button that is interlocked to the State PLC as a permissive to begin a shot cycle is located at this desk. In addition, some of the automatic warning and alarm messages are broadcast to this workstation.
At the beginning of the run day, or when taking over as operator during a run, the Physics Operator must “log in” using the web-based form accessed from the C-Mod Operations menu by selecting “PhysOp Signin”. Alternatively, the form can be reached directly from a browser window using the URL https://www.psfc.mit.edu/research/alcator/program/physops_signon.php
The form includes space for a comment, which is not mandatory, and a starting shot, which at the beginning of the day will normally default to Shot#1 of the current date. Only one Physics Operator may be signed in at a time, so signing in during a run automatically signs out the previous Operator. This is in contrast to the Session Leader job, which can have multiple simultaneous occupants. Normally the user’s name will be filled in when the form appears, and all that is required is to click the [Sign On] button and close the browser tab. If necessary, for instance when taking over briefly from another physop without logging him out of the cmodws50 workstation, the [Select Physics Operator] menu can be used to sign in. Only registered Physics Operators are included on the selection menu.
Once signed on, the brower window or tab can be closed. It is not necessary to sign out at the end of the day.
Use of the PCS software is described in Chapter 6. Actually invoking the code is accomplished by selecting the [PCS] item from the C-Mod Operations menu, or by typing
/usr/local/cmod/codes/pcs/pcs
at the Bash prompt. It is helpful, but not necessary, to have a working directory someplace under your $HOME pointed to by the environment variable pcs_scratch to hold the files during your session, but if this envar is not present then PCS will generate a temporary directory for this purpose. The advantage of having a permanent pcs_scratch directory is that shots can be prepared ahead of time and saved there, then restored using [Load From]. It is necessary for the user to have write access to the PCS and DPCS trees, which requires the Group id hybrid_developers, in order to output to the active tree. Note that the results of a /SAFE session can still be saved using the SAVE_AS button.
Executing the pcs script either from the menu or from the bash prompt as above invokes IDL in the correct environment, and starts the pcs.pro procedure without qualifiers. The [PCS (safe)] menu entry brings the PCS interface up in “Safe” mode, with the [Load] button disabled to prevent accidental overwriting of the live model at a time when you are not the active Physics Operator. Under normal circumstances, only the active Physics Operator should be running an unrestricted (not “Safe”) instance of the PCS software.
When PCS is invoked, with or without the /safe switch, it copies the current PCS_MODEL and DPCS_MODEL files into the working directory, and redefines the environment variables pcs_path and dpcs_path to point to the working directory, and then performs an MdsOpen on the HYBRID tree, which includes \PCS and \DPCS as subtrees. Effectively, this opens the copied model files for modification under the PCS graphical interface. All of the changes made under PCS are carried out on the copy of the model file in the working directory. The modified tree becomes live only when it is copied to alcdata-models::/cmod/trees/models/~t directories by pushing the [Load] button, as described in Chapter 6.
Invoking pcs.pro with the /NOCOPY option assumes a valid model file already exists in the working directory, and no copy operation is performed. If the three files PCS_MODEL.TREE, PCS_MODEL.CHARACTERISTICS, and PCS_MODEL.DATAFILE are not present, an error results. However, the error message is rather obscure, consisting of a mismatch in CONFIG_ID values, and then a complain widget stating that "NO VALID SEGMENTS" were found, and a return to the IDL prompt when the complaint is acknowledged. I’m not sure this behavior still exists, and the /nocopy option is rarely used anymore.
The origin of this obscurity is that the PCS software works by redefining pcs_path and dpcs_path to point to $pcs_scratch , and then opening the HYBRID tree. This open succeeds, since hybrid_path still points to the public area on alcdata-models. The first reference to the PCS subtree is to compare the CONFIG_ID nodes, and this results in a mismatch, since \PCS::TOP:CONFIG_ID is not found. The next operation is to determine how many segments are contained in the PCS subtree, in preparation for drawing the main interface screen; when this query returns 0, the "NO VALID SEGMENTS" message is generated and the procedure then gives up. It should be sufficient to re-invoke PCS, without the /NOCOPY switch, to get fresh copies of pcs_model.* and dpcs_model.* into the working directory.
Once PCS has been invoked, the main action is on the widget interfaces of that procedure. However, some error messages from PCS, and especially from the user-maintained algorithms invoked by PCS, echo to the originating terminal. It is therefore important to keep the xterm (or konsole window or whatever) visible on the screen during a PCS session.
A large number of (hopefully) useful scope files for viewing the inputs, outputs, and intermediate stages of the DPCS computation are found in the directory /usr/local/cmod/codes/dpcs/scopes/. (It is assumed that the reader is familiar with the use of the MDSPlus DW_SCOPE utility. If not, refer to the on-line help or the )MDSPlus documentation. Note that most of these scopes are set up to open the HYBRID tree with a default shot of "CURRENT_SHOT(CMOD)", so they normally track the current shot; to use these scopes for test shots it is only necessary to enter a "0" in the shot number field to pick up the CURRENT_SHOT("HYBRID"), which is usually the most recent hybrid test shot. See Chapter 10 for more on generating test shots.
The principal inputs to the DPCS (the A-inputs) are available in the two scopes named scope_dpcs2_inputs_1-64.dat and scope_dpcs2_inputs_65-128.dat . Note that only the channel numbers are displayed in the title of each panel, and the units are VOLTS at the input of the DPCS digitizers. Alternatively, the scopes scope_dpcs2_phys_inputs_1-64.dat and scope_dpcs2_phys_inputs_65-128.dat present the same data in “physical units” and specify the signal name, as recorded in the \HYBRID::TOP.DPCS_CONFIG.INPUTS nodes in the panel titles. These scopes are useful for troubleshooting and for checking out whether new inputs to the Hybrid are behaving properly. It is not usually necessary to monitor these signals on a routine basis. Similar data, one step further along in the calculation, is displayed in the scopes scope_dpcs_inputs_1.dat and scope_dpcs_inputs_65.dat which show the input signals after baseline subtraction and any other input conditioning applied in the first stage of the realtime loop.
The "feedback error" signals, i.e. the output of the A-matrix, are available in internal units (i.e. Volts) in SCOPE_A_OUT.DAT, and, more usefully, in physical units in PHYS_A_OUT_SEGn.DAT, where "n" represents a segment number from 1 to 4. These signals indicate how closely the plasma is following the programming waveform, and are often useful to the Physop in evaluating the performance of each shot during the run. Note that the "physical units" represented are still those natural to the linearized DPCS system, which means, for example, that the signal labeled RCUR is in fact Ip*R0, with units of amp-meters, not just meters. It is also important to remember that the scale of the signals for times outside the nominal segment are invalid. Trying to interpret the PHYS_A_OUT traces can be somewhat tricky. The signal is "what you asked for minus what you got", but for Ip-scaled quantities the sign of the current has to be considered as well. Thus, a positive signal on the ZCUR trace, with negative (normal) plasma current, implies that the plasma is higher than the programmed value, while a positive value on NL_04 (which is not Ip-referenced) indicates a lower than programmed density.
The programmed target waveforms and "feed-forward" demands to the supplies and gas valves, are available on lowbrid_p_out.dat and lowbrid_v_out.dat, where the “lowbrid” is intended as a humorous(?) contrast to “hybrid”. These scopes and others with similar names were devised during the testing phase of DPCS and the left hand columns, now not used, were intended to compare the output of the hybrid computer hardware with the corresponding DPCS computed values.
The output of the PID gain section, which serves as the input to the Controller (M-matrix) stage, can be viewed in lowbrid_PID_OUT.DAT. The PID gains for the first two segments are available in PIDGAINS.DAT and PIDGAINS2.DAT. These scopes are primarily useful for troubleshooting, although the PIDGAINS scopes can be helpful in identifying times when gain switches take place; note that the PCS interface itself only provides this information on the EDIT_WIRE screens, on a one wire at a time basis. The pidgains scopes are actually not present in the /usr/local/cmod/codes/dpcs/scopes/ directory, but the old versions in /usr/local/cmod/codes/hybrid/scopes/ area should still work, I think.
The outputs of the DPCS, which correspond to the demand signals to the various supplies and gas valves, are available in volts, as digitized in the interface room, in SCOPE_M_OUT.DAT, and in physical units in PHYS_M_OUT_1.DAT. The computed values stored by the dpcs_store procedure, are shown in scope_dpcs2_outputs.dat and scope_dpcs2_phys_outputs.dat. For comparison, the demand signal for each power supply is usually available as an engineering signal digitized at the supply itself, i.e. at the other end of the AFOL line from the interface room to the power room. The PHYS_M_OUT scope is sometimes useful during runs. A related scope is the compare_volts_dpcs.dat scope, which displays the PHYS_M_OUT traces adjacent to actual power supply output voltages, to enable direct evaluation of how well the supplies are following their demands. Lags, saturations, and supply failures can be easily identified in this manner. The corresponding coil currents are also displayed, along with some key plasma traces. If you can’t find the compare_volts_dpcs scope in a public area, there is one in /home/wolfe/scopes/ .
Two useful scopes for diagnosing breakdown and current rise (or lack thereof) are CURRENT_RISE.DAT and INIT2_SCOPE.DAT in the /usr/local/cmod/codes/hybrid/scopes/ directory. There are other versions of these in the private directories of various PhysOps that may be more up to date and/or useful.
In addition to the two-d plasma shape plotting routines mentioned in the next section, some scopes with time traces of various shape and equilibrium parameters are IHHPREDS.DAT, which plots what are essentially MFIL outputs, and SCOPE_EFIT_NEW.DAT, which plots EFIT output quantities.
Ian has produced a family of routines based on his filament reconstruction technique. There is a close relationship between these analysis routines and the FLUXIHH and CONTIHH algorithms for observers and controllers respectively, as well as to the \ANALYSIS::TOP:FLUXIHH nodes in the MDSplus tree. In any case, these routines MFLUX and MFIL turn out to be quite useful for between shot evaluation and tuning.
For either of these codes, or several others derived from them, the recommended procedure is to invoke
IDL> @/home/hutch/mds/mfil_setup.pro
which compiles everything and sets up the environment, and tells you how to proceed (sort of). The routine MSET sets up the parameters. MSET,/HELP tells you what parameters are available and what to do with them. For the lazy user,
IDL> @/home/wolfe/idl/cmod/setup_mflux
loads a standard set of parameters for MFLUX.
MFLUX performs vacuum flux reconstructions, i.e. no plasma model is considered. It is particularly useful for analyzing the null around the nominal breakdown time, and subsequent current rise. Only the flux loop data is considered, since the non-axisymmetry due to the ports, etc., during the relatively high voltage of startup, can cause the Bp loop data to be suspect. Most people find a contour spacing of 0.001 Wb appropriate for this purpose. An example of the null for a successful startup is shown in figure 9.1.
MFIL performs a plasma shape reconstruction, using a standard set of filaments to model the current sources. Both flux loop and Bp coil data is used. This code is equivalent to the MFIT code formerly used at GA. The Grad-Shafranov equation is not solved, i.e no force balance is imposed. However, the plasma shape obtained by MFIL tends to be remarkably close to that generated by EFIT, which does a full equilibrium solution. Moreover, MFIL can be run much faster than EFIT, which takes several minutes after the shot to complete.
A number of automatic alarms and warning messages have been set up to alert the Physics Operator of potentially dangerous occurrences. These are normally in the form of a broadcast to the active terminals on the normal Physop workstation (presently cmodws50) . These normally come through after the pulse, as a result of STORE or ANALYSIS actions. It is important that the Physics Operator pay attention to beeping on his terminal, as most of these messages do call for some operator action or response. The currently active alarms which may be broadcast to the Physics Operator are listed below. More may be added as new systems and tests are brought online.
Failures of the magnetics signals are detected by a routine which runs immediately after the relevant data is acquired. Tests are performed to try to identify shorted or open diagnostics, as well as integrator failures (baseline drift) and CAMAC glitches. Only signals expected to be valid are tested, so no alarms are generated by diagnostics which are known to be bad. In addition to the online warnings, off-normal events are logged to a database. The testing algorithm is fairly robust, although it can be fooled by low-level power system tests, which may give spurious "no signal" faults, and by crowbars, which can give "baseline offset" errors. If you don't know that a fault report is spurious, it should be checked, especially if the diagnostic signal identified is used as an input to the Hybrid. Note that if the failure is in the cPCI digitization of the MAGNETICS data, there will be no effect on the control system, which has its own inputs, but reconstructions based on the faulty signals may be incorrect. If a DPCS input signal is in fact failing, it will usually be necessary to take corrective action. If the signal is not reparable, then a substitute may be connected, or use of the signal discontinued. Either case will constitute a change in the Hybrid Configuration and probably a modification to the observers or even to the underlying algorithm. The magnetics, and the check_magnetics routine, are the responsibility of Bob Granetz.
Halo currents in the divertor and gusset structures are measured and monitored. Because the forces associated with these currents can cause damage to the divertor and first wall, a hierarchy of alarm levels has been established. At the Warning level, the operator is alerted, and if possible should take steps to ameliorate the halo severity (under the ALARA principle), but is not required to change course. At the STRIKE level, a limit of five disruptions meeting this criterion are allowed during a single run; the operator should try to avoid further occurrences and must absolutely change to another program or stop the run after the fifth strike (they should be called fouls?). At the OUT level, the most severe category, the danger of damage to the machine has been judged to be unacceptable. The Physics Operator must stop the course of action that resulted in the disruption; if the operator can find no way to carry out the program without incurring further high-halo disruptions then the program must be abandoned. There is probably no truth to the rumor that on an "OUT" or fifth "STRIKE" the trap door opens and drops the Physop into the basement dungeon, but why risk it? The halo current monitoring program is the responsibility of Jim Irby.
In the past, Alcator C-Mod has experienced a failure in the coaxial bus feeding one of the OH coils. This coax connects to the coil via a feltmetal joint, which degraded, overheated, and eventually caused a catastrophic arc. The resistance of all three coax joints is now monitored, and an alarm alerts the operator if that resistance goes outside of nominal limits. The alarm is also entered in the logbook under the power_systems topic. This alarm is the responsibility of Jim Irby. One of the functions of the dpcs_fizzle asynchronous procedure is to cause the OH currents to complete a controlled double-swing while the TF current is kept on, in order to prevent the JxB forces on the coaxes from causing an imbalance in the compression at the coax joint. If this routine is in use and is behaving as intended, it is unclear that there is much more the Physics Operator can do about this alarm except worry, and stop the run if the top-level limit is exceeded.
The administratively-allowed current limits are supposed to prevent combinations of PF coil currents which would cause stresses in any coil to exceed allowables. However, under some circumstances inductively driven currents may cause these stress allowables to be approached. An analysis program running after the shot notifies the Physics Operator if the calculated stress in any coil exceeds one of three pre-set fractions of the allowable value. This alarm is maintained by Steve Wolfe. Operation that unduly stresses the coil system should be avoided.
Note that a hardware interlock based on calculation of the tension stress on the top and bottom of the OH stack, which was not considered in the original coil stress calculation, was implemented in 2008 by Dave Gwinn and Willy Burke. This interlock causes a Type 2 fault condition that terminates the shot when the calculated force exceeds the pre-load of the stack. The message that appears on the PLC screen may still refer to this fault as originating from DPCS, which is not correct. (There was a brief interval when a dpcs_type2_fault procedure was employed as a stop-gap measure before the stand-alone hardware solution could be produced, but that has long since been disabled and the fiber link that carried it is no longer connected.) In any case, there is a scope in /usr/local/cmod/codes/engineering/scopes/scope_oh2_force.dat that shows the output of the interlock circuit and the corresponding calculation based on independently digitized data. When this circuit is activated (other than because of a malfunction) it is usually because the shot program is causing the EF1’s and OH2’s to go to too large a negative current while the OH1 goes toward zero during the current rise; this can occur if an attempt is being made to get early X-point formation. If this is the case, it is necessary to change the shot programming to avoid putting the stack in tension. Sometimes this can be accomplished by changing the timing of the diversion slightly.
Each coil is provided with a set of metal-oxide varistors (MOV) which conduct if the coil voltage exceeds nominal levels. The current in these varistors is monitored, and an alarm is broadcast if significant current is observed. This alarm is maintained by Jim Irby.
The Physop will normally keep a detailed shot-by-shot log during the course of a run. The PHYSICS_OPERATOR topic of the Electronic Logbook table is set up for this purpose. Most physops prefer the web-based interface to the logbook, https://www.psfc.mit.edu/research/alcator/logbook.php but the older IDL-based version can still be accessed by typing logbook (or /usr/local/mdsplus/bin/logbook if your PATH does not include this directory) or by typing entry_display at the IDL prompt.
This IDL application provides automatically updating display of logbook entries for selected topics during the run, and a screen for making and editing new entries. Existing entries made by the user can be conveniently selected, and modified or voided. The editing features are basic, but serviceable for the short entries typical of the shot logs. The menus include a range of selection and display options.
Some Physops prefer to keep notes in a text editor. One advantage of using a regular text editor is that a running account can be maintained in a single file, which can then be incorporated into the Physop's Summary at the end of the day.
While making timely comments in the online Logbook is encouraged, and can be helpful to others trying to follow the progress of the run, it is not a requirement for the Physics Operator. The Physop is required, however, to submit a run summary under the PO_SUMMARY logbook topic at the end of the day. These summaries, along with the ones written by the Session Leader, become part of the permanent record of the experiment. They are available on-line and over the Web, through the cmod_runs page. It is especially important that the PO_SUMMARY be prepared and posted prior to the next run, so that the next Physop has an up-to-date record of how the machine is performing and of any special precautions indicated.
A typical run summary will include a synopsis of the results of the run, and a catalog of any operational problems encountered and their solutions. A shot-by-shot summary is not necessary, especially if there are logbook entries, but can be helpful to someone trying to identify noteworthy shots.
No routine maintenance schedule has been established for the DPCS Computer, or associated hardware.
The major hardware components of the Digital Plasma Control System consist of :
the host computer, pcdaqdpcs3
a single cPCI crate containing
PCI bus extender connected to the host
Two DT196 digitizers used for real-time operation
One DT196 digitizer used as transient recorder for recording outputs
One INCAA DI02 “Decoder/Timer” Module
Two Eurocard crates containing AFOL Receivers for DPCS Input signals
One Eurocard crate containing AFOL Transmitters for DPCS Output Signals
Three Patch Panels for interconnection of 37-pin D, Lemo, and SCSI connectors to and from DPCS
In addition to the above components, the DPCS Rack Enclosure also includes a complete spare/development system duplicating all of the above components (except the AFOL transmitters), a Eurocard crate containing AFOL transmitters for the “Live Scope” in the C-Mod Control Room and DFOL output for the Hardware Fizzle Detector, two Ethernet switches (one for PSFC public network, one for private networks on each of the two DPCS hosts), a KVM monitor, an Ethernet AC power switch ALCPWR16,two DC power supplies for the AFOL racks, and an AC local service power strip. The rack layout and interconnections are given here.
The host computer can be rebooted and/or power cycled without power cycling the cPCI crate. If it is necessary to power cycle the cPCI crate, a reboot of the host computer after powering the crate back up will probably be required.
It is important to note that the DI02 in the main DPCS cPCI crate also provides the gate for the Hardware Fizzle Detector. If it is necessary to disable this crate, that functionality as well as the DPCS operation may need to be transferred to the spare/development system.
The DPCS software process /usr/local/cmod/codes/dpcs/dpcs3 is included in inittab of the DPCS host computer pcdaqdpcs3 with the respawn attribute, so it should always be running while the host computer is up. Formerly, the process was restarted by a cron script every morning, and the startup messages appeared in the log file (see below), but this is no longer the case. It would probably be a good idea to re-institute this procedure, but no problems have been noticed due to letting the process continue to run uninterrupted for long periods of time. The only known issue is that when changes or additions are made to the software, it is necessary to restart the process to insure that the most recent versions are compiled and run.
Regular test shots, as described below, with examination of the log file /usr/local/cmod/logs/pcdaqdpcs3-dpcs.log and data, are a good idea during off-run periods, as a check on both software and hardware.
A test procedure for exercising the full system (hardware and software) is available in /usr/local/cmod/codes/dpcs/test_init_dpcs2.pro . This IDL procedure takes a single argument, the test shot number, and can be run from any C-Mod workstation; it should not be run directly on pcdaqdpcs3. The procedure sets current_shot(‘hybrid’) to this shot number and exercises the full DPCS system through a shot sequence. Typical mesages echoed to the user terminal are as follows:
IDL> test_init_dpcs2,1091106101
% Compiled module: TEST_INIT_DPCS2.
% Compiled module: MDSTCL.
% Compiled module: MDSVALUE.
% Compiled module: MDSCHECKARG.
% Compiled module: MDSISCLIENT.
% Compiled module: MDSIDLIMAGE.
> set verify
> set current hybrid 1091106101
% Compiled module: MDSOPEN.
> create pulse 0
% Compiled module: MDSCLOSE.
> create pulse 1091106101
> dispatch \HYBRID::TOP.HARDWARE.DPCS:DIO2:INIT_ACTION
> dispatch \HYBRID::TOP.HARDWARE.DPCS.DIAG_HW:DT196_1:INIT_ACTION
> dispatch \HYBRID::TOP.HARDWARE.DPCS:DPCS2:INIT_ACTION
> dispatch/nowait \HYBRID::TOP.HARDWARE.DPCS:DPCS2:RT_ACTION
> do /meth \HYBRID::TOP.HARDWARE.CAMAC:MIT_ENCODER set_event /arg="""HYBRID_START"""
> dispatch \HYBRID::TOP.HARDWARE.DPCS:DPCS2:STORE_ACTION
> dispatch \HYBRID::TOP.HARDWARE.DPCS.DIAG_HW:DT196_1:STORE_ACTION
% Compiled module: MDSSETEVENT.
Messages are echoed to the logfile /usr/local/cmod/logs/pcdaqdpcs3-dpcs.log as on a normal C-Mod shot. Outputs and intermediate values can be seem on the usual DPCS and Hybrid scopes; the scopes will track the test shot number and update automatically if a shot number of "0" is loaded in the shot field. The SCOPE_M_OUT or PHYS_M_OUT1 scopes are useful monitors of the overall performance.
Note that in the absence of input level on the Ip sensor, as on a test shot, the software fizzle detector will be activated at the beginning of the fizzle gate, normally 0.08sec. This is usually acceptable for testing purposes. If for some reason it is desired to disable the fizzle detector function, for instance in order to evaluate the system latency or timing issues over a full shot length or for testing of another procedure, then the dpcs_fizzle procedure can be disabled, or else the threshold parameter can be set to 0.
For software testing, an environment for running the DPCS software using input signals derived from actual shot data is available by executing the shell script /usr/local/cmod/codes/dpcs/test_dpcs2_software.sh. This script can be run on any workstation, or even on the DPCS host computer (though not during operation); it runs the DPCS software on the local CPU without accessing the hardware (digitizers, transmitters, ...) or using the special memory and interrupt functions. After setting appropriate paths and environment variables, the script starts an IDL session which prompts for a test shot number, a source shot for input data, and a model from which to construct the test pulse. The model could be either the live HYBRID model or a specially prepared shot created using PCS using the SAVE_AS operation. The IDL script then allows the user to step through the shot sequence, or to PAUSE and enter interactive commands to query variables in common, set breakpoints, or otherwise debug the sequence. This script is extremely useful for testing and debugging new software, and may also be helpful in troubleshooting unexpected behavior. The major drawback is that the inputs are taken from existing data and do not depend on the demands provided by the software under test, so no evaluation of feedback is possible. For a full simulation including model plasma response, it is necessary to use the Alcasim plasma simulator, accessible from the [Simulate] button on the main PCS screen.
From time to time, it will be necessary to modify the hybrid configuration, to replace or add new inputs, to accommodate new output signals, or to reflect changes to the hybrid itself. This operation should normally be handled by an experienced user. In addition to modifying the contents of the relevant HYBRID nodes, it is also essential that any configuration changes which may impact PCS results be entered in the \HYBRID::TOP.CONFIG:CONFIG_ID node; required information includes the date, name of the individual making the change, a brief description of the modification and its impact, and procedure for taking account of the new configuration vis a vis old PCS files. Note that this text node contains a STRING ARRAY; the new information should be appended to the end of the existing array. In addition, any modifications to the HYBRID should be described in appropriate detail in the HYBRID or DPCS topic of the online LOGBOOK.
When adding a new class of input to the Hybrid Input set, the relevant nodes under the \HYBRID::HYB_INPUT_NAME_%% should be filled in. Note that the "calibration" of the input is normally obtained by evaluation of the \HYBRID::HYB_INPUT_NAME_%%:P_TO_V_EXPR node. While a numeric value can be simply typed in to this node, the preferred option is to determine this value by reference to the appropriate data in the CMOD subtree that logically contains the new diagnostic, using a routine that performs the calculation given the NAME and STRUCTURE information. Such subroutines should be added to the GET_INPUT_P_TO_V module in the HYBEXE sharable image. See the comments in the header of this Fortran routine for details.
This section consists of a rather disorganized recounting of things that have gone wrong in the past, and why, and how we fixed them. Problems with the DPCS have been infrequent, but when they occur they stop the run cold, and have sometimes been extremely difficult to track down. We have also experienced a certain number of unexplained one-time glitches. Given the severity of the consequences of failure in the power system control, it is always advisable to err on the side of too much testing and verification once an off-normal event has occurred.
There are several INIT actions which have been labeled as “Critical”, such that if the DISPATCHER sees an error on one of these the State PLC gets an Alarm condition and a message that informs the State Operator that a critical error has ocurred and a NO POWER shot should be taken. Unfortunately it is not always easy for the Engineering Operator to identify which of the errors appearing on the Action Monitor is “Critical” and whether it is really necessary to abandon the shot. Sometimes an error in INIT is generated because a subsystem that is not actually being used, such as the ICRF, has been left enabled in the tree, but is physically offline, in which case the error could be safely ignored and the shot continued. Usually, however, a critical failure really is critical and the EO will normally take the Warning at face value and take a no-power shot cycle, leaving the diagnosis to after the cycle. Here, we are mostly concerned with INIT failures associated with DPCS which will normally show up as actions in the HYBRID tree. A listing of the Critical errors for a given shot can be obtained by typing
cmod_errors -e <shotnumber>
at the bash prompt; the “-e” option means essential. If the shotnumber is omitted the errors on the current_shot(‘cmod’) will be returned, but since the current shot number may not advance until after completion of INIT the number should be specified if you’re trying to look at what’s going on between INIT and CHECK. The actions associated with DPCS are \HYBRID::TOP.HARDWARE.DPCS:DIO2:INIT_ACTION which is the timing module used both for the DPCS and the hardware fizzle detector, and \HYBRID::TOP.HARDWARE.DPCS:DPCS2:INIT_ACTION which invokes the dpcs_init procedure that sets up the control system.
An INIT failure on the DI02 is likely to be a hardware problem, and may indicate that the server pcdaqdpcs3 is offline or that its mdsip server is not functioning correctly. We have not experienced any actual hardware failures of this module, or of the cPCI crate or SBS PCI bus-extender module, but any of these is possible. Fortunately, we have spares of each of these units in the development system.
An INIT failure on the DPCS2 “device” is most probably a software issue or indicative of a problem with the server being offline (or possibly powered down), but could be hardware. We have experienced failures due to a spontaneous reboot of the server pcdaqdpcs3 resulting from (possibly spurious) network glitches. The “feature” responsible for these events has been disabled.
Trouble shooting any of these situations begins with trying to determine the state of the systems involved. The first thing to check is probably whether the host is up and running, which can be checked by pinging pcdaqdpcs3. If the host is not responding, you’ve found the immediate problem. It may well be possible to restart the computer remotely, either by accessing the rac processor (requires root password) or by cycling the appropriate outlet on the ethernet AC power switch Alcpwr16. If all else fails, you can always go into the interface room and push the button.
On at least two occasions a glitch on the power room UPS system has caused the ethernet power switch in the interface room to turn off all the outlets and not turn them back on, so if a UPS problem occurs, which will usually result in a warning message on one of the PLC screens at the front of the room, it is probably a good idea to check on the DPCS, perhaps even running a test shot, before taking a C-MOd shot.
If the host is up and running, or at least pingable, the next place to look in the case of an INIT failure on the DPCS2:INIT_ACTION is probably the logfile /usr/local/cmod/logs/pcdaqdpcs3-dpcs.log . The messages associated with each dpcs_init call should be present, identified by shot number and including timestamps and error state on exit.
Some Warning level error messages from loadable procedure modules, such as
Procedure path set to
\HYBRID::TOP.HARDWARE.DPCS.LOADABLES.PROCEDURES:INPUT_PROS:PROCEDURE_01
% DPCS_GET_PROC_PARAMS: BASELINE_SUB: Node outputs not found or has no data
Procedure path set to
\HYBRID::TOP.HARDWARE.DPCS.LOADABLES.PROCEDURES:ASYNC_PROS:PROCEDURE_01
% DPCS_GET_PROC_PARAMS: DPCS_FIZZLE: Node parameters not found or has no data
** Structure !ERROR_STATE, 8 tags, length=84, data length=84:
NAME STRING 'IDL_M_USER_ERR'
BLOCK STRING 'IDL_MBLK_CORE'
CODE LONG -5
SYS_CODE LONG Array[2]
SYS_CODE_TYPE STRING ''
MSG STRING 'MDSVALUE: %TREE-E-TreeNODATA, No data available for this node'
SYS_MSG STRING ''
MSG_PREFIX STRING '% '
are normal, but successful completion of the dpcs_init procedure should be indicated with lines similar to:
8.4787750 seconds in dpcs_init
Finished DPCS_INIT Fri Nov 6 11:41:13 2009
Fri Nov 6 11:41:13 2009, INFO: ************* No errors detected, action status success *************************
If the dpcs_init messages are completely absent, it may be time to check more carefully on the processes running on the host. Ssh to pcdaqdpcs3 (assuming you have already verified that it is pingable), and check for the presence of the dpcs process:
wolfe@pcdaqdpcs3 ~$ ps -Uroot f | grep dpcs
11417 ? S 0:00 \_ su mdsplus -c ulimit -c 1000000; /usr/local/mdsplus/bin/mdsip -p mdsip_analysis -s -h /usr/local/cmod/etc/mdsip_server.hosts >> /usr/local/cmod/logs/mdsip_servers/pcdaqdpcs3.psfc.mit.edu:mdsip_analysis 2>&1
5691 ? Ss 0:00 /bin/bash /usr/local/cmod/codes/dpcs/dpcs3
7009 ? SNLl 278:54 \_ /usr/local/itt/idl70/bin/bin.linux.x86/idl /usr/local/cmod/idl/dpcs2/dpcs2.pro
The first process listed is the mdsip_analysis server, and the next two are the the dpcs parent script and the IDL process that actually runs the control system. Since both the mdsip server and the dpcs3 script are supposed to respawn if they die or are stopped, it is unlikely that these will be missing unless there is a system problem. If the IDL process appears to be hung up or failing, it may be possible to recover by invoking the shell script /usr/local/cmod/codes/dpcs/dpcs_restart ; otherwise, a reboot may do the trick.
It has happened at least once that one or more of the cPCI digitizer cards stops communicating with the host. In this case, it was necessary to power cycle the cPCI crate and then reboot pcdaqdpcs3.
Incorrect power supply response
It is sometimes found that the power supplies appear to be
running amok, or at least not putting out the expected waveform. The
first thing to check is that they are actually receiving the correct
demand signal from the hybrid. Each supply has CAMAC digitizing the
input signal from the AFOL at the supply. It is worthwhile checking
this signal, even when the M-out signal digitized at the hybrid looks
good. We have had cases of AFOL failures such that a hybrid output
was not properly received. We have also had one instance of a loose
output cable at the AFOL rack causing bad signals to be received at
the supplies.
The most frequent cause of improper power supply response is that the feedback in the power supply voltage regulation is itself broken. This is a power systems problem, not a hybrid problem, but it is often difficult to convince the power systems people of this. We have had such problems in many PF supplies. Some have been sufficiently subtle that only careful comparison of the demand and actual outputs reveals the problem. EF1L and OH2L have been common offenders, with the symptom being a significant offset in the actual output voltage from the supply. We have also had problems with RF pickup in the power supply cabinets causing incorrect response. In the case of the EF2 TMX supplies, this has happened more than once, and is usually fixed by reclosing the doors on the supply cabinet. There has been a persistent pickup issue involving the J3 transmitter and the EF1U power supply shunt signal; as of this writing this problem has not been resolved.
Note that in some cases, failure of the supply to follow its demand signal is a consequence of lags in the supply, or of reaching a current or voltage limit. These effects are not really failures, but do require attention. If a supply is being driven to its rail, and therefore not responding to demand signals, control will be lost. A change in either the control scheme or the operating point is indicated.
Incorrect signals at Hybrid
If the signals at the
output of the DPCS look wrong, it is time to start looking at
intermediate signals. The scopes in
/user/local/cmod/codes/dpcs/scopes/ are useful in this context;
running test shots with hardware in the loop
(/usr/local/cmod/codes/dpcs/test_init_dpcs2.pro)
or with only software running against old data
(/usr/local/cmod/codes/dpcs/test_dpcs2_software.sh)
is recommended over using the tokamak cycle as the world's most
expensive waveform generator.
Several of the unused AFOL receivers in Ch 97-128 have excessive drift (of the order of Volts). The problem was previously diagnosed to be due to bad solder joints on some on-board header assembly, but not all have been satisfactorily repaired. This should be dealt with during the next extended maintenance period, or at least before we need these channels.
One of the fans in the DPCS cPCI crate is broken. This has been reported (Tech Request #14280) but requires the system to be shut down and the modules removed from the crate for repair, so it has been deferred. If the crate should fail, this may be the cause. Also, open slots on this and also the development cPCI crate should be closed off with blank panels (now available in electronics shot).
Figures referenced in this document can be found here.
This Chapter is largely drawn from documentation prepared by Steve Horne. More documentation authored and/or collected by him are listed in the Reference section at the end of the chapter.
This chapter is obsolete! The Hybrid is no longer in use. The former Chapter 5 is retained here as an appendix for reference and historical reasons.
The Hybrid Computer provides real-time control of Alcator C-Mod subsystems, principally magnet power supplies and pulsed gas fueling, during a plasma pulse. Both open-loop and feedback control of multiple parameters (up to sixteen at a time) are available. The control scheme is inherently linear, in the sense that the controllable parameters are linear combinations of real-time input signals and the output demands are composed of linear combinations of (PID) amplified error signals and pre-programmed waveforms.
The control system includes the following components: A,PID,M,SPARE matrix multiplier modules (A is made up of two crates, PID,M, and SPARE are each 1/3 of the bottom crate) Waveform generator (wavegen) RT-node, complete with digital and analog inputs and independent private bus cards.
The system is capable of storing at least 400 matrices and switching between them in less than 2 msecs. Input and output levels are limited to +/-10 Volts. Nominal bandwidth is DC to 20kHz. Digital resolution is 12 bits.
The linear transformation performed by the control system may be thought if as consisting of three matrix multiplications and two vector additions. It is convenient to refer to an identification of the first matrix (called A) as an observer which maps the (up to 96) inputs onto sixteen observers (also called predictors or estimators) which constitute a linear approximation to parameters whose behavior is to be specified. This 16-vector is then differenced with the target P waveforms, and the resulting error vector is multiplied by a PID gain stage (which can be considered as a complex diagonal matrix) to produce the feedback signals. The final matrix multiplication, referred to as the M-matrix, applies the controllers to transform the 16 feedback signals into 16 demand signals which, after combining with the feed-forward V programming waveforms, are fed to the power supplies, etc.
The matrices are themselves built up of 4 x 16 (16 input, 4 output) multiplier cards, also referred to as DAC cards. A 16x16 module is built up of 4 cards, plus a summer card. This collection is packaged into 1/3 of a crate, with 37-pin D "JET Norm" connectors.
The A matrix (16x96) consists of 6 of these modules.
The M matrix is a single 16X16 module.
The PID is a single DAC card, plus a "piggyback" card, and a summer.
The Wavegen is a 32-channel waveform generator. A detailed description (translated from the French into a language resembling English) is to be found in user9:[horne.hybrid_docs]wavegen.tex. The original French version is also available, complete with figures and some schematics, from either Tom Fredian or Joe Bosco.
Like the matrix modules, the wavegen is based on the use of DAC cards to control an analog signal based on digital input values. It contains, among other components, a DAC card with a "large" memory (the matrix cards use "small" memories).
Each signal is defined by a set of data points and a set of time intervals, loaded as digital values. Two linear ramp signals are generated and combined to produce a linear interpolation between a pair of input values. The output of each channel of the wavegen between times t0 and t1, where the end-point values are P0 and P1, is thus
OUT(t)= (P1-P0)*(t-t0) + P0 , for t0 < t < t1
The 32 channels are divided into two sets of 16 each, referred to as the P and V waveforms. The references are set on the GENTRI board using two push-on jumpers per each group of four channels (i.e. 8 sets of jumpers for all 32 channels). Two of these groups, representing channels 5-8 and 9-12 of the P's, have been modified to use analog switches instead of jumpers, enabling the reference choice to be changed in real time.
Analog signals from the cell and power room are brought into the interface room via optoisolators. There is a rack of 64 channels of optoisolators in the cell next to the magnetics rack, connected to it by 4 37-conductor ribbon cables. The output are brought to the interface room by shielded twisted pair cables terminated in 37-pin D connectors at both ends. These are connected via ribbons to the inputs of the first 4 A modules, inputs 1-64.
In addition, the Bus Rogowski signals are brought into the interface room via AFOLs. The transmitters are located in the Buss Diagnostics rack (see Jim Irby). The receivers are located in a single-width Eurocard rack with a custom backplane (see Rick Murray). The signals are brought via ribbon to the 5'th A-matrix module (inputs 65-80). A ribbon "tees" off from this ribbon and connects to the patch panel. The LEMO cables from this patch panel connect to AFOL transmitters which drive the storage scopes in the control room.
A similar chassis is connected to the A6 submatrix (inputs 81-96). This system is designed to accommodate 8 optical channels, plus 7 LEMO inputs. Hybrid input 96 is hard-wired to a one-volt reference supply, and is assigned to the name "minus-one-volt"; this input is used to tweak offsets and provide a DC term in observers.
The 96 A-matrix inputs
The PID input (A output)
The M input (PID output)
The M output
The Wavegen V
the Wavegen P (or S)
A set of digital matrices are loaded into the DAC cards during the INIT cycle. The switching of matrices during the shot is controlled by the RT-node. Originally, the timing was handled by the Jorway. In this configuration, the Jorway is loaded with the times at which each switch is to occur, and the RT-node gets the matrix addresses. During the shot, whenever the Jorway emits a pulse, the RT-node interrupt routine loads the next set of addresses onto its so-called "Private Bus" cards. Their outputs are distributed to the various matrices via ribbon cables.
As of 1995 the RT-node takes care of its own timing. Since this is done by counting down a clock from the decoder, the internal timing will still be synchronized to the experiment clock. Reversion to Jorway timing requires moving a cable on the PIO panel in the interface room.
Jorway chan 5 is set with a gate from (tstart + 1 microsec) to +10 sec. While Start Trigger is held low, internal clock will stop. The 10 sec gate should be longer than any shot.
As the RT-Node goes through a shot, it will store internally the time that each matrix switch occurs (with half-msec resolution). This allows reconstructing the sequence of switches after the shot -- especially important if the adaptive control takes over. The table is uploaded and saved to the tree after the shot.
The loading of the matrices is handled by the Hybrid Loader. This image manages the contents of the hybrid DAC cards -- all matrices, and the wavegen. The loader tries to minimize the bitbus I/O, since this I/O is slow and expensive. A map of the hybrid memory is kept in Vax memory. The loader software compares the contents of the tree for a given shot, with the current contents of the map and updates the hybrid hardware and vax image to match the tree.
The Intel 8044 CPU in the RT-node drives each of the matrix multipliers through it's private bus (PB). There are three independent PB drivers, one for each matrix multiplier (A,PID,M). Two bytes are written sequentially to the private bus to define an address. The matrix switch occurs after the second (low) byte is written to the private bus. The multiplier cards for a particular matrix (A, PID, or M) are all driven in parallel by the private bus; at any given time, all cards in a given matrix load the contents of the same address in their local memory, to their DACs.
The RT-node program provides for two basic phases, LOADING and OPERATION. Loading: After the address at which matrices are stored have been determined by the MDS Matrix Loader (see below) the table(s) of matrix addresses are loaded into the 8044 RAM. The RT-node program responds to an inquiry from the MDS Matrix Loader by returning the address at which the table is to be loaded. After the matrix contents are loaded into the multiplier memory, the addresses are loaded and verified by an IDL procedure via the RAC task. Operation: The software maintains a pointer into the current table, which is initially the SEQUENCE table. On every rising edge of the NEXT MATRIX input, the next address in the current table is expressed on the private bus.
The VAX communicates with these cards via the bitbus. This is a serial communications system which is composed of a master node (node 0) and a collection of slave nodes. These nodes communicate via messages. Only the master node may originate a message -- the slaves may only reply to messages from the master. In our system, the master node is the IBQ card, installed in SHAPE. Each DAC card is a slave node.
The bitbus itself consists of the following components:
IBQ card, part of SHAPE -- node zero.
Ribbon cable from SHAPE to the copper/glass interface module, in the control room.
Two glass fibers from the control room to the interface room
The glass/copper interface in the interface room
The daisy-chain of ribbon cables running from the glass/copper interface to the various matrices
A 12-volt power supply which terminates the cable and provides power for
The internal optoisolated bitbus repeaters built into the three multiplier crates.
The BCS shareable image performs the low-level actions required to manage the bitbus. Access to the RAC tasks and the on-chip software is through this task. (The RAC task and the on-chip software are documented by INTEL.) Calls to this task may be initiated via MDS actions, which may be synchronized via events. This capability gives MDS complete access to the entire bitbus environment. We have a BCS manual. For a quick go/no test of the hybrid, log onto SHAPE and do the following:
$ mcr ibq$bcs BCS Version 2.0 Copyright (C), 1987, 1988 Digital Equipment Corporation BCS>search Bitbus Addresses Device Code (16): 99, Version Number (16): 1 Node List (10): 0 5 6 7 8 9 10 11 16 17 18 19 24 25 26 27 32 33 34 35 40 41 42 43 48 49 50 51 76 80 81 82 83 96 97 98 99 BCS> Exit
All of the setup information, as well as the shot programming, for the Hybrid Control System is contained in the HYBRID MDSplus tree and its PCS subtree. Volatile data associated with shot programming is stored in the PCS tree, and referenced in the HYBRID tree. Static and Configuration data is stored directly in the HYBRID tree. Under normal circumstances, the main Physop interaction with the tree structure is to the PCS subtree, using the PCS.PRO software described in Chapter 6. Changes to the configuration, including changes in inputs or outputs, and modifications to the machine setup (such as reverse-field operation) require updating of the contents of the HYBRID tree, as noted in Chapter 10.
The top-level nodes are shown in the TRAVERSER display in figure 5.1. Some of the nodes are obsolete. Among the ones that are still in use, the following are noteworthy:
\HYBRID::TOP.CONFIG:CONFIG_ID is a text node containing a STRARR which contains the history of the hybrid configuration. The load date of this node is put into \PCS::TOP:CONFIG_ID by PCS.PRO at load time, and the contents copied to \PCS::TOP:CONFIG_TXT. These nodes are used to check the compatibility of old PCS trees or segments with the current state of the hybrid control system. Any change to the hybrid configuration should be appended to the array of text values in \HYBRID::TOP.CONFIG:CONFIG_ID.
Each of the 96 inputs to the Hybrid Computer (A-inputs) is described in a node under \HYBRID::TOP.CONFIG.INPUTS:INPUT_nn. The structure of these nodes, as described in \HYBRID::TOP.CONFIG:AAAINPUTS is
.INPUTS:INPUT_nn = Unique NAME identifying the input, eg 'BP01_BC' TAG = \HYBRID::HYB_INPUT_NAME_nn INPUT_nn:STRUCTURE = Unique description of type of measurement and means of obtaining further information. eg 'FLUX_FULL' INPUT_nn:QUANTITY = Name of the quantity measured by the signal INPUT_nn:P_TO_V_EXPR = evaluates to the calibration of the input, in physical units/volt. Most of these nodes contain an expression that invokes a shareable image made from Fortran subroutines that "know" about how to extract calibration information from the tree for given values of STRUCTURE and NAME
Each of the 16 OUTPUT signals is described by a node under \HYBRID::TOP.CONFIG.OUTPUTS of the form OUTPUT_nn, with underlying structure
.OUTPUTS:OUTPUT_nn = Unique name describing the output, e.g. OH1_VOLT CHANNEL = the channel number of the corresponding Wavegen (V) signal GAIN = Calibration of the output in Volts of output/Volt out of supply. This is a signed quantity, for example a typical value for OH1_VOLT is -.01. Note that this actually corresponds to the inverse of the gain of the output device, considered as an amplifier applied to the hybrid output. WAVEGEN_OUT = Obsolete (no longer used)
For each name in the contents of \HYBRID::HYB_OUTPUT_%% there is a node under \HYBRID::TOP.CONFIG.V:* with the same name. Note that this means changing an output actually involves editing the tree, not just changing the data! The only purpose of these nodes seems to be to contain LIMITS and STEP settings for the draw widgets in PCS. This seems to be a vestigial feature.
Nodes under \HYBRID::TOP.CONFIG.WAVEGEN contain information about the wavegen references in a cryptic and convoluted form. As noted above, the references for the 32 wavegen channels are controlled in 8 groups of four channels each. Originally, when the references were hard-wired, the nodes \HYBRID::TOP.CONFIG.WAVEGEN:REF_01 through REF_07 contained data regarding these references, using the GET_INPUT_P_T0_V routines as done for inputs, with a structure of "HYB_REFERENCE" and a name of "REF_ONE". These nodes are now obsolete for the P wavegen nodes, which can have time-dependent reference lines. The PCS.PRO software now calls WRITE_P_OUTPUT.PRO, which identifies the reference for each segment as either "10" or "IP", and evaluates the P_TO_V_EXPR in either \HYBRID::TOP.CONFIG.WAVEGEN:REF_10 or \HYBRID::TOP.CONFIG.WAVEGEN:REF_IP accordingly. The V outputs, all of which use a constant reference, actually do not access these nodes and simply assume a P_TO_V of 1.0, although it would probably be more elegant to evaluate the appropriate REF_%% nodes.
The \HYBRID::TOP.HARDWARE.BITBUS child node includes the BITBUS devices as shown in the figure. The INIT actions under each of the matrix devices and the WAVEGEN device load data which is referenced from the PCS subtree. The NODE_LIST identifies the DAC cards for which the data is destined. The STORE actions return the contents of the cyclic buffer to the appropriate nodes in the hybrid tree. The RT_NODE and RT_STORE are IDL pseudo-devices that invoke code to download the shot sequence and upload the timing table from the hybrid.
The CAMAC devices under \HYBRID::TOP.HARDWARE.CAMAC include the digitizers which record the inputs, outputs, and intermediate signals from the Hybrid. The DECODER and J221 also generate gates and triggers used by the Hybrid. The DECODER values are independent of the PCS tree except for the Wavegen trigger time E4, which indirectly references \PCS::TOP.LOADABLES.WAVEGEN:TRIGGER_TIME. The J221 active outputs are
switch times for RT-node (not used in present configuration)
Fizzle detector gate (now references the Engineering tree)
RT-node start trigger
Aurora 12 start trigger
Notice that the A12_01 digitizer is available for general troubleshooting, and has a separate trigger from the main data digitization.
The digitized signals from the Hybrid are found in \HYBRID::HYBRID_SIGNALS.
The PCS subtree contains the volatile (shot-specific) programming data which is referenced by the Hybrid tree nodes. The main user interface to the PCS tree is through PCS.PRO, as described in Chapter 6. The top level structure of the PCS tree is shown in figure 5.2. As mentioned above, \PCS::TOP:CONFIG_ID contains the date_entered value for the corresponding node in HYBRID, while \PCS::TOP:CONFIG_TXT holds the contents. The \PCS::TOP.LOADABLES child holds the assembled matrices and programming that gets downloaded to the Hybrid. All of the segment-level programming described in the next chapter is contained under the \PCS::TOP.SEG_%% nodes.
Additional information may be found in files contained in the directory user9:[horne.hybrid_docs]. Particularly useful (at least to somebody) are the following files:
Directory USER9:[HORNE.HYBRID_DOCS] HYBRID.TEX WAVEGEN.TEX GENERAL_NOTES.TXT
