Difference between revisions of "Helicity Control"

Latest revision as of 16:51, 3 June 2019

See also - DAQ Doc Portal

SCAM Module

SCAM module update description

The SCAM module (see description above) is responsible for sending the 60 Hz line-sync based signal around the entire accelerator, and for our purposes is used to signal the start of a new multiplet pattern in the Helicity Control Board.

Pete Francis designed and manages the beam sync chasis (a box holding a CAMAC module in an independent power supply) and all of its distribution (to all service buildings, the injector, and the 4 halls).

• There is a "line sync" generator module in the injector (and a hot backup) which take the 60 Hz line signal from the wall and generates a "beam sync" pulse that is sent to the SCAM module.
• Line sync is used to create "beam sync" in the SCAM module
  • SCAM is basically one of Roger Flood's Helicity Control Boards
  • It has fiber in and out, but it also has a LEMO/NIM output of both the input line sync and output beam sync signals, and in the injector both of these are put into a nearby scope to make sure the signal is healthy.
• SCAM's beam sync signal is sent to all subsequent beam sync chasis (daisy chained, so if one breaks they all go, none have broken) which have many LEMO, ECL, and fiber outputs (and delayed outputs) and if any are unused that means they are free to grab.
• The beam sync chasis are daisy chained around the accelerator
  • 2 in the front of the injector, with free spaces
  • 1 near the beam sync generating SCAM, no free spaces
  • 1 in each service building
  • 1 in each hall
• The non-injector beam sync chasis will also have additional structure to their signals
  • They will have very narrow small pulses indicating additional passes of beam around the accelerator
  • On the scope, beam sync varies ~ 35 us from one pulse to the next (looking for a few seconds, maybe larger jumps are possible too)
  • The beam sync signal is ~ 500 us delayed w.r.t. line sync input, and the pulse is ~ 370 us long

Here is a diagram of beam sync (not including when the electron beam is sent during Tune Beam, but it is apparently synched too) from John Musson.

Helicity Control Board

Helicity Control Board manual

Usage

Load the Helicity control board library at boot in the vxworks bootscript, or as an executable from the linux command line, or directly from a telnet session in vxworks - the version in apar@adaq halladaq6.boot bootscript is in devices/helbrd/HelBoard.o

ld < /adaqfs/home/apar/devices/helbrd/HelBoard.o
# these 3 the same in any case
WriteHelBoard(0,5) # Tsettle time
WriteHelBoard(2,0) # QRT
WriteHelBoard(3,1) # Delay (I think)
# changes the frequency, essentially
WriteHelBoard(1,27)    -- 30 Hz
# WriteHelBoard(1,23)    -- 120 Hz
# WriteHelBoard(1,20)    -- 160 Hz
# WriteHelBoard(1,12)   -- about 480
# WriteHelBoard(1,10)    -- 715 Hz
# WriteHelBoard(1,8)    -- 940 Hz
# WriteHelBoard(1,5)    -- 1100 Hz

Firmware Version Confusion

There are multiple versions of the helicity control board firmware. Here is a description of the discovery that newer versions of the firmware do not allow free-clock mode without an external beam sync signal (see also DAQ_Testing/20190212)

Using Bob's TEDf test stand Cameron noticed that the Helicity Control Board that had recently had its firmware upgraded did not work in free-clock mode right off the bat - it is not getting a heartbeat

• Talk with Roger Flood: he took the board last Friday and re-flashed all of the firmware to make sure it works
  • Cameron tested it again today and found the same problem - took it back to him and he suggests trying to talk with Software EPICs people who know which software bits need to be set in order to turn on and off the Free Clock vs. 30Hz line sync modes
• Using readHelBoard(bit) doesn't return anything for values other than the 4 main helicity sequence setting bits - go to MCC to ask Kyle Hesse

Working with Kyle Hesse to understand difference between old and new firmware:

• In EPICs there is setting of a "CLOCK" parameter which can be set to Free Running mode or to several CLOCK locking modes when the ROC is connected to an EPICS IOC
• Kyle shows the EPICs interface (search for Helicity in JMenu)
  • Sets bits for CLOCK with EPICS from an IOC
  • CLOCK Offset = 0x0f
  • CLOCK Mask = 0xff
  • Bits: 0000 0000
  • 0 = 30 Hz Line Sync
  • 1 = 120 Hz Line Sync
  • 2 = 240 Hz Line Sync
  • 3 = Free Clock (Defaults?)

• We look at the Injector Crate's Helicity Control Board
  • It has a 30Hz line synch signal plugged into it to trigger off of (unlike the TEDf test stand)
• Go to UITF VME Test Crate to test one of the new firmware boards that Kyle has in his possession -> Observations:
  • The Helboard will load the software and address and initialize all just fine
  • Giving a 30 Hz line sync fiber signal input (top port) will wake up the board from dormant heart beat (HB light turns on, and so does BS light on the left)
    • This works in either Free Clock or Line Synch mode
  • If we set the CLOCK bit to 240 Hz liny synch mode then it will blink 8 times faster, even if 30 Hz reference is plugged in, meaning the software is speeding up, and the reference clock is just a reference
  • If we switch to free clock mode and then remove the 30 Hz reference fiber the board will still work!
    • But then switching back to 30 Hz line synch mode with the 30 Hz reference removed will go back to dormant hearbeat mode, and switching back to free clock will fail again
• Conclusion: So in order to get free clock to work you have to initially wake up the HelBoard and get it cycling, and if it goes to sleep it stays asleep until you give it a reference again
• What about the "old" board that works from boot?
  • Has exactly the same behavior except that it wakes up at boot without needing a reference signal but it still falls dormant and needs to be revived in the same way
• Goal: we would like to at least preserve the "old" behavior, and we would like to not require a reference signal at all to use the free clock mode

Why is this different, why update it at all? When asked about what "line sync" is actually doing he responded this: line sync is taking the signal from a 60Hz reference line sync signal and using that to trigger the start of new Multiplet windows. Because of the requirement that the multiple start on a true to false transition of this 60 Hz signal, running something like Pair-pattern at 240 Hz will actually miss half of the windows! So we should keep this in mind. He says that the time of the final multiplet window is stretched or squeezed to fit in the appropriate number of 60Hz line reference windows, while the first N-1 windows are all fixed at the nominal width (and as a consequence we should always be careful to Gate our ADCs to integrate for less than 1/Frequency time, to avoid getting burned by 60Hz line fluctuations). Using "free clock" mode will simply make frequency = 1/(t settle + t stable) and doesn't try to sync to line at all.

The problem with line synch that was encountered in the injector recently has to do with using multiplets and frequencies faster than the 60Hz line (like a 240 Hz pair I mentioned above). Previously (a month + ago) the board would re-trigger if it saw the line sync signal = true, and so if you ran faster than the 60 Hz flip rate sometimes you would see the tail of the previous true pulse (or something along these lines) which would re-trigger and make a bit of a mess. Now it requires seeing a transition from true to false, meaning it will not have these extra re-truggerings, but also we should still be careful about running flip patterns that come close to filling T=1/60 seconds and report any weird behavior to Roger.

Beam Sync vs. Free Clock

In beam sync mode the logical (falling edge) "beam sync" signal keeps track of the 60 Hz line signal's phase, which does wander regularly, and sometimes in spikes. This beam sync signal is used by the Helicity Control Board (helboard) to trigger the start of a new multiplet pattern, and as such, when running with the beam sync signal plugged in (not in free clock mode) the helboard will either truncate or expand the Nth window of the N-multiplet s.t. the next multiplet will start with the new beam sync transition signal.

This means that there is a reduction of usable Tstable ~ integrate time in vqwks to ensure there are no truncations of the Nth window's integration w.r.t. the other windows (all should always integrate the same amount, so the fluctuation time must be taken from all N windows equally, which introduces artificial deadtime). The Integration time per window must therefore be at most: T_int = T_total - Tsettle - const*Delta T, where const is >= 1 for safety, Delta T is the largest likely instantaneous per-window fluctuation in beam sync, and T_total is the average time / cycle ignoring the fluctuation noise. In Free Clock mode we would always just get T_total and hope that the fluctuations or phase advance differences cancel out over large times, and in Beam Sync mode we have to hope that the large deviations that eat into the Nth window's integration time and register a Nsamples vqwk read error are infrequent enough, but also that we don't loose too much of our integration time to that const*Delta T deadtime factor.

• Looking at Tsettle on a scope in free clock mode I see ~ 40 ns stability at 30 Hz running and ~ 30 ns stabiliy at 1 kHz running.
• Looking at beam sync signal itself on a scope I see ~ 100 ns stability of beam sync vs. line sync, and 35 us of stability of beam sync to the prior beam sync signal which means that 0.84 % of 240 Hz beam time is lost to this instability (which translates to a day or so of running with 50% PAC days of 35 days running for 240 Hz PREX)

HelBoard software update

The HelBoard software has been updated (with advice from Gary Croke) - The Counting House VXWorks Bootscript's HelBoard.o executable is now in a new ~/devices/helbrd-sync/ copy folder. This update allows for VXWorks command line user editing of the "Clock Mode" register - now we have a 5th register to control the beam synch mode (beam synch vs. free clock) and its fixed output frequency (30, 120, 240):

• WriteHelBoard(4,0) -- 30 Hz
• WriteHelBoard(4,1) -- 120 Hz
• WriteHelBoard(4,2) -- 240 Hz
• WriteHelBoard(4,3) -- Free Clock

All require some clock signal to be plugged into the front, but these are the exact frequencies that it will generate in the first N-1 multiplet windows before resetting the QRT trigger (I think... maybe it resets QRT/relative MPS trigger on each external "beam synch"?)

Note that in Free Clock mode the user has control over Tsettle and Tstable, while in Beam Synch mode the user only has control over the relative amount of the helicity window that is occupied by Tsettle. In both modes the user can control delay and multiplet pattern type.

Helicity and SCAM update in injector - from Riad

https://logbooks.jlab.org/entry/3683476