This website is no longer maintained. Its content may be obsolete. Please visit http://home.cern for current CERN information.
Refer to Functional Specification http://cern.ch/fgc/ (inside CERN only) PC status
The LHC powering system will be comprised of some ~1700 power converters. These will be divided into ~80 WorldFIP segments each of which is to be connected to the Controls Ethernet via a gateway PC. The gateways are to be responsible for the management of the WorldFIP segments and the sending and receiving of commands and other data to the FGCs within the power converters.
Each gateway acts as a CMW middleware device server allowing access to each power converter connected to its WorldFIP bus. Devices within the power converter control system are either gateways or FGCs, both of which have properties and published data.
Each gateway receives a block of status data from each power converter connected to its WorldFIP bus in real-time at 50 Hz. This data is made available through a CMW subscription at a (presently fixed) rate of 2 Hz.
The gateways allow both synchronous and asynchronous get and set commands to be sent to power converters using the CMW middleware. All property values are transmitted through the middleware as ASCII strings.
Details of power converter properties are available on the FGC project web site. Not all properties are made visible through the Java client interface. Those which are exposed through Java are listed as having the 'Java' flag set on the web page.
Subscription to arbitrary properties is not available as this would require polling across the WorldFIP segments resulting in an unacceptable load. A single property is published per power converter that contains the above-mentioned status block received over the WorldFIP.
Several interfaces in a variety of languages exist for client access to the gateways and power converters. For LHC controls the JAPC interface in Java will be used in combination with the CMW middleware.
Name resolution and the resolution of a power convertor name to its associated gateway - and therefore CMW device server - will be handled by the CMW naming service.
The gateways will allow real-time control data to be sent to all or a subset of the power converters at a rate of 50 Hz. The protocol and interface for sending real-time data to the gateways are as yet undefined. The FGCs support several different modes of real-time feedback, allowing the reference to be supplied as an offset, gain or direct reference.
Each gateway will include an LHC timing receiver (CTRI) which will be used to trigger the 50Hz WorldFIP cycles and to get the time that will be sent to the FGCs within each of those cycles.
Timing events received from the CTRI that are relevant to the power converters attached to a gateway will be forwarded to the converters by the gateway over the WorldFIP bus. Therefore it will be possible to use timing events to trigger power converters to start synchronised ramps.
A power converter's state can be obtained by getting its state.pc property. This property is also available for subscription. The range of states that a power converter may be in is documented on the FGC web site. A diagram showing the possible state transitions is also available.
The procedure for PELPing to a given current is as follows (assuming the converter starts in the OFF state):
state.pc property to on_standby.to_standby state and ramp to its standby current. When the standby current has been reached, the converter's state will change to on_standby.state.pc property to idle.ref property to a PELP reference with appropriate parameters as defined on this page.checking state while it is validating the reference change.armed state if the reference is accepted or return to the idle state if not.time.run property to the time at which the PELP should start.running state when the time specified in time.run is reached and will start to ramp.idle state target current is reached.The procedure for ramping with a function is as follows (assuming the converter starts in the OFF state):
state.pc property to on_standby.to_standby state and ramp to its standby current. When the standby current has been reached, the converter's state will change to on_standby.state.pc property to idle.tbl.dt property to the array of time reference deltas.tbl.dr property to the array of current reference deltas.ref property to a TABLE reference with a gain parameter for the current references (e.g. 0.001 for milliamps) as defined on this page.checking state while it is validating the reference change.armed state if the reference is accepted or return to the idle state if not.time.run property to the time at which the PELP should start.running state when the time specified in time.run is reached and will start to ramp.idle state when the target current is reached.During LHC operations, many power converters must be ramped synchronously. The procedure that must be followed in order to achieve this is similar to that stated above under the heading "Load and run function". All properties should be set through CMW using the JAPC interface and converter states should be monitored throughout. In order to perform operations in good time, asynchronous commands should be used.
The procedure is as follows (assuming that converters start in the IDLE state):
tbl.dt property to the array of time reference deltas for the individual converter's function.tbl.dr property to the array of current reference deltas for the individual converter's function.ref property to a TABLE reference with a gain parameter for the current references (e.g. 0.001 for milliamps) as defined on this page.checking state while they validating the reference change.armed state if the reference is accepted or return to the idle state if not. Converters in the armed state are waiting for the arrival of a timing event to trigger the start of the ramp.running state when the timing event is received and will start to ramp.idle state when the target current is reached. This procedure may then be repeated to run another ramp.1. I would never expect to use a PELP in current (as opposed to energy) in an FGC for a trim, since the length of a PELP is not one of the parameters. The time it takes is a result of the Delta I and the acceleration etc... So PELPs for different converters with different Delta Is would difficult to arrange to take the same time. The FGC includes two dedicated trim functions, LTRIM and CTRIM (linear and cubic). The key feature of these functions is that the time taken is a parameter. Linear trims are best avoided unless they are very small and slow otherwise the discontinuity in the first derivative will lead to overshoots/undershoots in the tracking of the reference. Cubic trims are beautifully smooth in the first and second derivative and should result in perfect tracking. I guess for very small trims it may be fine to move a number of converters in unison using CTRIM. However, I expect in the end, in order to assure the optics remain precisely controlled, I imagine even trims of a few converters will be done using tables of current vs time derived from strengths vs time, in just the same way as the ramp or squeeze.
2. Stopping during a ramp was included in a basic way in the FGC design in as much as there will be a timing event that will be able to tell all the converters to slow down their dI/dT in a linear way in a pre-defined time (perhaps 15s). In this way, every predefined ramp will terminate smoothly with a parabolic deceleration taking exactly the same time. Will there still be a beam? Seems highly unlikely unless you have real-time orbit and tune feedback working well (chromaticity too perhap?). So maybe one day when the RT systems have been perfected, then aborting a ramp may be possible while holding onto the beam.
3. There is a third real-time mode that you didn't mention on your slide, RT_DIRECT, in which the function generation is disabled and the reference is set directly to the value received at 50Hz via the WorldFIP. This mode may or may not be useful. It basically pushes the full responsibility for function generation to the centre, which actually might be good for RT orbit feedback, and maybe tune feedback. Or it may always be better to download a predefined function based on previous experience and just leave the feedback to mop up the error.
Following discussion between Mike & Quentin
5000 it is then - though be aware that there is a limit to the maximum length
of a command that can be sent to an FGC (due to memory limitation
in the microcontroller. This is ~9KB, so you will probably only be able to
send 500 points per command (depending upon how many digits are
needed per point. Thus your business layer will need to know how to break apart
the vector into shorter pieces to be sent separately. If we
assumed that a typical point required this:
"1234.678,1234.67," (seconds,amps) (In fact, the time and current vectors are separate properties so you will send time,time,time,... and later current,current,current,... But this is unimportant for this back of the envelope throughput calculation).
This is 17 characters, so 5000 points means ~85KB, so 10 separate commands
will be needed, each taking a minimum of 3s to send (3K/s). So
you're looking at ~30s to send a 5000 point vector to an FGC. The gateway can
sustain this throughput to 16 FGCs in parallel. Beyond this
number and it will slow down as they compete for bandwidth.
Don't forget the REF.ERR_IDX property which will tell you which segment of a PELP/PLEP or point of a table is the source of the error when trying to arm a reference change. The new software adds another similar property called, for the moment, simply ERR_IDX (i.e. it's a top level property). This will report the parameter which caused an error when setting a property. Might be useful if you have 5000 points, and the 3845th is out of limits or something like that.
http://proj-lhc-fgc.web.cern.ch/proj-lhc-fgc/gendoc/def/PropertyLIMITS.htm
1. Load Control Properties
To accommodate the new model, the properties defining the load have changed:
*
* LOAD.OHMS.CONTROL[4] ==> LOAD.RST.OHMS_SER[4] LOAD.HENRYS.CONTROL[4] ==> LOAD.RST.HENRYS[4]
* LOAD.OHMS.SIM[4] ==> LOAD.SIM.OHMS_SER
* LOAD.HENRYS.SIM[4] ==> LOAD.SIM.HENRYS
* LOAD.OHMS.MEAS ==> MEAS.OHMS
* LOAD.HENRYS.MEAS ==> MEAS.HENRYS
Two new properties have been added to specify the parallel resistance:
* LOAD.RST.OHMS_PAR[4]
* LOAD.SIM.OHMS_PAR
The old "CONTROL" properties are now grouped under LOAD.RST since
they are used to calculate the RST polynomial coefficients that define the
current loop behaviour. OHMS_SER specifies the series resistance, OHMS_PAR
specifies the parallel resistance and HENRYS specifies the inductance. Note
that if a circuit does not contain a parallel resistance, the value of LOAD.RST.OHMS_PAR
should be set to a very large value, e.g. 1.0E+8, to indicate that the parallel
branch is open circuit.
As before, these properties are arrays of four values corresponding to the
four possible load configurations chosen by the property LOAD.SELECT:
* 0 = Magnet circuit (Normal operation)
* 1 = Cable circuit (loopback at cryostat or warm magnet)
* 2 = Short circuit (loopback at the converter)
* 3 = Test
2. Simulated Load Properties
All the LOAD.RST properties are part of the FGC configuration, which means
that the values are saved in non-volatile memory and are persistent across
resets. They will also be stored in the configuration database once this
is implemented. Before this latest update, the simulation properties were
also arrays of four values selected by LOAD.SELECT and were also part of
the configuration. However, in practice, the simulation properties should
almost always be the same as the LOAD.RST properties, except on the rare
occasions when loop tests are being done by myself or Hugues. So the simulation
properties now have a new and simpler behaviour:
* LOAD.SIM properties are scalar
* LOAD.SIM properties are no longer part of the FGC configuration
* LOAD.SIM properties will be set to the corresponding LOAD.RST properties
selected by LOAD.SELECT whenever the FGC is reset or LOAD.SELECT is set, but
not when the LOAD.RST are set.
* LOAD.SIM properties can be changed to test the stability of the RST algorithm,
however, the changes will be lost at the next reset or the next time LOAD.SELECT
is set.
The new release of the software implements the new circuit model based on
the the LOAD.SIM properties.
3. Measured Load Properties
The "measured" load properties have moved to MEAS.OHMS and MEAS.HENRYS.
These values are only rough estimates and it is not possible to discriminate
between the series and parallel resistances, so only a single MEAS.OHMS property
is provided. OHMS_PAR will always be significantly larger than OHMS_SER so
MEAS.OHMS can be assumed to be an estimate of OHMS_SER. OHMS_PAR will have
to be set to the theoretical value for the circuit.
4. RST coefficients
As the moment, the computation of the RST coefficients is based on the old
circuit model that does not have a parallel resistance. This can lead to
instability when testing a single magnet containing a parallel resistance.
Hugues is preparing a new control algorithm based on the new circuit model
which will be included in a future release of the the FGC software.
5. Start-up of 1 and 2 quadrant converters
The start-up of 1 and 2 quadrant converters includes an initial period of
open-loop operation in which the voltage reference is ramped up linearly.
The purpose of this ramp is to raise the current to a level at which the
voltage source is operating linearly and it is possible to close the loop.
One of the new limits properties described in the previously distributed
memo is LOAD.LIMITS.I_CLOSELOOP[4], which defines the current at which the
loop should be closed. The calculation of the voltage ramp has been updated
in the new release to accommodate the new circuit model such that if the
voltage source were perfectly linear from zero amps, the current will reach
this threshold after VS.TO_SB.START_PERIOD seconds. The user needs to tune
the value of START_PERIOD for each load configuration so that the rate of
change of current at the moment the loop closes is roughly 80% of LOAD.LIMITS.DIDT.
It would be nice if the FGC could work out START_PERIOD in order to achieve
this, but unfortunately, according to Mathematica, the solution depends very
sensitively on the ProductLog function, which is not available in the C maths
library. The attached Limits memo has been updated slightly (v4) to show
the new start-up behaviour.
6. Reference checking
From version 38, improved limits checking was added to the FGC software.
When setting up a reference change using PELP, PLEP, CTRIM, LTRIM or TABLE,
the old circuit model was used to estimate the voltage required to achieve
the I and dI/dt at certain points during the reference. This was possible
because the equation was simply V = I.R + L.dI/dt. With the new circuit model,
it is not possible to calculate V in this way. It depends not only on I and
dI/dt but also on the history of V. For the moment the limits checking remains
unchanged, so it will produce small errors when the circuit contains a parallel
resistance. Work is ongoing to estimate the significance of the these errors
and if necessary, the FGC could run a simulation of the complete reference
change in 1 ms steps to see if any of the voltage limits are exceeded. It
is difficult to estimate how long this might take, but it should be no more
than 1 second, even for a very long table.