• transfer: a single loading of beam between MI and Tev
• a transfer is distinguished by a single injection/extraction kicker pulse
• the plan is to start with 36 proton transfers and 9 pbar transfers
• bucket: a single RF bucket
• there are 1113 of these in the Tev
• enumeration of proton buckets is relative to the proton beam-synch marker
• enumeration of pbar buckets is relative to the pbar beam-synch marker
• bunch: a single populated bucket of beam
• the plan is to start with loading 36 proton and 36 pbar bunches
• batch: a Booster cycle's worth of protons or a "2.5 MHz blob" of pbars
• a coalesced batch ends up as a bunch in the Tevatron

• 2 Pseudo devices, one for each species particle: T:PBKTD, T:ABKTD
• describes the bucket population we want
• [0 - 36] elements
• element 0 is the total number of bunches to load
• element X contains the target bucket number for bunch X
• so, the number of bunches to be injected will equal the number of non zero elements, not including the 0-th element
• this device should not change during a fill
• 2 Pseudo devices, one for each species particle: T:PXORD, T:AXORD
• describes the ordering of the transfers
• [0 - 36] elements
• element 0 is the total number of transfer to do
• element X is the leading bunch number to transfer
• so, the number of transfers to be done will equal the number of non zero elements, not including the 0-th element
• this is the index for reading values from T:PBKTD and T:ABKTD
• this is the index for filling values into T:PBKTC and T:ABKTC
• this device not should change during a fill

• 2 Pseudo devices, one for each species particle: T:PBKTC, T:ABKTC
• describes the actual (current) bucket population
• [0 - 36] elements
• element 0 is the total number of bunches actually loaded
• element X contains the actual bucket number for bunch X
• so, the number of bunches that have been injected will equal the number of non zero elements, not including the 0-th element
• device set shortly after the transfer

• States device V:NXTBKT
• tells the target bucket for the leading bunch of next transfer
• values are [1 - 1113]
• set shortly before the Tev reset associated with the transfer
• States device V:NBATCH
• tells number of bunches in next transfer
• values are [1 - 4] (as long as we have 396 nsec spacing)
• set shortly before the Tev reset associated with the transfer
• As this parameters name suggests, it is the number of "batches" that is really specified.  This means that when we are injecting uncoalesced beam, a single Booster cycle that produces 5 uncoalesce bunches will correspond to a V:NBATCH value of 1.
• States device V:BKTGAP
• tells the number of buckets between bunches in a transfer
• values are [1 - 588]
• set whenever different value desired
• V:BKTGAP will not change if coalescing is turned on and off even though more of the buckets between batches will be filled in the uncoalesced case.
• States device V:XFER
• tells the transfer number
• values are [1 - 36]
• set shortly before the Tev reset associated with the transfer
• States device V:NXBNCH
• tell the number of leading bunch of next transfer
• values are [1 - 36]
• set shortly before the Tev reset associated with the transfer
• States device V:XFRTYP
• tells the species of particle being transferred
• values are [1 through 4]; 1 == forward protons, 2 == forward pbars, 3 == reverse protons, 4 == reverse pbars
• set shortly before the Tev reset associated with the transfer

• INJECT <SPECIES> <ENUM>
• <SPECIES> = PROTON or PBAR
• <ENUM> = ALL or ? or a bunch number of the leading bunch
• a single transfer: INJECT PROTON 3
1. reads element 3 of T:PBKTD to determine target bucket
2. set V:NXBNCH to 3
3. set V:XFRTYP to 1 to indicate forward protons
4. set V:NBATCH to desired number of batches [source of this value to be determined]
5. set V:NXTBKT to value from step 1.
6. set V:XFER to index of element T:PXORD that contains 3

[more discussion needed on all scenarios that could occur within this command]
7. pause
8. Check that T:TGTBKT = V:NXTBKT
9. EVENT 4D ENABLE
10. WAIT_FOR EVENT 5C
11. EVENT 4D DISABLE
12. set elements of T:PBKTC to reflect current bucket population
13. if elements of T:PBKTC above were previously 0, increment element 0 of T:PBKTC by V:NBATCH
14. When injecting Pbars, collision point cogging will have to be set (or at least checked).  Details of this still need to be defined.
• an interactive, single transfer: INJECT PROTON ?
• query user for desired leading bunch number;

choices are the non zero values of T:PXORD
• do same action as a single transfer, described above
• a full transfer: INJECT PROTON ALL
• user prompted for starting bunch number (call this 'SB') to transfer;

choices are the non zero values of T:PXORD
(allows for continuing a fill after a failed transfer)
• read T:PXORD to determine number of transfers (loop iterations);

which is:  T:PXORD[0] - 'index' + 1 (where SB = T:PXORD['index'])
• 'transfer number' = 'index' (where SB = T:PXORD['index'])
• for each transfer:
1. set V:XFRTYP to 1 to indicate forward protons
2. set V:NXBNCH to T:PXORD['transfer number']
3. set V:NBATCH to desired number of batches [source of this value to be determined]
4. set V:NXTBKT to T:PBKTD[T:PXORD['transfer number']]
5. set V:XFER to 'transfer number'
6. pause
7. Check that T:TGTBKT = V:NXTBKT
8. EVENT 4D ENABLE
9. WAIT_FOR EVENT 5C
10. EVENT 4D DISABLE
11. set elements of T:PBKTC to reflect current bucket population
12. if elements of T:PBKTC above were previously 0, increment element 0 of T:PBKTC by V:NBATCH
13. increment 'transfer number'
14. When injecting Pbars, collision point cogging will have to be set (or at least checked).  Details of this still need to be defined.

Sequencer EJECT command (this whole section is new, but only significant changes from forward injection are in red)

• EJECT <SPECIES> <ENUM>
• <SPECIES> = PROTON or PBAR
• <ENUM> = ALL or ? or a bunch number of the leading bunch
• a single transfer: EJECT PBAR 17
1. reads element 17 of T:ABKTD to determine target bucket
2. set V:NXBNCH to 17
3. set V:XFRTYP to 4 to indicate reverse pbars
4. set V:NBATCH to desired number of batches [source of this value to be determined]
5. set V:NXTBKT to value from step 1.
6. set V:XFER to index of element T:AXORD that contains 17

[more discussion needed on all scenarios that could occur within this command]
7. pause
8. EVENT 54 ENABLE
9. WAIT_FOR EVENT 5F
10. EVENT 54 DISABLE
11. set elements of T:ABKTC to reflect current bucket population
12. if elements of T:ABKTC above were previously non-0, decrement element 0 of T:ABKTC by V:NBATCH
• an interactive, single transfer: EJECT PBAR ?
• query user for desired leading bunch number;

choices are the non zero values of T:AXORD
• do same action as a single transfer, described above
• a full transfer: EJECT PBAR ALL (T:PXORD and T:AXORD are still used, but are looped through in reverse order of forward injections.)
• user prompted for starting bunch number (call this 'SB') to transfer;

choices are the non zero values of T:AXORD
(allows for continuing a fill after a failed transfer)
• read T:AXORD to determine number of transfers (loop iterations);

which is:  'index' of T:AXORD[0]  (where SB = T:AXORD['index'])
• 'transfer number' = 'index' (where SB = T:AXORD['index'])
• for each transfer:
1. set V:XFRTYP to 4 to indicate reverse pbars
2. set V:NXBNCH to T:AXORD['transfer number']
3. set V:NBATCH to desired number of batches [source of this value to be determined]
4. set V:NXTBKT to T:ABKTD[T:AXORD['transfer number']]
5. set V:XFER to 'transfer number'
6. pause
7. Check that T:TGTBKT = V:NXTBKT
8. EVENT 54 ENABLE
9. WAIT_FOR EVENT 5F
10. EVENT 54 DISABLE
11. set elements of T:ABKTC to reflect current bucket population
12. if elements of T:ABKTC above were previously non-0, decrement element 0 of T:ABKTC by V:NBATCH
13. decrement 'transfer number'

Examples of bucket loading for 36x36

As an example, we give the contents of the bucket array devices for the scenario in which 36 proton bunches are injected one at a time and 36 bunches of antiprotons are injected in 9 transfers of 4 bunches each.  In this example, the fully loaded Tevatron has three trains of 12 proton bunches and three trains of 12 antiproton bunches. The bunches within each train are spaced spaced 21 buckets apart and the starts of each train are spaced 1/3 of the Tevatron ring apart.

• For protons the arrays T:PBKTD and T:PXORD are self explanatory. We inject the proton bunches in order 1 through 36 and the bucket number for proton bunch X is given by T:PBKTD[X].
• T:PBKTD[36, 1, 22, 43, 64, 85, 106, 127, 148, 169, 190, 211, 232, 372, 393, 414, 435, 456, 477, 498, 519, 540, 561, 582, 604, 743, 764, 785, 806, 827, 848, 869, 890, 911, 932, 953, 974]
• T:PXORD[36, 1, 2, 3, 4, ..., 34, 35, 36]
• For each transfer V:NBATCH = 1
Thus transfer #1 loads proton bunch 1; transfer #2 loads proton bunch 2; etc.
 
• For antiprotons the arrays T:ABKTD and T:AXORD need a bit more explanation. Because the antiprotons are loaded after the protons the injection of the antiprotons must be timed to align them within the gap in the proton bunches. Since the gap is not long enough to accommodate the injection of 12 antiproton bunches it is necessary to inject some of the antiprotons, cog those antiprotons, then inject some more antiprotons. This means that the antiproton bunches are not injected sequentially according to bunch number.  Also, because the antiprotons are injected 4 bunches at a time, not all antiproton bunch numbers will be used to enumerate the injection scenario described here. This scheme can be accomplished by setting up T:ABKTD and T:AXORD as
• T:ABKTD[] = T:PBKTD[] as in example above
• T:AXORD[9, 1, 13, 25, 5, 17, 29, 9, 21, 33, 0, 0, ..., 0]
• For each transfer V:NBATCH = 4
Thus transfer #1 loads antiproton bunches 1, 2, 3, and 4; transfer #2 loads antiproton bunches 13, 14, 15, 16; transfer #3 loads antiproton bunches 25, 26, 27, and 28; etc. Note that between transfer #3 and transfer #4 the antiprotons already in the Tevatron will be cogged by 84 bunches with respect to the proton bunches. Between transfer #6 and transfer #7 the antiprotons already in the Tevatron will be cogged by an additional 84 bunches. (There will be a final cogging to move the antiprotons to the collision point cog, but when this occurs is still undetermined.)

Tevatron LLRF and Injection

• Communication with the LLRF
•  Before each injection four state devices will be set by the Tev sequencer and broadcast via multicast. The state devices are:
• V:XFRTYP Injection Type, values are [1 = Forward Protons, 2 = Forward Pbars, 3 = Reverse Protons, 4 = Reverse Pbars]
• V:NXTBKT Target bucket for next transfer, values are [1 - 1113]
• V:NBATCH Number of bunches in next transfer, values are [1 - 12]
• V:XFER Transfer number values [1 - 36 for protons, 1 - 9 for pbars]
• V:NXBNCH Next leading bunch [1-36 for both protons and pbars]
• Even though all four states are broadcast, the LLRF will probably need only the value of V:NXTBKT, the target bucket number. The injection type (proton or antiproton) will be obvious from the MI LLRF state but can also be determined from V:XFRTYP if needed.
• The Tevatron LLRF, whenever it is in a proton injection(or ejection) state or a pbar injection (or ejection) state, will receive the multicast state V:NXTBKT via UDP.  Since the MI LLRF and the Tev LLRF have shared memory the value of V:NXTBKT will be available to the MI LLRF.
• To help diagnose problems the MI LLRF should update an ACNET device whenever it receives a multicast of V:NXTBKT. The device should reflect the target bucket that the MI LLRF believes it will inject beam into. The name of the device might be called T:TGTBKT for example. T:TGTBKT will be used as a very useful diagnostic device to help understand the injection process.  When injecting pbars, does the LLRF reflection event tell us the bucket offset from the proton marker, the pbar marker, or do we need a parmeter for both?  I know we want the state device to be relative to the pbar marker and my guess is that this is all we need for the reflection device as well.
• By using the multicast method there is no assurance that the Tev LLRF received the multicast and this leads to the possibility of injecting beam on top of already circulating beam thereby causing a quench. There are two possibilities to reduce this risk:
• The sequencer 'inject' command checks that the device T:TGTBKT is set to the desired value before enabling the injection.
• OR, Instead of relying on the multicast of a state variable, the sequencer sets an ACNET device which is owned by the LLRF and whose value is the target bucket.
We plan on beginning by implementing the first safeguard and will switch to the second if necessary.
 
• Meaning of V:NXTBKT:
• When we are injecting protons the target bucket given in V:NXTBKT is with respect to the proton marker. The leading bunch in a train of proton bunches will be injected into this Tevatron bucket number.
• When we are injecting antiprotons the target bucket given in V:NXTBKT is with respect to the ANTIPROTON MARKER. However, the antiproton transfers occur with respect to the proton marker so that the Tev/MI LLRF must calculate the correct value for the target bucket with respect to the proton marker. This should not be a problem since the Tev LLRF knows and controls the cogging of the pbar marker with respect to the proton marker. (I assume there will be one time study to determine timing delays, etc.)
• So far there has not been any determination of what the LLRF does when uncoalesced beam is used in the Main Injector. The main question is the meaning of the target bucket. Will uncoalesced beam be injected with its leading bunch in the target bucket? or will uncoalesced beam be injected with its central bucket in the target bucket? And how will the LLRF know whether beam is coalesced or uncoalesced.

My suggestion for controlling coalescing is as follows.  To turn on coalescing we turn on a TLLRF owned device (T:COALES).  When the MILLRF is playing a state that is a Tevatron injection state, it looks at the status of T:COALES to determine if it should do coalescing.  There should also be a states device that indicates if there is coalesced beam in the Tevatron or not.  This would have to be set during injection and then left alone once we move out of an injection state.  We may need a parameter for protons, and another for pbars.

Other Issues to Consider

• How do we reset the parameters T:PBKTC and T:ABKTC
• After Proton removal, the Proton buckets should be empty
• After an abort or a clean up event, all buckets should be empty.
• If we have uncoalesced beam, the total length of the bunch train is increased by the number of bunches in a batch.  We will need to understand the limitations based on the real kicker flattop lengtns.