[Dsg-hallc_nps] [EXTERNAL] NPS LED/VLD controller specs/information/summary
Brad Sawatzky
brads at jlab.org
Mon Nov 21 18:42:49 EST 2022
After recent discussions with Bryan and William, I volunteered to send
out a status/summary on the NPS LED/VLD needs for the near (Dec/Jan)
and medium term (Feb/Mar).
- Operational specs for the LED pulser are in William's directories.
- His software libraries and test code can be found here:
/group/da/distribution/coda/Hardwaremanual/VLD/
or from the CODA web page. The test software can be accessed from
/daqfs/home/jgu/Triggersoftware/trigger.c, VLDtestN functions.
There are docx files in the /group directory with specs and technical
details. Ideally we would be running the software under linux (intel
vme computer), so any vxworks specific code should be updated to
compile in that environment.
- I am attaching what I think is the most recent spec document for
easy access: 'VLD.docx'
- A Control/GUI requirements summary is attached as a text file.
- See: 'LED-GUI-summary-21Nov2022.txt'
- Here is a link to some (intel controller) development code from Bryan
Moffit: https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_JeffersonLab_vld&d=DwIDAw&c=CJqEzB1piLOyyvZjb8YUQw&r=xEtW9c3YOrPzCwZnOoNyx92mohSWEih9F9MUxcjXPos&m=syAhVPGQCCh58UnUfznMGgP_xw5A4N0lxx4YQXKCKCMDJdxl0eWeeqetQByuGafo&s=X6hwekc4k6mrsuVvTi_JR55kyBT5UUdBlcU9fYaqtt0&e=
---------------------------------------------
Near Term Requirements (ie. late-Dec/early-January)
---------------------------------------------
- We don't need a full working GUI, but we do need a clear, student-
accessible way to run specific tests.
* I am imagining a set of pre-compiled, special-case binaries or
script(s) that are run from a command-line running on the VME
contoller(s)
- The scripts should be able to do the following:
A. Turn all LED on in bleach mode
* This should also set the Trg_out NIM ouput logic HI *first*
and that needs to be tied into the HV interlock circuit.
B. Pulse one or more specified LEDs when a pulse is seen on the VLD
Trg/Clk input.
- The list of LEDs to be activated, pulse characteristics, etc can
either be hardcoded, or read-in via a config file. Doesn't have
to be perfect, just needs to work. We can fine-tune later.
---------------------------------------------
'Beta' quality GUI (Feb, early-March)
---------------------------------------------
- NPS installation begins this spring -- that will come very soon!
* We will need at least a 'beta' quality (ie. feature complete, but may
be buggy) GUI by Feb/early-March so we can test and fix bugs before
the systems is disassembled and moved to the Hall. It will be a while
before it is working again in the Hall and we definitely do not want
to leave testing this critical system to the summer.
-- Brad
--
Brad Sawatzky (he/him), PhD <brads at jlab.org> -<>- Jefferson Lab/SciComp/F272
Ph: 757-269-5947 -<>- Fax: 757-269-5235 -<>- Pager: brads-page at jlab.org
The most exciting phrase to hear in science, the one that heralds new
discoveries, is not "Eureka!" but "That's funny..." -- Isaac Asimov
-------------- next part --------------
A non-text attachment was scrubbed...
Name: VLD.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 3696850 bytes
Desc: not available
URL: <https://mailman.jlab.org/pipermail/dsg-hallc_nps/attachments/20221121/686c3e75/attachment-0001.docx>
-------------- next part --------------
====================================================================================
DSG Meeting: Mon 29 Aug 2022 2:00 PM EDT
- Attending: Brad, Aaron, Bryan M., George J, Marc
====================================================================================
Bleaching Mode:
- All LEDs ON with each channel operating at a common current draw.
It would be a 'like' to be able to set that global current setting
if that is easily set using the underlying library. NOT critical
though.
'Pulse' Mode (individual/group control)
- This is used to test individual PMTs/crystals, simulate 'beam like'
clusters to test the VTP clustering algorithms and timing.
We would like Users to do the following:
- Be able to light up one single LED or a group of LEDs.
for both continuous and pulsed modes.
- Be able to cycle through all (or a range of) channels, pulsing one
LED at a time. LED to LED cycle period should be adjustable.
- The 'pulse' mode should also be generating a 'trigger' pulse on the
module(s) NIM output(s) at the start of each pulse.
I'm sure we will need to meet to go over details, etc. Take a little
time to think about it and we'll set something up later in the week.
----------------------------------
Discussion notes/comments
----------------------------------
- Went over a few questions from Aaron about the above usage and interface
design options.
- Bryan M. and Aaron will work together on the low-level interface
- Brian Eng is one of the people working on this as well (wasn't able to make
it to this meeting)
====================================================================================
Earlier summary email (2021-02-16)
- More detailed notes/requirements
====================================================================================
INBOX - F- 333/333 [17:48 2021-02-16] Brad Sawatzky Re: 5 additional CAEN HV cards -- LED driver board Notes
From: Brad Sawatzky <brads at jlab.org>
Subject: Re: 5 additional CAEN HV cards -- LED driver board Notes
To: Aaron Brown <ambrown at jlab.org>
Cc: "dsg-hallc_nps at jlab.org" <dsg-hallc_nps at jlab.org>
Timeline for the remaining HV card checks sounds fine. Thanks very
much -- that DSG Note is great.
Here is a summary off the top of my head:
The 'LED driver' system will be composed of 7--10 JLab designed
FPGA-based VME boards in a single crate. The boards will be
controlled/accessed through a VME single-board computer running linux.
Generally the FE group supplies a C library for low-level access to the
registers. The boards will be able to individually control an LED
integrated into each of the 1080 crystal+pmt assemblies.
I'm attaching a Draft write up by William Gu that describes the board
and the functionality. There are two general modes of operation:
A) 'Bleaching Mode'
- LEDs are turned on at 'max power' and stay on for up to several
days to anneal out radiation damage in the detector crystals.
- Fairly straight forward - basically an 'All ON / All OFF' switch,
perhaps with a timer and logging mechanism.
- I would expect this to share the same interface as (B), but
would simply involve an extra 'Bleach' button that would engage
all of the LEDS flagged 'active'.
B) 'Pulsed Mode'
- Any subset of the LEDs will be able to driven by a (short) pulse
that will induce a signal in the PMT that approximates a true
particle interaction.
- Ideally the GUI should provide a few basic options:
- a pulse-duration field,
- a pulse-amplitude field (common to all LEDs),
- a pulse-frequency field (common to all 'active' LEDs),
- 'Select all / Disable all',
- indicate what LEDs are 'active' in graphical 2d representation
of the 30x36 detector array, and
- being able to click and/or drag-select groups of crystals in
that 2D grid. For example, similar to how one would select
cells in a spreadsheet. I am hoping(!) this is general enough
that a 'grid' widget is present in your favored GUI toolkit that
can support this.
Additional features that would be useful would include
- An 'import/export' feature to save a configuration and/or restore
a configuration.
- A 'logging' hook that would run a script when used to generate a
logbook entry when the 'Bleach' or 'Pulse Now' button.
It is likely that a CODA ROC process running on the same single-board
VME computer will also access the boards through the VME interface.
We will have to be mindful of race conditions and appropriate locking.
This is something that the FE group will handle in their C library, but
the GUI should perhaps poll the boards periodically and update its
GUI if there has been a configuration change, for example.
Regarding timeline:
My understanding is that the FE group has ordered a prototype board that
should be arriving in 4--6 weeks.
William will need to spend some time testing the board, playing with
the firmware, etc. Once that is basically final (ie. the software
interface is nailed down), then we (William, you folks, and me)
should meet and discuss details. Somewhere in there William (or the FE
group) will develop the C driver library as well.
A rough timescale for a fully-fledged GUI could be June/July, perhaps?
There will be a lot of expert-driven stuff we can do by poking at
registers on the command line, so we will not need a full GUI right
away.
Hope this helps -- save it in a 'notes' file for future discussions.
-- Brad
On Tue, 16 Feb 2021, Aaron Brown wrote:
> Hi Brad,
>
> In our weekly DSG-NPS R&D meeting today we discussed testing the
> additional modules you dropped off.
>
> Tomorrow we will start running the full battery of tests (voltage and
> current stability, ramp, and trip) on the five A7435SN modules and the
> four A1535 modules that you dropped off back in September.
>
> This should all take 2 to 2.5 weeks.
> Also, during the collaboration meeting it was mentioned that DSG would
> make the control and monitoring GUI for the LEDs.
> Would you happen to have any information about this?
> Thanks,
> Aaron
--
Brad Sawatzky, PhD <brads at jlab.org> -<>- Jefferson Lab / Hall C / C111
Ph: 757-269-5947 -<>- Fax: 757-269-5235 -<>- Pager: brads-page at jlab.org
The most exciting phrase to hear in science, the one that heralds new
discoveries, is not "Eureka!" but "That's funny..." -- Isaac Asimov
More information about the Dsg-hallc_nps
mailing list