GammaSphere DAQ - User contributions [en]

Linking Systems Together

2024-02-29T22:46:30Z

Jta: /* Linking Multiple Systems Together */

== Linking Multiple Systems Together ==

The trigger logic implemented for the various DAQ systems and the hardware design of the trigger module allows for the possibility to link multiple systems together. This allows both clock synchronization and trigger sharing to occur. A number of rules must be obeyed, so read '''''carefully'''''.

=== Physical Connectivity and basic firmware controls ===

Just plugging in a cable or a fiber is '''''not sufficient''''' to make anything work.

* Every link (A,B,C,D,E,F,G,H,L,R,U) of a trigger module has an '''''Input Link Mask''''' bit associated with it.
** If a link is masked, the trigger module will not use any data coming in on that link.
** If a link is masked, the trigger module won't send the data you want it to send, either.
** In the GUI screens, the color GRAY means "link is masked" and the color YELLOW means "link is in use/valid".
* While the Input Link Mask is a '''''firmware''''' control, there is also a level of '''''hardware''''' control associated with the cable driver/receiver chips.
** There are controls named DEN (Driver ENable), REN (Receiver ENable) and SYNC that tell the cable driver/receiver chips to operate.
*** For cross-triggering operation, DEN and REN should be '''ON''' and SYNC should be '''OFF'''.
* System linkup scripts will usually leave the SYNC bit for links L, R, U in the '''ON''' state, so to link systems the SYNC should be turned '''OFF'''.

=== Clock Sharing ===

The basic method of clock sharing that most users are familiar with is that the master trigger sends clock to the routers, and the routers re-distribute that clock to the digitizers. Many users also understand that this tree of clock distribution has been extended to include Digital Gammasphere (DGS) sending the clock to DFMA, as shown here.

[[File:ClockHierarchy.png|Standard clock distribution]]

Those that have been involved from the beginning will recall that the DGS master trigger could also be connected to 'Analog' Gammasphere using the GITMO module - and use the clock from 'Analog' Gammasphere. Those that have been involved with hosting external detectors such as CHICO, Microball, ORRUBA, etc. also understand that there is clock sharing associated with the MyRIAD module. A more full picture of this clock distribution hierarchy is shown here.

[[File:FullSystem.png|full system clocking tree]]

==== The rules of the game as currently understood by users ====

So people know that you can hook a MyRIAD to DGS, and you can hook DFMA to DGS, and that with appropriate software incantations the clock and timestamp can be distributed from DGS to the other two systems. That is correct, and that is true, but it is not the whole and complete truth of how the firmware works.

==== How clock sharing REALLY works ====

How the clock sharing works in full detail is as follows.

* Any master trigger can be declared as the "timing monarch" that is the source of the clock.
* Which master trigger is the "timing monarch" is defined ''solely by cabling''.
** If a master trigger ''has a cable connected to it's link L'' then that master trigger can be told to be subservient to whatever is on the other end of the link L cable.
** The hierarchy is defined by what cables plug into link L of what boards.
** This is why all the master-to-router cables go from any link of the master always to link L of the router.
* There is a limit as to how far the hierarchy can descend.
** Each time the clock is sent out of a board and received by another, clock jitter accumulates with each 'hop'.
** In the DGS-DFMA setup that people are used to, there are six 'hops' to get a trigger from DFMA back to DGS when DGS is the clock source :
*** DGS to DFMA master -> DFMA master-router -> DFMA router-digitizer -> DFMA digitizer-router -> DFMA router-master -> DFMA master to DGS
*** Measurements show that the accumulated jitter per 'hop' is about 35ps.
*** So in the DGS-DFMA setup there would be a total accumulated jitter of (6*35), or 360ps.
*** The serial data stream is 1Gbps, or 1ns (1000ps) per bit.
*** If the ratio of the accumulated jitter divided by the bit period is greater than 50%, the link WILL HAVE BIT ERRORS.
** Thus the number of 'hops' in the current system is at a maximum and '''''hanging a 3rd system behind DFMA will not work'''''.

Any master trigger starts up using its own internal clock. Then, by writing a bit to a register, a master trigger agrees to use the clock that comes in on link L. The firmware has an automatic fallback provision that will cause any master trigger to fall back to using the internal clock ''irrespective of the software selection'' if there is no LOCK indication from the SERDES chip of link L. Thus it is necessary to establish the SERDES link between two master triggers and verify that link L is locked BEFORE telling the "subservient" master trigger to use the clock from link L.

=== Understanding Link usage ===

Each master trigger board has three "special" SERDES links named "L", "R" and "U". Originally this was meant to be read as "Left", "Right" and "Up" for drawing complicated link connections, but the convention of direction was abandoned unused. These three links are "special" in the sense that they are intended to be used as ''system interconnect'' links as opposed to the ''internal connections'' of links A through H. More precisely, what this means is that the data formats that these links send and receive are slightly different than the data format used to connect with routers. Each of these three links has a unique purpose and unique characteristics.

* Link L is unique in that it alone can receive a clock from an external source that can be used in place of the board's internal clock.
** Link L can receive two different data formats, either the GITMO format or the format from another master trigger.
* Link R is intended to receive data from another master trigger.
* Link U is historically used with the MyRIAD module to receive trigger information from an external detector.
** Link U can be programmed to receive data from another master trigger.

== General recipe for success ==

* Run local scripts for each system to link everybody up within each system individually.
* Adjust Input Link Mask bits on links L, R, U of cross-connected systems so that the triggers send nice data to each other.
* Adjust Sync bits on links L, R, U of cross-connected systems so that triggers send nice data to each other.
* Turn on the F1 propagation bit of the systems that are subservient to the designated timing monarch.
* Set the Clock Source of the systems that are subservient to the designated timing monarch to 'link'.
** this will cause some digitizers or routers to drop the link or have 'lost lock' errors. Reset errors and/or links as needed to re-link routers to master and then to re-link digitizers to routers as needed.
* Turn on the Imperative Sync of the timing monarch. Verify that subservient systems respond at all levels of boards (master, routers, digitizers).
* As desired, Turn on F3 (and, if needed, F4, F5, F6, etc.) Propagation Control bits in systems subservient to the timing monarch to tell the systems to listen to and process triggers sent by the timing monarch.
* As desired, Turn on F3 (and, if needed, F4, F5, F6, etc.) Propagation Control bits in the timing monarch to tell the timing monarch to listen to and process triggers sent by the subservient systems.
** the purpose of the Propagation Control bits is to select which triggers from other systems are to be listened to by the system with the Propagation Control bits.
*** The F4/5/6/etc. bits are there to allow a system to listen to multiple trigger messages from multiple algorithms if the trigger setup is that complex.
* Send test triggers and see that they occur in the other systems.
** Learn how to use the Manual Trigger bit in the Pulsed Control register and the Trig RAM logic to generate triggers at will without any beam and without any digitizers.

=== Expert diagnosis tricks ===
There is a script that allows experts to look at the raw data being received on link L, R or U of any master trigger. Experts know what the appropriate data pattern looks like.

* data pattern of constant value of 0x00FF means that the sending device still has the hardware SYNC control on.
* data pattern of constant value of 0xFF00 means that the sending device still has the Input Link Mask bit in the gray state.

== The concept of Propagation Control ==

Every master trigger is the master of its own detector. However, each master trigger that is receiving data from another master trigger from the SERDES links (L, R or U) can ''selectively propagate information received from another master trigger'' into itself. There is a '''Propagation Control''' register associated with each of the three links that is bit-wise mapped to enumerate what information is allowed to enter. This is described in the Trigger Timing and Control Link Specification document that I know you haven't read, so here's the text again.

[[File:Ttcl cutout.PNG]]

These Propagation Control registers are important not only to set up the timestamp, but also in the setting up of shared triggers across systems.

=== Timestamp sharing and Imperative Sync ===

There is a difference between sharing the CLOCK and sharing the TIMESTAMP. The timestamp logic of the subservient master trigger has a separate enable bit to allow the subservient master to respond to Imperative Sync commands sent from the "timing monarch". The precise rule here is:

* If the LINK L PROPAGATION CONTROL register, bit 0, is SET, '''and''' the subservient master has set its link L to be receiving commands from another master trigger, '''then''' the subservient master will respond only to Imperative Sync from the "timing monarch" AND cannot issue its own local Imperative Sync.
* If either of those two conditions are not met, then the subservient master, ''even if using the clock from the timing monarch'', will IGNORE any Imperative Sync from the timing monarch but CAN issue its own Imperative Sync within its own system.

== Collection of triggers from one master trigger to another ==

Each master trigger receives copies of all the 'local' (within a given detector) trigger accept messages from all the other master triggers it is connected to through links L, R and U. Hypothesize that the setup in play is Digital Gammasphere (DGS) as the "timing monarch" with DFMA and X-Array as the "subservient" master triggers. Just to fill out the example, also assume that there's some other external detector in the setup that is using a MyRIAD. Further assume that the wiring setup is as follows:

* DGS link R is connected to DFMA, link L.
* DGS link L is connected to X-Array, link L.
* DGS link U is connected to the MyRIAD in the external detector.

This is a legitimate setup because link L can be configured by writing to DGS's registers to use 'remote master' format, link R is natively 'remote master' format, and link U of DGS can be configured by writing to registers to use 'MyRIAD' format. This setup then means that the DGS master trigger has to somehow attempt to combine information not only from itself but from the other setups to make multi-system trigger accept messages. The overall data flow by which this occurs is shown in the following picture.

[[File:RemoteTriggerQueuing.png]]

== Currently Supported Cross-system Triggers ==

The important detail of the above picture is that the trigger messages coming in from links L, R and U must pass through ''Trigger Algorithms'' and only those combinations explicitly supported by the specific algorithms can create multi-detector coincidences. There are also limits, as indicated in the picture, of what trigger messages pass through to the other systems.

'''''As the firmware is currently written there is no way to perform a three- or four-system coincidence and broadcast that coincidence trigger to all systems'''''

=== Processing of information from other masters ===

Whenever a SERDES link (L, R or U) is configured to be a 'remote master' data format, the firmware has a fixed way of processing that data, shown here.

[[File:RemoteTrigAlgorithm.PNG]]

As is seen in the picture, the algorithm can perform a coincidence calculation of the trigger message ''received from that particular link'' relative to ''any of the other triggers''. The resultant coincidence then creates trigger acceptance messages FOR THAT LINK. This means that, in our example,

* DGS is receiving messages from the X-Array over link L. Thus, DGS can calculate a timestamp offset for the messages from the X-Array to compensate for time-of-flight, different integration time, etc., generate an internal pulse at the adjusted timestamp, and then perform a coincidence of that pulse with the other triggers ''at the moment they occur'' to generate an internal DGS trigger (algorithm #6).
** The Algorithm 6 trigger is sent to DGS, to DFMA and to the MyRIAD, '''but is not sent back to the X-Array to avoid infinite trigger loops'''
* DGS is receiving messages from DFMA over link R. Thus, DGS can calculate a timestamp offset for the messages from DFMA to compensate for time-of-flight, different integration time, etc., generate an internal pulse at the adjusted timestamp, and then perform a coincidence of that pulse with the other triggers ''at the moment they occur'' to generate an internal DGS trigger (algorithm #7).
** The Algorithm 7 trigger is sent to DGS, to X-Array and to the MyRIAD, '''but is not sent back to DFMA to avoid infinite trigger loops'''

The MyRIAD - link U in this example - is treated different.y.

Linking Systems Together

2024-02-29T22:24:35Z

Jta:

== Linking Multiple Systems Together ==

The trigger logic implemented for the various DAQ systems and the hardware design of the trigger module allows for the possibility to link multiple systems together. This allows both clock synchronization and trigger sharing to occur. A number of rules must be obeyed, so read carefully.

=== Clock Sharing ===

The basic method of clock sharing that most users are familiar with is that the master trigger sends clock to the routers, and the routers re-distribute that clock to the digitizers. Many users also understand that this tree of clock distribution has been extended to include Digital Gammasphere (DGS) sending the clock to DFMA, as shown here.

[[File:ClockHierarchy.png|Standard clock distribution]]

Those that have been involved from the beginning will recall that the DGS master trigger could also be connected to 'Analog' Gammasphere using the GITMO module - and use the clock from 'Analog' Gammasphere. Those that have been involved with hosting external detectors such as CHICO, Microball, ORRUBA, etc. also understand that there is clock sharing associated with the MyRIAD module. A more full picture of this clock distribution hierarchy is shown here.

[[File:FullSystem.png|full system clocking tree]]

==== The rules of the game as currently understood by users ====

So people know that you can hook a MyRIAD to DGS, and you can hook DFMA to DGS, and that with appropriate software incantations the clock and timestamp can be distributed from DGS to the other two systems. That is correct, and that is true, but it is not the whole and complete truth of how the firmware works.

==== How clock sharing REALLY works ====

How the clock sharing works in full detail is as follows.

* Any master trigger can be declared as the "timing monarch" that is the source of the clock.
* Which master trigger is the "timing monarch" is defined ''solely by cabling''.
** If a master trigger ''has a cable connected to it's link L'' then that master trigger can be told to be subservient to whatever is on the other end of the link L cable.
** The hierarchy is defined by what cables plug into link L of what boards.
** This is why all the master-to-router cables go from any link of the master always to link L of the router.
* There is a limit as to how far the hierarchy can descend.
** Each time the clock is sent out of a board and received by another, clock jitter accumulates with each 'hop'.
** In the DGS-DFMA setup that people are used to, there are six 'hops' to get a trigger from DFMA back to DGS when DGS is the clock source :
*** DGS to DFMA master -> DFMA master-router -> DFMA router-digitizer -> DFMA digitizer-router -> DFMA router-master -> DFMA master to DGS
*** Measurements show that the accumulated jitter per 'hop' is about 35ps.
*** So in the DGS-DFMA setup there would be a total accumulated jitter of (6*35), or 360ps.
*** The serial data stream is 1Gbps, or 1ns (1000ps) per bit.
*** If the ratio of the accumulated jitter divided by the bit period is greater than 50%, the link WILL HAVE BIT ERRORS.
** Thus the number of 'hops' in the current system is at a maximum and '''''hanging a 3rd system behind DFMA will not work'''''.

Any master trigger starts up using its own internal clock. Then, by writing a bit to a register, a master trigger agrees to use the clock that comes in on link L. The firmware has an automatic fallback provision that will cause any master trigger to fall back to using the internal clock ''irrespective of the software selection'' if there is no LOCK indication from the SERDES chip of link L. Thus it is necessary to establish the SERDES link between two master triggers and verify that link L is locked BEFORE telling the "subservient" master trigger to use the clock from link L.

=== Understanding Link usage ===

Each master trigger board has three "special" SERDES links named "L", "R" and "U". Originally this was meant to be read as "Left", "Right" and "Up" for drawing complicated link connections, but the convention of direction was abandoned unused. These three links are "special" in the sense that they are intended to be used as ''system interconnect'' links as opposed to the ''internal connections'' of links A through H. More precisely, what this means is that the data formats that these links send and receive are slightly different than the data format used to connect with routers. Each of these three links has a unique purpose and unique characteristics.

* Link L is unique in that it alone can receive a clock from an external source that can be used in place of the board's internal clock.
** Link L can receive two different data formats, either the GITMO format or the format from another master trigger.
* Link R is intended to receive data from another master trigger.
* Link U is historically used with the MyRIAD module to receive trigger information from an external detector.
** Link U can be programmed to receive data from another master trigger.

== The concept of Propagation Control ==

Every master trigger is the master of its own detector. However, each master trigger that is receiving data from another master trigger from the SERDES links (L, R or U) can ''selectively propagate information received from another master trigger'' into itself. There is a '''Propagation Control''' register associated with each of the three links that is bit-wise mapped to enumerate what information is allowed to enter. This is described in the Trigger Timing and Control Link Specification document that I know you haven't read, so here's the text again.

[[File:Ttcl cutout.PNG]]

These Propagation Control registers are important not only to set up the timestamp, but also in the setting up of shared triggers across systems.

=== Timestamp sharing and Imperative Sync ===

There is a difference between sharing the CLOCK and sharing the TIMESTAMP. The timestamp logic of the subservient master trigger has a separate enable bit to allow the subservient master to respond to Imperative Sync commands sent from the "timing monarch". The precise rule here is:

* If the LINK L PROPAGATION CONTROL register, bit 0, is SET, '''and''' the subservient master has set its link L to be receiving commands from another master trigger, '''then''' the subservient master will respond only to Imperative Sync from the "timing monarch" AND cannot issue its own local Imperative Sync.
* If either of those two conditions are not met, then the subservient master, ''even if using the clock from the timing monarch'', will IGNORE any Imperative Sync from the timing monarch but CAN issue its own Imperative Sync within its own system.

== Collection of triggers from one master trigger to another ==

Each master trigger receives copies of all the 'local' (within a given detector) trigger accept messages from all the other master triggers it is connected to through links L, R and U. Hypothesize that the setup in play is Digital Gammasphere (DGS) as the "timing monarch" with DFMA and X-Array as the "subservient" master triggers. Just to fill out the example, also assume that there's some other external detector in the setup that is using a MyRIAD. Further assume that the wiring setup is as follows:

* DGS link R is connected to DFMA, link L.
* DGS link L is connected to X-Array, link L.
* DGS link U is connected to the MyRIAD in the external detector.

This is a legitimate setup because link L can be configured by writing to DGS's registers to use 'remote master' format, link R is natively 'remote master' format, and link U of DGS can be configured by writing to registers to use 'MyRIAD' format. This setup then means that the DGS master trigger has to somehow attempt to combine information not only from itself but from the other setups to make multi-system trigger accept messages. The overall data flow by which this occurs is shown in the following picture.

[[File:RemoteTriggerQueuing.png]]

== Currently Supported Cross-system Triggers ==

The important detail of the above picture is that the trigger messages coming in from links L, R and U must pass through ''Trigger Algorithms'' and only those combinations explicitly supported by the specific algorithms can create multi-detector coincidences. There are also limits, as indicated in the picture, of what trigger messages pass through to the other systems.

'''''As the firmware is currently written there is no way to perform a three- or four-system coincidence and broadcast that coincidence trigger to all systems'''''

=== Processing of information from other masters ===

Whenever a SERDES link (L, R or U) is configured to be a 'remote master' data format, the firmware has a fixed way of processing that data, shown here.

[[File:RemoteTrigAlgorithm.PNG]]

As is seen in the picture, the algorithm can perform a coincidence calculation of the trigger message ''received from that particular link'' relative to ''any of the other triggers''. The resultant coincidence then creates trigger acceptance messages FOR THAT LINK. This means that, in our example,

* DGS is receiving messages from the X-Array over link L. Thus, DGS can calculate a timestamp offset for the messages from the X-Array to compensate for time-of-flight, different integration time, etc., generate an internal pulse at the adjusted timestamp, and then perform a coincidence of that pulse with the other triggers ''at the moment they occur'' to generate an internal DGS trigger (algorithm #6).
** The Algorithm 6 trigger is sent to DGS, to DFMA and to the MyRIAD, '''but is not sent back to the X-Array to avoid infinite trigger loops'''
* DGS is receiving messages from DFMA over link R. Thus, DGS can calculate a timestamp offset for the messages from DFMA to compensate for time-of-flight, different integration time, etc., generate an internal pulse at the adjusted timestamp, and then perform a coincidence of that pulse with the other triggers ''at the moment they occur'' to generate an internal DGS trigger (algorithm #7).
** The Algorithm 7 trigger is sent to DGS, to X-Array and to the MyRIAD, '''but is not sent back to DFMA to avoid infinite trigger loops'''

The MyRIAD - link U in this example - is treated different.y.

Building the Entire System

2024-02-20T02:06:13Z

Jta:

A multi-stage make is required to build the .munch files for the IOCs. Munch files are raw binary executable for the MVME5500's VxWorks operating system generated by a cross compiler. The cross compiler resides on machine con6, a Sun Solaris machine. This machine has no internal hard disk, it connects to the network file server. This means files ''can'' be copied willy-nilly but that doesn't mean they ''should'' be. Yes, physicists, I speak to you. '''DO NOT TOUCH /dk/fs2/dgs/global_sanbox EVER. NO, NEVER!!'''

=== How Gammasphere VME IOCs boot ===
Each of the VME processors in Gammasphere (VME01 - VME12) are embedded processors running the VxWorks operating system, version 5.5. For some history see https://www.windriver.com/blog/vxworks-past-and-future, but don't allow the maximally stupid concept of "upgrading" to enter your mind. Everything in the system is specifically dependent and designed for VxWorks version 5.5, and if you change that, you have contracted to spend the next 5 years of your life attempting to rebuild everything for ZERO functional gain.

When the VxWorks processors are powered on they first boot from an onboard boot loader PROM. If one has access to a console terminal window the data in the PROM may be viewed or edited. The PROM specifies the IP address, user name and location of the boot script that the VME processor will load and execute after the initial PROM boot, and also the location of the VxWorks image.

==== Boot Host for VME processors ====
Machine DGS1 is the boot host for VME processors. The VxWorks OS image and the boot scripts for all the VME processors are located on machine DGS1, starting at the folder /global/ioc.

==== Shared File System ====
Machine DGS1 and other machines in the data room use a shared file server. The /global folder on many machines is actually just a symbolic link. /global, ''depending upon which machine you log into'', may be one of '''''THREE''''' different locations on the file server:

* Machines running a 64-bit OS like Rocky Linux will map /global to /dk/fs2/dgs/global_64.
* Machines running Scientific Linux 6 (e.g. DGS1) will map /global to /dk/fs2/dgs/global_32.
* One specific machine (CON6), critical to the maintenance of the system, maps /global to /dk/fs2/dgs/global_sandbox.

== File Structure of Boot Host DGS1 ==

The root of the boot host is the folder '''/global/ioc''' that has subfolders

* bin
* boot
* db
* dbd
* dgsSoftIOC
* epics
* FW_Maint (Will be deprecated in the '''imminent''' future)
* gui

The places that change when the system is rebuilt are the '''bin''', '''boot''' and '''gui''' areas.

=== Compiling the Code used in the VME IOCs ===
# ssh -XY dgs@con6
# cd /global/devel/dgsDrivers/dgsDriverApp/src
# ./Export_SVN_ParameterFiles.sh
# cd ../..
# make clean
# make
## There should be ZERO errors and ZERO warnings. Anything else is a fatal, full, stop.
# cd ../dgsIoc
# make clean
# make
## There should be ZERO errors and ZERO warnings. Anything else is a fatal, full, stop.
# Log out of con6
# Log into dgs1 as dgs
# cd /global/ioc/bin/vxWorks-ppc604_long
# ./CopyNewMunch.sh

=== Ensuring EPICS databases are up to date ===
# ssh -XY dgs@dgs1
# cd /global/ioc/db
# ./Export_SVN_Databases.sh
# You will have to reboot all the VME IOCs to load the new databases.
# You will have to stop and restart the Soft IOC to load the new databases

=The entire sequence from spreadsheet to boot=

==Spreadsheet general path==

* Checkout or update a local working copy of https://svn.inside.anl.gov/repos/psg/CodeGeneratingSpreadsheetsGeneric onto a Windows PC.
* Make any modifications to the spreadsheet needed to update desired functionality in firmware, EPICS, C structs, etc.
* There are different projects for every kind of FPGA/board.
* After the spreadsheet is run then the entire folder tree for the project must be committed to SVN.

===Spreadsheet outputs===

A spreadsheet for the digitizer or the master trigger or the router trigger has a folder '''SS_output''' that contains all of its output products.
The output products of interest for the Area IV data acquisition systems are

====files for rebuilding the VxWorks driver====
* asyn<boardtype>Params.c
* asyn<boardtype>Params.h

The Solaris machine 'con6' has no 'svn' program installed on it, so some other machine that has 'svn' must be used to pull the files down.
This is done by

* cd /dk/fs2/dgs/global_sandbox/devel/dgsDrivers/dgsDriverApp/src
* ./Export_Parameter_Files_from_dgs1.sh

After you have exported the parameter files, then compile as described above.

Once you have successfully compiled, then you must go to the '''boot machine''' (e.g. DGS1) and do the following:

* cd /global/ioc/bin/vxWorks-ppc604_long
* ./CopyNewMunch.sh

====files used by the VME IOCs to generate PVs====
* <boardtype>Registers.template
* <boardtype>User.template
* A series of 'VMExx.db' files (however many were defined in the system definition file of the spreadsheet)

These files must be exported from SVN to the folder on the boot host machine (e.g. dgs1) for use by the VME IOC processor
during the boot of that specific processor. This is done by

* cd /global/ioc/db
* ./Export_SVN_Databases.sh

====files used by the Soft IOC (run on the host machine, e.g. DGS1)====
* JustGlobals.db

This file must be exported from SVN to the folder on the boot host machine where the Soft IOC resides. This is done by

* cd /global/ioc/dgsSoftIOC/db
* ./Export_SVN_SoftIOC_Database.sh

Building the Entire System

2024-02-20T02:03:31Z

Jta:

A multi-stage make is required to build the .munch files for the IOCs. Munch files are raw binary executable for the MVME5500's VxWorks operating system generated by a cross compiler. The cross compiler resides on machine con6, a Sun Solaris machine. This machine has no internal hard disk, it connects to the network file server. This means files ''can'' be copied willy-nilly but that doesn't mean they ''should'' be. Yes, physicists, I speak to you. '''DO NOT TOUCH /dk/fs2/dgs/global_sanbox EVER. NO, NEVER!!'''

=== How Gammasphere VME IOCs boot ===
Each of the VME processors in Gammasphere (VME01 - VME12) are embedded processors running the VxWorks operating system, version 5.5. For some history see https://www.windriver.com/blog/vxworks-past-and-future, but don't allow the maximally stupid concept of "upgrading" to enter your mind. Everything in the system is specifically dependent and designed for VxWorks version 5.5, and if you change that, you have contracted to spend the next 5 years of your life attempting to rebuild everything for ZERO functional gain.

When the VxWorks processors are powered on they first boot from an onboard boot loader PROM. If one has access to a console terminal window the data in the PROM may be viewed or edited. The PROM specifies the IP address, user name and location of the boot script that the VME processor will load and execute after the initial PROM boot, and also the location of the VxWorks image.

==== Boot Host for VME processors ====
Machine DGS1 is the boot host for VME processors. The VxWorks OS image and the boot scripts for all the VME processors are located on machine DGS1, starting at the folder /global/ioc.

==== Shared File System ====
Machine DGS1 and other machines in the data room use a shared file server. The /global folder on many machines is actually just a symbolic link. /global, ''depending upon which machine you log into'', may be one of '''''THREE''''' different locations on the file server:

* Machines running a 64-bit OS like Rocky Linux will map /global to /dk/fs2/dgs/global_64.
* Machines running Scientific Linux 6 (e.g. DGS1) will map /global to /dk/fs2/dgs/global_32.
* One specific machine (CON6), critical to the maintenance of the system, maps /global to /dk/fs2/dgs/global_sandbox.

== File Structure of Boot Host DGS1 ==

The root of the boot host is the folder '''/global/ioc''' that has subfolders

* bin
* boot
* db
* dbd
* dgsSoftIOC
* epics
* FW_Maint (Will be deprecated in the '''imminent''' future)
* gui

The places that change when the system is rebuilt are the '''bin''', '''boot''' and '''gui''' areas.

=== Compiling the Code used in the VME IOCs ===
# ssh -XY dgs@con6
# cd /global/devel/dgsDrivers/dgsDriverApp/src
# ./Export_SVN_ParameterFiles.sh
# cd ../..
# make clean
# make
## There should be ZERO errors and ZERO warnings. Anything else is a fatal, full, stop.
# cd ../dgsIoc
# make clean
# make
## There should be ZERO errors and ZERO warnings. Anything else is a fatal, full, stop.
# Log out of con6
# Log into dgs1 as dgs
# cd /global/ioc/bin/vxWorks-ppc604_long
# ./CopyNewMunch.sh

=== Ensuring EPICS databases are up to date ===
# ssh -XY dgs@dgs1
# cd /global/ioc/db
# ./Export_SVN_Databases.sh
# You will have to reboot all the VME IOCs to load the new databases.
# You will have to stop and restart the Soft IOC to load the new databases

=The entire sequence from spreadsheet to boot=

==Spreadsheet general path==

* Checkout or update a local working copy of https://svn.inside.anl.gov/repos/psg/CodeGeneratingSpreadsheetsGeneric onto a Windows PC.
* Make any modifications to the spreadsheet needed to update desired functionality in firmware, EPICS, C structs, etc.
* There are different projects for every kind of FPGA/board.
* After the spreadsheet is run then the entire folder tree for the project must be committed to SVN.

===Spreadsheet outputs===

A spreadsheet for the digitizer or the master trigger or the router trigger has a folder '''SS_output''' that contains all of its output products.
The output products of interest for the Area IV data acquisition systems are

====files for rebuilding the VxWorks driver====
* asyn<boardtype>Params.c
* asyn<boardtype>Params.h

The Solaris machine 'con6' has no 'svn' program installed on it, so some other machine that has 'svn' must be used to pull the files down.
This is done by

* cd /dk/fs2/dgs/global_sandbox/devel/dgsDrivers/dgsDriverApp/src
* ./Export_Parameter_Files_from_dgs1.sh

====files used by the VME IOCs to generate PVs====
* <boardtype>Registers.template
* <boardtype>User.template
* A series of 'VMExx.db' files (however many were defined in the system definition file of the spreadsheet)

These files must be exported from SVN to the folder on the boot host machine (e.g. dgs1) for use by the VME IOC processor
during the boot of that specific processor. This is done by

* cd /global/ioc/db
* ./Export_SVN_Databases.sh

====files used by the Soft IOC (run on the host machine, e.g. DGS1)====
* JustGlobals.db

This file must be exported from SVN to the folder on the boot host machine where the Soft IOC resides. This is done by

* cd /global/ioc/dgsSoftIOC/db
* ./Export_SVN_SoftIOC_Database.sh

Building the Entire System

2024-02-20T01:02:07Z

Jta:

A multi-stage make is required to build the .munch files for the IOCs. Munch files are raw binary executable for the MVME5500's VxWorks operating system generated by a cross compiler. The cross compiler resides on machine con6, a Sun Solaris machine. This machine has no internal hard disk, it connects to the network file server. This means files ''can'' be copied willy-nilly but that doesn't mean they ''should'' be. Yes, physicists, I speak to you. '''DO NOT TOUCH /dk/fs2/dgs/global_sanbox EVER. NO, NEVER!!'''

=== How Gammasphere VME IOCs boot ===
Each of the VME processors in Gammasphere (VME01 - VME12) are embedded processors running the VxWorks operating system, version 5.5. For some history see https://www.windriver.com/blog/vxworks-past-and-future, but don't allow the maximally stupid concept of "upgrading" to enter your mind. Everything in the system is specifically dependent and designed for VxWorks version 5.5, and if you change that, you have contracted to spend the next 5 years of your life attempting to rebuild everything for ZERO functional gain.

When the VxWorks processors are powered on they first boot from an onboard boot loader PROM. If one has access to a console terminal window the data in the PROM may be viewed or edited. The PROM specifies the IP address, user name and location of the boot script that the VME processor will load and execute after the initial PROM boot, and also the location of the VxWorks image.

==== Boot Host for VME processors ====
Machine DGS1 is the boot host for VME processors. The VxWorks OS image and the boot scripts for all the VME processors are located on machine DGS1, starting at the folder /global/ioc.

==== Shared File System ====
Machine DGS1 and other machines in the data room use a shared file server. The /global folder on many machines is actually just a symbolic link. /global, ''depending upon which machine you log into'', may be one of '''''THREE''''' different locations on the file server:

* Machines running a 64-bit OS like Rocky Linux will map /global to /dk/fs2/dgs/global_64.
* Machines running Scientific Linux 6 (e.g. DGS1) will map /global to /dk/fs2/dgs/global_32.
* One specific machine (CON6), critical to the maintenance of the system, maps /global to /dk/fs2/dgs/global_sandbox.

== File Structure of Boot Host DGS1 ==

The root of the boot host is the folder '''/global/ioc''' that has subfolders

* bin
* boot
* db
* dbd
* dgsSoftIOC
* epics
* FW_Maint (Will be deprecated in the '''imminent''' future)
* gui

The places that change when the system is rebuilt are the '''bin''', '''boot''' and '''gui''' areas.

=== Compiling the Code used in the VME IOCs ===
# ssh -XY dgs@con6
# cd /global/devel/dgsDrivers/dgsDriverApp/src
# ./Export_SVN_ParameterFiles.sh
# cd ../..
# make clean
# make
## There should be ZERO errors and ZERO warnings. Anything else is a fatal, full, stop.
# cd ../dgsIoc
# make clean
# make
## There should be ZERO errors and ZERO warnings. Anything else is a fatal, full, stop.
# Log out of con6
# Log into dgs1 as dgs
# cd /global/ioc/bin/vxWorks-ppc604_long
# ./CopyNewMunch.sh

=== Ensuring EPICS databases are up to date ===
# ssh -XY dgs@dgs1
# cd /global/ioc/db
# ./Export_SVN_Databases.sh
# You will have to reboot all the VME IOCs to load the new databases.
# You will have to stop and restart the Soft IOC to load the new databases

=The entire sequence from spreadsheet to boot=

==Spreadsheet general path==

* Checkout or update a local working copy of https://svn.inside.anl.gov/repos/psg/CodeGeneratingSpreadsheetsGeneric onto a Windows PC.
* Make any modifications to the spreadsheet needed to update desired functionality in firmware, EPICS, C structs, etc.
* There are different projects for every kind of FPGA/board.

===Spreadsheet outputs===

A spreadsheet for the digitizer or the master trigger or the router trigger has a folder '''SS_output''' that contains all of its output products.
The output products of interest for the Area IV data acquisition systems are

* <boardtype>Registers.template
* <boardtype>User.template
* A series of VMExx.db files (however many were defined in the system definition file of the spreadsheet)
* A 'JustGlobals.db' file for use by the Soft IOC

Building the Entire System

2024-02-19T23:49:38Z

Jta: /* File Structure of Boot Host DGS1 */

Building the Entire System

2024-02-19T23:45:50Z

Jta:

A multi-stage make is required to build the .munch files for the IOCs. Munch files are raw binary executable for the MVME5500's VxWorks operating system generated by a cross compiler. The cross compiler resides on machine con6, a Sun Solaris machine. This machine has no internal hard disk, it connects to the network file server. This means files ''can'' be copied willy-nilly but that doesn't mean they ''should'' be. Yes, physicists, I speak to you. '''DO NOT TOUCH /dk/fs2/dgs/global_sanbox EVER. NO, NEVER!!'''

=== How Gammasphere VME IOCs boot ===
Each of the VME processors in Gammasphere (VME01 - VME12) are embedded processors running the VxWorks operating system, version 5.5. For some history see https://www.windriver.com/blog/vxworks-past-and-future, but don't allow the maximally stupid concept of "upgrading" to enter your mind. Everything in the system is specifically dependent and designed for VxWorks version 5.5, and if you change that, you have contracted to spend the next 5 years of your life attempting to rebuild everything for ZERO functional gain.

When the VxWorks processors are powered on they first boot from an onboard boot loader PROM. If one has access to a console terminal window the data in the PROM may be viewed or edited. The PROM specifies the IP address, user name and location of the boot script that the VME processor will load and execute after the initial PROM boot, and also the location of the VxWorks image.

==== Boot Host for VME processors ====
Machine DGS1 is the boot host for VME processors. The VxWorks OS image and the boot scripts for all the VME processors are located on machine DGS1, starting at the folder /global/ioc.

==== Shared File System ====
Machine DGS1 and other machines in the data room use a shared file server. The /global folder on many machines is actually just a symbolic link. /global, ''depending upon which machine you log into'', may be one of '''''THREE''''' different locations on the file server:

* Machines running a 64-bit OS like Rocky Linux will map /global to /dk/fs2/dgs/global_64.
* Machines running Scientific Linux 6 (e.g. DGS1) will map /global to /dk/fs2/dgs/global_32.
* One specific machine (CON6), critical to the maintenance of the system, maps /global to /dk/fs2/dgs/global_sandbox.

== File Structure of Boot Host DGS1 ==

<nowiki>
[dgs@dgs1 ioc]$ pwd
/global/ioc
[dgs@dgs1 ioc]$ ls -la
total 220
drwxrwxr-x. 10 dgs dgs 14 Feb 19 15:06 ./
drwxrwxr-x. 11 dgs dgs 14 Sep 28 19:27 ../
drwxrwxr-x. 3 dgs dgs 3 Mar 30 2023 bin/
drwxrwxr-x. 3 dgs dgs 68 Sep 21 18:50 boot/
-rwxrwxr-x. 1 dgs dgs 386 Mar 30 2023 Copy_from_sandbox.sh*
-rwxrwxr-x. 1 dgs dgs 924 Mar 30 2023 Copy_from_svn_checkout.sh*
drwxrwxr-x. 2 dgs dgs 32 Feb 5 16:02 db/
drwxrwxr-x. 2 dgs dgs 3 Feb 19 17:32 dbd/
drwxrwxr-x. 10 dgs dgs 11 Sep 20 13:57 dgsSoftIOC/
drwxrwxr-x. 3 dgs dgs 3 Apr 5 2023 epics/
drwxrwxr-x. 6 dgs dgs 8 Sep 8 16:12 FW_Maint/
drwxrwxr-x. 6 dgs dgs 22 Feb 16 16:36 gui/
-rw-rw-r--. 1 dgs dgs 275916 Feb 19 15:06 tempfile.tmp
-rw-rw-r--. 1 dgs dgs 6321 Sep 8 14:45 WikiExtract.txt
[dgs@dgs1 ioc]$
</nowiki>

=== Compiling the Code used in the VME IOCs ===
# ssh -XY dgs@con6
# cd /global/devel/dgsDrivers/dgsDriverApp/src
# ./Export_SVN_ParameterFiles.sh
# cd ../..
# make clean
# make
## There should be ZERO errors and ZERO warnings. Anything else is a fatal, full, stop.
# cd ../dgsIoc
# make clean
# make
## There should be ZERO errors and ZERO warnings. Anything else is a fatal, full, stop.
# Log out of con6
# Log into dgs1 as dgs
# cd /global/ioc/bin/vxWorks-ppc604_long
# ./CopyNewMunch.sh

=== Ensuring EPICS databases are up to date ===
# ssh -XY dgs@dgs1
# cd /global/ioc/db
# ./Export_SVN_Databases.sh
# You will have to reboot all the VME IOCs to load the new databases.
# You will have to stop and restart the Soft IOC to load the new databases.

Collector Box

2024-01-10T21:03:18Z

Jta: /* In Each Collector Box */

<imagemap>
Image:Collectorbox.png|thumb|400px|Figure 1. One of the collector boxes on Gammasphere, circled in white; yellow-encased power supply above collector box and gray VME crate below.
poly 295 352 296 401 372 420 370 359 325 363 [[VME Crates]]
poly 431 272 417 283 416 315 456 323 463 351 487 352 537 326 537 257 488 285 [[VME Crates]]
</imagemap>
As a part of [[Gammasphere]]'s upgraded [[DAQ system]], a new "collector box" has been added. The collector box collects and maps all analog [[Detector Signals|signals]] for up to 30 [[Gammasphere Detectors|detectors]], coming from the pickoff card in the [[The Slope Box Extension|SBX]] to the collector, and being output to the [[Gammasphere Detectors|digitizers]]. For concepts like [[Detector Signals|"electric honeycomb"]], the collector box implements distinct hardware to accurately route signals to the digitizer. It does this this by utilizing time synchronization with its access to the trigger system to ensure that the correct set of samples are used for the reconstruction of each BGO waveform. Control and monitoring of Gammasphere's modules are maintained with the help of the collector box, using EPICS IOC. It provides power to individual SBX units via a singular 48V input from the power supply (above the circled collector box in the image to the right).

The collector box was created to replace the system that preceded it, known as VXI crates. They consisted of multiple boards and racks, including over a hundred heavy, 60-foot multi-conductor cables that were draped all around Gammasphere. Detector [[The Slope Box|slope boxes]] were connected directly to an entirely separate system called the VXI system, which would convert the signals to digitizer-readable differential signals before sending them off to "VXI digitizers". The VXI system had an entire "shack" designated to it, whereas the collector box upgrade can now be attached directly to Gammasphere's chassis and contain the DAQ system near the detectors. The previous system took up physical space within the room and presented a heat issue as well as multiple obsolescence risks and possibilities of power supply failure. The collector box eliminates these risks, and physically and digitally optimizes the overall system.

==Collector Box Hardware==
===Throughout Gammasphere===
[[File:CollectorBoxesLayout.png|left|800px|thumb|Figure 2. A top-view mapping of Gammasphere's collector box setup.]]
Figure 1 shows a hemisphere of Gammasphere, and two of the collector boxes placed on it. On the other side of Gammasphere, there are another two collector boxes with the rest of the DAQ (the full picture is displayed on the [[DAQ system]] page). This is because Gammasphere has four pairs of collector boxes and VME crates (along with the power supply), each of which power and receive data from approximately 30 detectors. Figure 2 shows all of this from an above point of view; an "unfolded” drawing of how this mapping looks when viewing collectors and VME crates from their “active sides” where connections happen. Each collector box is shown (in the diagram) from the connector side, where cables are plugged in from the collector box to each [[The Slope Box Extension|SBX]] for power output. The output is accomplished using the same cable interfaces as used for the analog signal path, slow control-and-monitoring and all other detector functionality. All four collector boxes of Gammasphere are paired with their VME crate from their "active side", where the arrangement of digitizers, IOCs, and trigger modules are carefully placed. The collector boxes are labeled with the “GS#” they appear as in EPICS, with even “GS” numbers on the south hemisphere and odd “GS” numbers on the northern hemisphere. The semicircle “N” in Figure 2 represents the Gammasphere’s northern hemisphere, while “S” represents Gammasphere’s southern hemisphere. The compass directions in purple (NE, NW, SE, SW) are as in the current in-front-of-[[Argonne Gas-Filled Analyzer|AGFA]] position. The collector boxes and VME crates are flipped right-to-left when comparing East versus West because the collector boxes are rotated 180 degrees in the birds’ eye view. Note that Figure 2 is giving a closeup of the system, but Figure 1 represents what the DAQ system actually looks like in real life. Although not shown in the Figure 2 diagram, each collector box also provides a connection for hooking up the alarm and status outputs from the external 48V DC supply, so that the collector can make that data available to the control system via the [[DGS Commander EPICS Screens|EPICS interface]].

===In Each Collector Box===
[[File:CollectorBoxHardware.png|600px|thumb|Figure 3. Collector box hardware]]
Observing Figure 2, one can note from each collector box that there are 30 output cables, each boxed in the diagram into groups of three. This is because there are six FPGAs (field-programmable gate arrays) programmed to handle 5 detectors at a time in units called "stripes". The Collector Box maps the four differential signals from the Pickoff to specified digitizer channels, while distributing 48V Power to individual SBX Units. Built-in ground fault circuits periodically monitor continuity between the DVI cable shield and Earth ground, as ground loops are another known source of degraded performance. A distinct FPGA collects all BGO discriminator bits, calculates the [[Detector Signals|Electric Honeycomb]] for nearest neighbor Compton Suppression, and sends the information to a dedicated router of the trigger system via fiber optic cable. This Electric Honeycomb increases Compton suppression by up to 10% @ 1 MeV. With the Electric Honeycomb now supported by a distinct Trigger module, two of the four digitized channels have multiple options for readout. The Ge center and BGO sum will always remain fixed, but the other two can be assigned to the Ge sides, the BGO Hit Pattern, or to a copy of the Ge center at a fixed energy range (of 8 or 20 MeV). The collector box routes these values to the "front boards" to the digitizers in the [[VME Crates]].

''Go back to [[DAQ system]]''

Run procedures

2023-09-20T21:27:55Z

Jta: Removed incorrect commentary.

==start DAQ==

There are 3 controls associated with Run Control on the main page of either GUI

* Start/Stop - this is self explanatory. Pushing to start begins taking data.
* NoSave/Save - If set to Save, IOC buffers fill with data.

To start the DGS and DFMA systems you usually do the following:

* on the DGS side, find the window where the DGS data is stored. There will be a start.sh script there. Start the receivers up by typing

start.sh <runNo>

where <runNo> is the run number you want. A bunch of windows should show up, one for each receiver/IOC pair

* On the DFMA side, find the where the DFMA data is stored. There will be a start.sh script there. Start the receivers up by typing

start.sh <runNo>

where <runNo> is the run number you want, the same as what you used on the DGS side please. A bunch of windows should show up, one for each receiver/IOC pair now in the FMA setup

* If necessary, synch the clocks of the two systems by clicking on the Impeartive sync button on the DGS side. Please don't click on the Impeartive sync button on the DFMA side or bad things will happen...

* now, as simultaneous as you can, click the start buttons on the DGS and DFMA DAQ windows. You shoImpeartiveuld see the receivers on both systems receiving data.

* may want to check that the data files are growing to be sure data is coming in

* check that the dssd_liveTS show the same numbers on both sides (FMA-GS-Sync) on Darek computer

If not : click on imp sync (GS side) but this should not happen very often

*Check the digitizers counters at the FMA show the same
stop runs in both sides : click on stop in the commander windows
and then stop the receivers : type Ctrl C on all the receivers (IOC1, OIC2 ....)
numbers on the left side of the window (AcEvCnt- AcHtCnt-DsCnt) and all dizitizers (right 3 raws of the window)

* Check the MaterDiag counters : should show numbers if the beam is on

* Check Sender Summary (VME SummaryDFMA window), the IOC's should keep updating at DGS

==stop DAQ==
stop the run on both sides : click on stop in the commander windows

and then stop the receivers : type Ctrl-C on all the receivers (IOC1, OIC2 ....)

==Linking two or more systems==

write your instructions here

==syncing two systems==

For DGS

* Goto trig0 window.
* Turn off SYNC U - listed under LRU Control
* Make sure receive/send power is on for L & U

'''Note:''' If SYNC U is turned off - an Impeartive sync by DGS will reset the master clock on DFMA.

For DFMA

* Goto Trig0 Window
* Under Misc Control - turn on both undefined buttons
* Pull up diagnotsitc window on trig0.
* Set Clrk Source to LINK
* Set Nim1 and Nim2 out on master trigger module FMA

'''Note:''' Clock Source cannot be set to LINK in GUI. Set address 0x8D0 in slot 0 to set 1 for trigger modules. This needs to be fixed in Driver by Tim.

Building the Entire System

2023-09-20T19:01:04Z

Jta:

Building the Entire System

2023-09-20T18:13:13Z

Jta:

Updating Firmware in Digitizers and Triggers

2023-09-08T20:23:23Z

Jta:

==Some more notes about flashing digitizers or triggers:==
# Log into dgs account on dgs1
# Get the *.bin from directory /Digitizer/MAIN_FPGA/Work11_DGS
## We have 4 flavors, MSTR_digitizer, SLAVE_digitizer, trigger_top and router_top
# copy to /home/dgs/tmadden/DGSDigFirmware or /home/dgs/tmadden/DGSTrigFirmware
## You can rename file to reflect the date compiled e.g. MSTR_digitizer_2020722.bin
# cd /home/dgs/tmadden/swWork/workspace/epicsClient/src
# issue following: java -classpath jca-2.3.5.jar:caj-1.1.9.jar:fpgasender.jar plotControl 
# copy and paste below

epics.epics_init(); 
var fn0=new String("/home/dgs/tmadden/swWork/workspace/epicsClient/src/asynRecords.txt"); 
var fn1=new String("/home/dgs/tmadden/retfile.bin"); 
epics.connectPVs(fn0); 
var digware=new String("/home/dgs/tmadden/DGSDigFirmware/MSTR_digitizer_20200722.bin"); 
var slvware=new String("/home/dgs/tmadden/DGSDigFirmware/SLAVE_digitizer_20200602.bin"); 
var mastware=new String("/home/dgs/tmadden/DGSTrigFirmware/trigger_top_20160626.bin"); 
var routware=new String("/home/dgs/tmadden/DGSTrigFirmware/router_top_20160601.bin"); 

-'''NOTE: Need to define add current name of master, slave digitizer bin files and trigger & router bin file names''' 
-'''NOTE: If bin file name is wrong, program will still try to flash and result will be yellow fever.''' 
-'''NOTE: The asynRecords.txt file defines the active crates. If you get a missing PV during setup, edit this file or better yet, make a new one and assign it instead.''' 

If you get this far, you are now ready to flash the individual digitizers

* To flash digitizer type epics.sendFpga(digware, fn1, 1, 0,1, 1, 1);
** This line sends the firmware file defined in digware to the board.
** The args of the function are defined as: epics.sendFgga(Firmwarename, ret file name, Crate num, Board num, erase, program, verify)
** IN the above function, we send digware to crate 1, board 0 and erase, program and verify the fpga.
* To Update the FPGA so it runs the new firmware. ON the dig boards there is a PV called GLBL:DIG:config_main_fpga that will reconfigure ALL digitizer FPGAs in DGS. This is convenient.
* To update a single FPGA, say in VME1, we use VME01:DIG1:config_main_fpga. Simple write a 1 to these PVs to reconfig the FPGAs.
* For the Trigger crate, a power cycle is needed but power cycle also works for digitizers too. 

==Below are cut and paste commands to use with DGS or DFMA ==
=== Trigger and Routers ===
'''For master trigger''' 
epics.sendFpga(mastware, fn1, 0, 0,1, 1, 1); 

'''For routers''' 
epics.sendFpga(routware, fn1, 0, 1,1, 1, 1); 
epics.sendFpga(routware, fn1, 0, 2,1, 1, 1); 
epics.sendFpga(routware, fn1, 0, 3,1, 1, 1); 

'''add these for FMA''' 

epics.sendFpga(routware, fn1, 0, 4,1, 1, 1); 
epics.sendFpga(routware, fn1, 0, 5,1, 1, 1); 

===DGS Digitizers===
'''master digitzers''' 
epics.sendFpga(digware, fn1, 1, 0, 1,1,0); 
epics.sendFpga(digware, fn1, 1, 2, 1,1,0); 
epics.sendFpga(digware, fn1, 2, 0, 1,1,0); 
epics.sendFpga(digware, fn1, 2, 2, 1,1,0); 
epics.sendFpga(digware, fn1, 3, 0, 1,1,0); 
epics.sendFpga(digware, fn1, 3, 2, 1,1,0); 
epics.sendFpga(digware, fn1, 4, 0, 1,1,0); 
epics.sendFpga(digware, fn1, 4, 2, 1,1,0); 
epics.sendFpga(digware, fn1, 5, 0, 1,1,0); 
epics.sendFpga(digware, fn1, 5, 2, 1,1,0); 
epics.sendFpga(digware, fn1, 6, 0, 1,1,0); 
epics.sendFpga(digware, fn1, 7, 0, 1,1,0); 
epics.sendFpga(digware, fn1, 7, 2, 1,1,0); 
epics.sendFpga(digware, fn1, 8, 0, 1,1,0); 
epics.sendFpga(digware, fn1, 8, 2, 1,1,0); 
epics.sendFpga(digware, fn1, 9, 0, 1,1,0); 
epics.sendFpga(digware, fn1, 9, 2, 1,1,0); 
epics.sendFpga(digware, fn1, 10, 0, 1,1,0); 
epics.sendFpga(digware, fn1, 11, 0, 1,1,0); 
epics.sendFpga(digware, fn1, 11, 2, 1,1,0); 
epics.sendFpga(digware, fn1, 12, 0, 1,1,0); 
epics.sendFpga(digware, fn1, 12, 2, 1,1,0); 
'''slave digitzers''' 
epics.sendFpga(slvware, fn1, 1, 1, 1,1,0); 
epics.sendFpga(slvware, fn1, 1, 3, 1,1,0); 
epics.sendFpga(slvware, fn1, 2, 1, 1,1,0); 
epics.sendFpga(slvware, fn1, 2, 3, 1,1,0); 
epics.sendFpga(slvware, fn1, 3, 1, 1,1,0); 
epics.sendFpga(slvware, fn1, 3, 3, 1,1,0); 
epics.sendFpga(slvware, fn1, 4, 1, 1,1,0); 
epics.sendFpga(slvware, fn1, 4, 3, 1,1,0); 
epics.sendFpga(slvware, fn1, 5, 1, 1,1,0); 
epics.sendFpga(slvware, fn1, 5, 3, 1,1,0); 
epics.sendFpga(slvware, fn1, 6, 1, 1,1,0); 
epics.sendFpga(slvware, fn1, 7, 1, 1,1,0); 
epics.sendFpga(slvware, fn1, 7, 3, 1,1,0); 
epics.sendFpga(slvware, fn1, 8, 1, 1,1,0); 
epics.sendFpga(slvware, fn1, 8, 3, 1,1,0); 
epics.sendFpga(slvware, fn1, 9, 1, 1,1,0); 
epics.sendFpga(slvware, fn1, 9, 3, 1,1,0); 
epics.sendFpga(slvware, fn1, 10, 1, 1,1,0); 
epics.sendFpga(slvware, fn1, 11, 1, 1,1,0); 
epics.sendFpga(slvware, fn1, 11, 3, 1,1,0); 
epics.sendFpga(slvware, fn1, 12, 1, 1,1,0); 
epics.sendFpga(slvware, fn1, 12, 3, 1,1,0); 

===For Non-Slave Configuration (FMA):===
 
epics.sendFpga(digware, fn1, 1, 0, 1,1,1); 
epics.sendFpga(digware, fn1, 1, 1, 1,1,1); 
epics.sendFpga(digware, fn1, 1, 2, 1,1,1); 
epics.sendFpga(digware, fn1, 1, 3, 1,1,1); 
epics.sendFpga(digware, fn1, 2, 0, 1,1,1); 
epics.sendFpga(digware, fn1, 2, 1, 1,1,1); 
epics.sendFpga(digware, fn1, 2, 2, 1,1,1); 
epics.sendFpga(digware, fn1, 2, 3, 1,1,1); 
epics.sendFpga(digware, fn1, 3, 0, 1,1,1); 
epics.sendFpga(digware, fn1, 3, 1, 1,1,1); 
epics.sendFpga(digware, fn1, 3, 2, 1,1,1); 
epics.sendFpga(digware, fn1, 3, 3, 1,1,1); 
epics.sendFpga(digware, fn1, 4, 0, 1,1,1); 
epics.sendFpga(digware, fn1, 4, 1, 1,1,1); 
epics.sendFpga(digware, fn1, 4, 2, 1,1,1); 
epics.sendFpga(digware, fn1, 4, 3, 1,1,1); 
epics.sendFpga(digware, fn1, 5, 0, 1,1,1); 
epics.sendFpga(digware, fn1, 5, 1, 1,1,1); 
epics.sendFpga(digware, fn1, 5, 2, 1,1,1); 
epics.sendFpga(digware, fn1, 5, 3, 1,1,1); 
epics.sendFpga(digware, fn1, 6, 0, 1,1,1); 
epics.sendFpga(digware, fn1, 6, 1, 1,1,1); 
epics.sendFpga(digware, fn1, 6, 2, 1,1,1); 
epics.sendFpga(digware, fn1, 6, 3, 1,1,1); 
epics.sendFpga(digware, fn1, 7, 0, 1,1,1); 
epics.sendFpga(digware, fn1, 7, 1, 1,1,1); 
epics.sendFpga(digware, fn1, 7, 2, 1,1,1); 
epics.sendFpga(digware, fn1, 7, 3, 1,1,1); 
epics.sendFpga(digware, fn1, 8, 0, 1,1,1); 
epics.sendFpga(digware, fn1, 8, 1, 1,1,1); 
epics.sendFpga(digware, fn1, 8, 2, 1,1,1); 
epics.sendFpga(digware, fn1, 8, 3, 1,1,1); 
epics.sendFpga(digware, fn1, 9, 0, 1,1,1); 
epics.sendFpga(digware, fn1, 9, 1, 1,1,1); 
epics.sendFpga(digware, fn1, 9, 2, 1,1,1); 
epics.sendFpga(digware, fn1, 9, 3, 1,1,1);

Firmware documentation

2023-07-19T01:10:14Z

Jta:

"User manual" type documentation is provided here. Newer versions may be present on the DGS Subversion repository as updating of this page is a manual process.

* [[file:DGS_trigger_system_firmware_user_guide.pdf]] was uploaded by JTA on 20180501.

* [[file:MYRIAD_Module_Specification.pdf]] was uploaded by JTA on 20180501.

* [[file:ANL_Firmware_for_LBL_Digitizer.pdf]] was uploaded by JTA on 20180501.

** '' '''Scientists should first read''' '' [[file:Non-Expert_ANL_Firmware_-_ANL_version.pdf]] as this provides a shorter summary of features and is easier to digest.
** If you want to know more after the Non-Expert document '' '''then''' '' read [[file:ANL_Digitizer_Firmware_for_Experts.pdf]] for further details about how the firmware works.
** These two documents are newer than [[file:ANL_Firmware_for_LBL_Digitizer.pdf]] and present firmware changes that have occurred since this document was written.

* [[file:20160418_trig_command_link.pdf]] was uploaded by JTA on 20180501.

* [[file:CPLD_sum_logic.pdf]] was uploaded by JTA on 20180501.

* [[file:Interfacing_Digital_Gammasphere_with_other_detectors_and_systems.pdf]] was uploaded by JTA on 20180501.

* [[file:TripletPulseNotesTake2.pdf]] was uploaded by JTA on 20180501. This document demonstrates using the Digitizer Tester to show the effects of integration time and readout length settings on complex waveforms.

''Go back to [[Digital Gammasphere Upgrade Project]]''

File:ANL Digitizer Firmware for Experts.pdf

2023-07-19T01:07:35Z

Jta:

Firmware documentation

2023-07-19T01:06:47Z

Jta:

"User manual" type documentation is provided here. Newer versions may be present on the DGS Subversion repository as updating of this page is a manual process.

* [[file:DGS_trigger_system_firmware_user_guide.pdf]] was uploaded by JTA on 20180501.

* [[file:MYRIAD_Module_Specification.pdf]] was uploaded by JTA on 20180501.

* [[file:ANL_Firmware_for_LBL_Digitizer.pdf]] was uploaded by JTA on 20180501.

** '' '''Scientists should first read''' '' [[file:Non-Expert_ANL_Firmware_-_ANL_version.pdf]] as this provides a shorter summary of features and is easier to digest.

* [[file:20160418_trig_command_link.pdf]] was uploaded by JTA on 20180501.

* [[file:CPLD_sum_logic.pdf]] was uploaded by JTA on 20180501.

* [[file:Interfacing_Digital_Gammasphere_with_other_detectors_and_systems.pdf]] was uploaded by JTA on 20180501.

* [[file:TripletPulseNotesTake2.pdf]] was uploaded by JTA on 20180501. This document demonstrates using the Digitizer Tester to show the effects of integration time and readout length settings on complex waveforms.

''Go back to [[Digital Gammasphere Upgrade Project]]''

Firmware documentation

2023-07-19T01:06:27Z

Jta:

"User manual" type documentation is provided here. Newer versions may be present on the DGS Subversion repository as updating of this page is a manual process.

* [[file:DGS_trigger_system_firmware_user_guide.pdf]] was uploaded by JTA on 20180501.

* [[file:MYRIAD_Module_Specification.pdf]] was uploaded by JTA on 20180501.

* [[file:ANL_Firmware_for_LBL_Digitizer.pdf]] was uploaded by JTA on 20180501.

** '' '''Scientists should first'''' '' read [[file:Non-Expert_ANL_Firmware_-_ANL_version.pdf]] as this provides a shorter summary of features and is easier to digest.

* [[file:20160418_trig_command_link.pdf]] was uploaded by JTA on 20180501.

* [[file:CPLD_sum_logic.pdf]] was uploaded by JTA on 20180501.

* [[file:Interfacing_Digital_Gammasphere_with_other_detectors_and_systems.pdf]] was uploaded by JTA on 20180501.

* [[file:TripletPulseNotesTake2.pdf]] was uploaded by JTA on 20180501. This document demonstrates using the Digitizer Tester to show the effects of integration time and readout length settings on complex waveforms.

''Go back to [[Digital Gammasphere Upgrade Project]]''

File:Non-Expert ANL Firmware - ANL version.pdf

2023-07-19T01:04:21Z

Jta:

The Pickoff Card

2023-07-19T00:59:45Z

Jta:

[[File:Pickofflabeled.png|475px|thumb|Figure 1. The SBX pickoff card, labeled.]]
The "SBX pickoff card" attached to the [[The Slope Box Extension|SBX]] of each detector receives the single-ended [[Detector Signals|signals]] for the Ge Center, Ge Sides, and BGO segments from the Slope Box. It converts these to differential signal format before sending them to the rest of the [[DAQ system]]. The SBX pickoff card is an FPGA-based design that provides a communication hub interfacing the preamp, power board, dongle and slope box to EPICS through a serial interface. Its receives all analog signals from the detector by directly plugging into the Slope Box, eliminating the "grey cables" that existed prior to the Gammasphere Upgrade. From the 10 detector signals (Ge center contact, two Ge Side contacts and 7 BGO signals) the SBX pickoff generates the four digitizer signals GeCenter, BGOsum, GeSide & BGOpattern. Many signal conditioning and multiplexing options for these four signals are included, all controllable from software through the FPGA's communication interface. New signal combination modes built into the SBX pickoff's design now also enable new measurements that were previously unavailable. These new features include

* Software programmable DC offsets for all four digitizer signals
* 16 different, software-selectable gain settings for the GeCenter signal
* 16 different, software-selectable decay time constants for the GeCenter signal
* Software programmable voltage comparator to detect preamp reset conditions, connected to software programmable clamping circuit (DC level and clamp time) for baseline restoration after preamp reset
* 5 level programmable attenuation for the BGO sum signal
* 16 different signal multiplexing/addition combinations for the GeSide channel providing access to both side channels, a 2nd copy of the GeCenter at fixed 5MeV full scale gain and many FPGA-based digital pulse signals for diganostics and system tuning
* Individual BGO discriminators with programmable threshold for every BGO scintillator, connected both to FPGA based rate counters and to the [[Collector Box|collector box]] via a fast serial interface for formation of the [[Detector Signals|electric honeycomb]] 2nd-order suppression data
* Software selectable access, through the BGOpattern digitizer channel, to each BGO scintillator signal, the BGO pattern signal, or a 3rd copy of the GeCenter signal at fixed gains of either 8Mev full scale or 17MeV full scale

Figure 1 shows the SBX pickoff card, with its various subsections highlighted. Parts of the pickoff card are dedicated to the processing of specific [[Detector Signals|signals]], like the Ge center, Ge sides, and BGO sum and BGO pattern. It is designed to stack up with the SBX power board, and has protruding connectors on two different sides to do so. It has connectors for an optional Raspberry Pi, which is meant to enable standalone detector operation. A DVI cable attaches to the pickoff card for connection to the collector box. This DVI cable contains the four digitizer signals plus power and communications. The FPGA of the SBX pickoff performs automated scanning of the Preamp, the Power Board and the Slope Box continuously in the background using scan programs stored in read-only memory. At startup, the EEPROMs of both the Preamp and the Dongle are also read. Within the pickoff firmware, scanner machines run these scan programs with the help of transactor machines that perform individual reads/writes tailored to the specific communications protocols of each device (speed, signal types, etc). The data collected from these scanners are placed into a dual-port RAM inside the FPGA to make all collected status values available to EPICS. All scanners can be paused to allow EPICS to manually insert commands to the transactors to set any detector device to new values. The status information collected by all these scanners is then written into a dual-port RAM by an arbiter machine. Values in the dual-port RAM are read by EPICS just like any register of the pickoff FPGA, hiding all device-specific timing from EPICS.

== The VXI Pickoff Card (Before the Gammasphere Upgrade) ==
Large many-conductor grey cables ran between the Slope Box on each detector to the Pickoff cards in the VXI crates of the old system. The VXI Pickoff Card received the single-ended signals for the Ge Center, Ge Sides, and BGO segments from the Slope Box. The VXI pickoff converted them to differential signal format before sending them to the digitizer. Detector signals were sent as single-ended signals on coax cables that were part of the grey cables, running parallel with multiple power supply voltages plus communication. All power for Gammasphere detectors was generated by the bulk power supplies of the VXI crates, that also had to power the VXI cards. The long cable runs and many connectors often resulted in noisy or marginal power for the detectors, and failing contacts in these cables caused an ever-growing maintenance issue. The VXI pickoff passed the power and slow control through from the VXI cards to the grey cable while intercepting the side and center Ge signals plus the 7 BGO signals, converting them into the same GeCenter, BGOsum and GeSide differential digitizers still in use today. The original VXI pickoff did not implement the BGOpattern signals or support for the electric honeycomb in any way. While sufficient for many experiments, the "pass-through" mechanical nature of the VXI pickoff card created mechanical contact difficulties. The functionality of the VXI pickoff has been completely replaced and significantly expanded upon by the SBX pickoff card.
[[File:VXI Pickoff card top view.jpg|thumb|400px|Figure 2. The VXI system, with old pickoff cards at the end of cables.]]

The Slope Box Extension

2023-07-19T00:31:23Z

Jta:

'''''This image is clickable. Click text to go to the link.'''''
<imagemap>
Image:SBX.png|thumb|600px|Figure 1. SBX contents
poly 388 753 245 317 285 203 320 108 322 27 1147 27 1554 62 1533 467 1373 424 1366 221 1123 148 771 216 701 136 307 206 290 346 386 410 434 576 820 507 874 639 388 753 [[The Slope Box]]
rect 801 256 1336 308 [[SBX Power Board]]
rect 814 454 1361 561 [[The Pickoff Card]]
rect 309 231 788 398 [[Raspberry Pi]]
</imagemap>
The Slope Box Extension (SBX) unit provides power to the detector and helps convert signals received from the detector to be sent to the [[Collector Box|collector box]]. It extends directly from the [[The Slope Box|slope box]]. The SBX contains a power board and '''[[The Pickoff Card|"pickoff card"]]''' along with an optional '''Raspberry Pi''' computer for standalone detecter operation. As a whole, the SBX is there to handle much of the signals and processing between the detectors and the greater [[DAQ system|data acquisition system]]. The power board of the SBX provides all necessary power to the detector from a single source (48VDC), and allows a single detector and its SBX to be run entirely from one PoE (power over ethernet) port, enabling a detector to operate by itself. Meanwhile, the pickoff card converts signals from the detector to go to the digitizer. Understanding the SBX on a hardware level can be understood by observing the functions of the [[The Pickoff Card|pickoff card]].

These electronics replace all utility of the previously used "VXI system", while providing additional functionality previously unavailable. The addition of the Slope Box Extension moved all detector analog signal conditioning performed by the pickoff directly to the detector. Signal conversion prior to the existence of the SBX required extensive cabling and signal-carrying to the VXI sub-systems before being digitized. As a result of the changes, there is a significant reduction in cabling, and the elimination of the VXI sub-system that previously fulfilled the function of the SBX, making the detector easier to move in the future. The Slope Box Extension now drives a DVI-I cable containing the analog signals, power, and communication interface to a [[Collector Box|collector box]].

==EDM Interface for Slope Box==

The Raspberry Pi contains an EDM screen allowing users to read and write process variables (PVs). The Slope Box PVs include detector controls and monitoring (HV, Temps, etc.), and the SBX Pickoff PVs include control for signal processing functions (DC offset, gain range, Preamp Reset Clamping, etc.).

<imagemap>
Image:PickoffControl Screen.png|frame|center|alt=Test Image Map
</imagemap>

''Go back to [[Gammasphere Detectors]]''

''Go back to [[Digital Gammasphere Upgrade Project]]''

The Slope Box Extension

2023-07-19T00:30:30Z

Jta:

'''''This image is clickable. Click text to go to the link.'''''
<imagemap>
Image:SBX.png|thumb|600px|Figure 1. SBX contents
poly 388 753 245 317 285 203 320 108 322 27 1147 27 1554 62 1533 467 1373 424 1366 221 1123 148 771 216 701 136 307 206 290 346 386 410 434 576 820 507 874 639 388 753 [[The Slope Box]]
rect 801 256 1336 308 [[SBX Power Board]]
rect 814 454 1361 461 [[The Pickoff Card]]
rect 309 231 788 398 [[Raspberry Pi]]
</imagemap>
The Slope Box Extension (SBX) unit provides power to the detector and helps convert signals received from the detector to be sent to the [[Collector Box|collector box]]. It extends directly from the [[The Slope Box|slope box]]. The SBX contains a power board and '''[[The Pickoff Card|"pickoff card"]]''' along with an optional '''Raspberry Pi''' computer for standalone detecter operation. As a whole, the SBX is there to handle much of the signals and processing between the detectors and the greater [[DAQ system|data acquisition system]]. The power board of the SBX provides all necessary power to the detector from a single source (48VDC), and allows a single detector and its SBX to be run entirely from one PoE (power over ethernet) port, enabling a detector to operate by itself. Meanwhile, the pickoff card converts signals from the detector to go to the digitizer. Understanding the SBX on a hardware level can be understood by observing the functions of the [[The Pickoff Card|pickoff card]].

These electronics replace all utility of the previously used "VXI system", while providing additional functionality previously unavailable. The addition of the Slope Box Extension moved all detector analog signal conditioning performed by the pickoff directly to the detector. Signal conversion prior to the existence of the SBX required extensive cabling and signal-carrying to the VXI sub-systems before being digitized. As a result of the changes, there is a significant reduction in cabling, and the elimination of the VXI sub-system that previously fulfilled the function of the SBX, making the detector easier to move in the future. The Slope Box Extension now drives a DVI-I cable containing the analog signals, power, and communication interface to a [[Collector Box|collector box]].

==EDM Interface for Slope Box==

The Raspberry Pi contains an EDM screen allowing users to read and write process variables (PVs). The Slope Box PVs include detector controls and monitoring (HV, Temps, etc.), and the SBX Pickoff PVs include control for signal processing functions (DC offset, gain range, Preamp Reset Clamping, etc.).

<imagemap>
Image:PickoffControl Screen.png|frame|center|alt=Test Image Map
</imagemap>

''Go back to [[Gammasphere Detectors]]''

''Go back to [[Digital Gammasphere Upgrade Project]]''

The Slope Box Extension

2023-07-19T00:29:11Z

Jta:

'''''This image is clickable. Click text to go to the link.'''''
<imagemap>
Image:SBX.png|thumb|600px|Figure 1. SBX contents
poly 388 753 245 317 285 203 320 108 322 27 1147 27 1554 62 1533 467 1373 424 1366 221 1123 148 771 216 701 136 307 206 290 346 386 410 434 576 820 507 874 639 388 753 [[The Slope Box]]
rect 801 256 1336 308 [[The Pickoff Card]]
rect 814 454 1361 461 [[SBX Power Board]]
rect 309 231 788 398 [[Raspberry Pi]]
</imagemap>
The Slope Box Extension (SBX) unit provides power to the detector and helps convert signals received from the detector to be sent to the [[Collector Box|collector box]]. It extends directly from the [[The Slope Box|slope box]]. The SBX contains a power board and '''[[The Pickoff Card|"pickoff card"]]''' along with an optional '''Raspberry Pi''' computer for standalone detecter operation. As a whole, the SBX is there to handle much of the signals and processing between the detectors and the greater [[DAQ system|data acquisition system]]. The power board of the SBX provides all necessary power to the detector from a single source (48VDC), and allows a single detector and its SBX to be run entirely from one PoE (power over ethernet) port, enabling a detector to operate by itself. Meanwhile, the pickoff card converts signals from the detector to go to the digitizer. Understanding the SBX on a hardware level can be understood by observing the functions of the [[The Pickoff Card|pickoff card]].

These electronics replace all utility of the previously used "VXI system", while providing additional functionality previously unavailable. The addition of the Slope Box Extension moved all detector analog signal conditioning performed by the pickoff directly to the detector. Signal conversion prior to the existence of the SBX required extensive cabling and signal-carrying to the VXI sub-systems before being digitized. As a result of the changes, there is a significant reduction in cabling, and the elimination of the VXI sub-system that previously fulfilled the function of the SBX, making the detector easier to move in the future. The Slope Box Extension now drives a DVI-I cable containing the analog signals, power, and communication interface to a [[Collector Box|collector box]].

==EDM Interface for Slope Box==

The Raspberry Pi contains an EDM screen allowing users to read and write process variables (PVs). The Slope Box PVs include detector controls and monitoring (HV, Temps, etc.), and the SBX Pickoff PVs include control for signal processing functions (DC offset, gain range, Preamp Reset Clamping, etc.).

<imagemap>
Image:PickoffControl Screen.png|frame|center|alt=Test Image Map
</imagemap>

''Go back to [[Gammasphere Detectors]]''

''Go back to [[Digital Gammasphere Upgrade Project]]''

The Slope Box Extension

2023-07-19T00:28:43Z

Jta:

'''''This image is clickable. Click text to go to the link.'''''
<imagemap>
Image:SBX.png|thumb|600px|Figure 1. SBX contents
poly 388 753 245 317 285 203 320 108 322 27 1147 27 1554 62 1533 467 1373 424 1366 221 1123 148 771 216 701 136 307 206 290 346 386 410 434 576 820 507 874 639 388 753 [[The Slope Box]]
rect 814 454 1361 461 [[SBX Power Board]]
rect 309 231 788 398 [[Raspberry Pi]]
</imagemap>
The Slope Box Extension (SBX) unit provides power to the detector and helps convert signals received from the detector to be sent to the [[Collector Box|collector box]]. It extends directly from the [[The Slope Box|slope box]]. The SBX contains a power board and '''[[The Pickoff Card|"pickoff card"]]''' along with an optional '''Raspberry Pi''' computer for standalone detecter operation. As a whole, the SBX is there to handle much of the signals and processing between the detectors and the greater [[DAQ system|data acquisition system]]. The power board of the SBX provides all necessary power to the detector from a single source (48VDC), and allows a single detector and its SBX to be run entirely from one PoE (power over ethernet) port, enabling a detector to operate by itself. Meanwhile, the pickoff card converts signals from the detector to go to the digitizer. Understanding the SBX on a hardware level can be understood by observing the functions of the [[The Pickoff Card|pickoff card]].

These electronics replace all utility of the previously used "VXI system", while providing additional functionality previously unavailable. The addition of the Slope Box Extension moved all detector analog signal conditioning performed by the pickoff directly to the detector. Signal conversion prior to the existence of the SBX required extensive cabling and signal-carrying to the VXI sub-systems before being digitized. As a result of the changes, there is a significant reduction in cabling, and the elimination of the VXI sub-system that previously fulfilled the function of the SBX, making the detector easier to move in the future. The Slope Box Extension now drives a DVI-I cable containing the analog signals, power, and communication interface to a [[Collector Box|collector box]].

==EDM Interface for Slope Box==

The Raspberry Pi contains an EDM screen allowing users to read and write process variables (PVs). The Slope Box PVs include detector controls and monitoring (HV, Temps, etc.), and the SBX Pickoff PVs include control for signal processing functions (DC offset, gain range, Preamp Reset Clamping, etc.).

<imagemap>
Image:PickoffControl Screen.png|frame|center|alt=Test Image Map
</imagemap>

''Go back to [[Gammasphere Detectors]]''

''Go back to [[Digital Gammasphere Upgrade Project]]''

The Slope Box Extension

2023-07-19T00:26:52Z

Jta:

'''''This image is clickable. Click text to go to the link.'''''
<imagemap>
Image:SBX.png|thumb|600px|Figure 1. SBX contents
poly 388 753 245 317 285 203 320 108 322 27 1147 27 1554 62 1533 467 1373 424 1366 221 1123 148 771 216 701 136 307 206 290 346 386 410 434 576 820 507 874 639 388 753 [[The Slope Box]]
rect 801 256 1336 308 [[The Pickoff Card]]
rect 814 454 1361 461 [[SBX Power Board]]
rect 309 231 788 398 [[Raspberry Pi]]
</imagemap>
The Slope Box Extension (SBX) unit provides power to the detector and helps convert signals received from the detector to be sent to the [[Collector Box|collector box]]. It extends directly from the [[The Slope Box|slope box]]. The SBX contains a power board and '''[[The Pickoff Card|"pickoff card"]]''' along with an optional '''Raspberry Pi''' computer for standalone detecter operation. As a whole, the SBX is there to handle much of the signals and processing between the detectors and the greater [[DAQ system|data acquisition system]]. The power board of the SBX provides all necessary power to the detector from a single source (48VDC), and allows a single detector and its SBX to be run entirely from one PoE (power over ethernet) port, enabling a detector to operate by itself. Meanwhile, the pickoff card converts signals from the detector to go to the digitizer. Understanding the SBX on a hardware level can be understood by observing the functions of the [[The Pickoff Card|pickoff card]].

These electronics replace all utility of the previously used "VXI system", while providing additional functionality previously unavailable. The addition of the Slope Box Extension moved all detector analog signal conditioning performed by the pickoff directly to the detector. Signal conversion prior to the existence of the SBX required extensive cabling and signal-carrying to the VXI sub-systems before being digitized. As a result of the changes, there is a significant reduction in cabling, and the elimination of the VXI sub-system that previously fulfilled the function of the SBX, making the detector easier to move in the future. The Slope Box Extension now drives a DVI-I cable containing the analog signals, power, and communication interface to a [[Collector Box|collector box]].

==EDM Interface for Slope Box==

The Raspberry Pi contains an EDM screen allowing users to read and write process variables (PVs). The Slope Box PVs include detector controls and monitoring (HV, Temps, etc.), and the SBX Pickoff PVs include control for signal processing functions (DC offset, gain range, Preamp Reset Clamping, etc.).

<imagemap>
Image:PickoffControl Screen.png|frame|center|alt=Test Image Map
</imagemap>

''Go back to [[Gammasphere Detectors]]''

''Go back to [[Digital Gammasphere Upgrade Project]]''

The Slope Box Extension

2023-07-19T00:18:58Z

Jta:

'''''This image is clickable. Click text to go to the link.'''''
<imagemap>
Image:SBX.png|thumb|600px|Figure 1. SBX contents
poly 519 162 691 149 1552 217 1560 352 1200 548 1180 211 [[The Slope Box]]
poly 163 548 274 474 873 510 803 610 [[The Pickoff Card]]
poly 890 377 806 499 424 466 547 356 [[SBX Power Board]]
</imagemap>
The Slope Box Extension (SBX) unit provides power to the detector and helps convert signals received from the detector to be sent to the [[Collector Box|collector box]]. It extends directly from the [[The Slope Box|slope box]]. The SBX contains a power board and '''[[The Pickoff Card|"pickoff card"]]''' along with an optional '''Raspberry Pi''' computer for standalone detecter operation. As a whole, the SBX is there to handle much of the signals and processing between the detectors and the greater [[DAQ system|data acquisition system]]. The power board of the SBX provides all necessary power to the detector from a single source (48VDC), and allows a single detector and its SBX to be run entirely from one PoE (power over ethernet) port, enabling a detector to operate by itself. Meanwhile, the pickoff card converts signals from the detector to go to the digitizer. Understanding the SBX on a hardware level can be understood by observing the functions of the [[The Pickoff Card|pickoff card]].

These electronics replace all utility of the previously used "VXI system", while providing additional functionality previously unavailable. The addition of the Slope Box Extension moved all detector analog signal conditioning performed by the pickoff directly to the detector. Signal conversion prior to the existence of the SBX required extensive cabling and signal-carrying to the VXI sub-systems before being digitized. As a result of the changes, there is a significant reduction in cabling, and the elimination of the VXI sub-system that previously fulfilled the function of the SBX, making the detector easier to move in the future. The Slope Box Extension now drives a DVI-I cable containing the analog signals, power, and communication interface to a [[Collector Box|collector box]].

==EDM Interface for Slope Box==

The Raspberry Pi contains an EDM screen allowing users to read and write process variables (PVs). The Slope Box PVs include detector controls and monitoring (HV, Temps, etc.), and the SBX Pickoff PVs include control for signal processing functions (DC offset, gain range, Preamp Reset Clamping, etc.).

<imagemap>
Image:PickoffControl Screen.png|frame|center|alt=Test Image Map
</imagemap>

''Go back to [[Gammasphere Detectors]]''

''Go back to [[Digital Gammasphere Upgrade Project]]''

File:SBX.png

2023-07-19T00:18:23Z

Jta:

DAQ system

2023-04-01T00:47:29Z

Jta:

'''''This is an image map. Click on a section of the picture to go to the page for that item.'''''
<imagemap>
Image:GammasphereDAQupgrade.jpg|700px|center|thumb|Figure 1. DAQ System circled in red; one rack for each of the four "hemispheres" of Gammasphere
poly 135 204 209 219 258 192 250 266 213 293 137 268 [[VME Crates]]
poly 904 385 977 402 1030 373 1029 438 979 470 904 452 [[VME Crates]]
poly 1039 326 1097 339 1143 308 1148 378 1096 406 1058 376 1027 364 [[VME Crates]]
poly 134 167 135 197 209 217 257 184 256 162 208 185 [[Collector Box]]
poly 906 347 906 367 977 395 1022 369 1025 345 977 367 [[Collector Box]]
poly 1034 287 1103 301 1146 275 1146 299 1100 323 1042 311 [[Collector Box]]
poly 199 104 137 158 206 175 269 139 [[DAQ Power Supply]]
poly 312 42 253 96 317 113 375 58 [[DAQ Power Supply]]
poly 902 339 966 285 1034 321 976 356 [[DAQ Power Supply]]
poly 1021 274 1081 225 1140 242 1089 293 [[DAQ Power Supply]]
poly 445 151 432 123 398 113 351 138 305 218 291 285 290 337 300 382 336 429 370 423 421 413 356 454 276 423 251 353 252 293 267 219 304 138 344 95 379 79 428 88 472 135 [[Liquid Nitrogen]]
poly 838 557 809 506 804 446 808 384 828 320 865 258 911 222 960 212 1010 233 1021 293 991 288 969 251 950 241 935 239 901 264 876 300 860 331 846 378 839 428 839 470 847 516 850 532[[Liquid Nitrogen]]
poly 502 374 499 305 519 251 564 207 615 184 660 181 713 195 759 233 783 277 796 329 788 382 764 427 710 470 648 483 587 471 533 431 [[Gammasphere|Gammasphere frame (without detectors in it)]]
</imagemap>
Gammasphere's DAQ system (data acquisition system) is now placed on relay racks by each side of its "hemispheres". Each of the racks for the DAQ consists of a [[DAQ Power Supply|power supply]], a [[Collector Box|collector box]], and a [[VME Crates|VME crate]]. The data acquisition system observes, interprets, and modifies data taken from [[Gammasphere]] and appropriately presents it to the user.

The picture above provides an overall map to the naming conventions associated with the system. Cardinal directions are shown in '''purple''' text, process variable (EPICS) names are shown in '''green''' text and network IDs are shown in '''red''' text. There are multiple computers within the DAQ system:

{| class="wikitable"
|+These devices are used both by data acquisition and by control & monitoring
|-
! scope=col | Network name
! scope=col | IP address
! scope=col | Description
|-
| ioc01: || 192.168.203.141 || MVME5500 VME processor used for control and readout
|-
| ioc02: || 192.168.203.142 || MVME5500 VME processor used for control and readout
|-
| ioc03: || 192.168.203.143 || MVME5500 VME processor used for control and readout
|-
| ioc04: || 192.168.203.144 || MVME5500 VME processor used for control and readout
|-
| ioc05: || 192.168.203.145 || MVME5500 VME processor used for control and readout
|-
| ioc06: || 192.168.203.177 || MVME5500 VME processor used for control and readout
|-
| ioc07: || 192.168.203.178 || MVME5500 VME processor used for control and readout
|-
| ioc08: || 192.168.203.179 || MVME5500 VME processor used for control and readout
|-
| ioc09: || 192.168.203.180 || MVME5500 VME processor used for control and readout
|-
| ioc10: || 192.168.203.183 || MVME5500 VME processor used for control and readout
|-
| ioc11: || 192.168.203.181 || MVME5500 VME processor used for control and readout
|-
| ioc12: || 192.168.203.182 || MVME5500 VME processor used for control and readout
|-}
{| class="wikitable"
|+These devices are used by control & monitoring only.
|-
! scope=col | Network name
! scope=col | IP address
! scope=col | Description
|-
| gs-cne || 192.168.203.88 || Raspberry Pi inside the North East Collector box
|-
| gs-cnw || 192.168.203.149 || Raspberry Pi inside the North West Collector box
|-
| gs-cse || 192.168.203.42 || Raspberry Pi inside the South East Collector box
|-
| gs-csw || 192.168.203.26 || Raspberry Pi inside the South West Collector box
|-}
{| class="wikitable"
|+These devices are used by directly logging into them to control power to the VME crates, network switches and terminal servers.
|-
! scope=col | Network name
! scope=col | IP address
! scope=col | Description
|-
| gs-pdu-north || 192.168.203.224 || Power Distribution Unit for the North Hemisphere
|-
| gs-pdu_south || 192.168.203.225 || Power Distribution Unit for the North Hemisphere
|-}
{| class="wikitable"
|+These devices are used by directly logging into them to connect to the console ports of IOC01 through IOC12.
|-
! scope=col | Network name
! scope=col | IP address
! scope=col | Description
|-
| gs-ts-north || 192.168.203.91 || Terminal server providing console port access for ioc07 through ioc12
|-
| gs-ts_south || 192.168.203.186 || Terminal server providing console port access for ioc01 through ioc06
|-}
{| class="wikitable"
|+These devices are associated with the liquid nitrogen subsystem.
|-
! scope=col | Network name
! scope=col | IP address
! scope=col | Description
|-
| lnfill || 192.168.203.121 || Embedded VME processor that hosts the EPICS databases for valve status and valve control
|-
| ln2con || 192.168.203.148 || Linux computer that lnfill boots from
|}

When [[Gammasphere]] collects data, single-ended [[Detector Signals|signals]] are first collected from the slope box for the Ge Center, Ge Sides, and BGO segment. The signals are converted to differential signals by the [[The Slope Box Extension|SBX]], and are then sent to the collector box so the signals can properly be routed to the digitizers. The digitizers process and output the desired information to the user based upon their data specifications. The DAQ system is an FPGA-based design that provides communication hub interfacing the [[Preamplifier|preamp]], power board, dongle and slope box to EPICS through serial interface. Analog signal paths are completely software controlled.
==DAQ System Function==
The Gammasphere DAQ system consists of VME crates, IOC Modules, Digitizers and Trigger Modules. The original "analog" implementation of Gammasphere using the VXI modules used a charge-integrating ADC methodology and did not continuously digitize the data from the detectors. The Digital Gammasphere system (2010s) introduced the digitizers as a replacement for the charge-integrating ADC functions of the VXI modules and replaces the "analog" system's trigger by a new trigger system, requiring a redesign of the DAQ. The later "Gammasphere Upgrade" project (2019-2023) that resulted in the SBX, preamp and collector box hardware did not materially affect the DAQ but replaced all of the remaining control, monitoring and power distribution functions of the VXI system allowing removal of the VXI system and associated cable plant.

Each digitizer in the system consists of 10 channels, but should be conceptualized as a pair of two ''sub-digitizers'' consisting of five channels each. There are two types of digitizers: master and slave. A pair of channels in a master digitizer receives signals from the Ge center and BGO sum from a single Gammasphere detector, while a channel-pair in the slave digitizer receives signals from the Ge side and BGO pattern. All channels in all digitizers run continuously.

There are two types of Digitizers (Master and Slave) and well as Trigger (Master and Router). All channels in all digitizers run continuously. There are two types of digitizers (master and slave) as well as two types of triggers (master and router).

When discriminator logic within the digitizer firmware marks edges of gamma-ray signals, energy sums, timing and other data are stored in a header identifying the event. If the event is selected for readout by the trigger system, the header and a programmable amount of waveform is transferred from the channel to the board-wide FIFO (first in, first out) data holder. Similarly the trigger modules have FIFO buffers that store information each time a trigger acceptance message is issued to the digitizers. The IOC scans the FIFOs of all modules to see if there is data to read out through a series of programs named inLoop, outLoop and MiniSender. If data is available, the inLoop program reads it and stores the data read into memory buffers. Program outLoop verifies the integrity of the buffers and then hands control of the buffers to the MiniSender program. A separate program running on a different computer called “gtReceiver” sends messages to each IOC's MiniSender program when it is capable of receiving data. The MiniSender program of each IOC, in response to requests from gtReceiver, then breaks apart buffers into UDP packets and sends them to gtReceiver. The gtReceiver program then stores the data received to files that may be organized by digitizer or by channel.
<imagemap>
Image:DAQSystem.png|center|thumb|700px|Figure 2. Diagram of the DAQ system process.
rect 454 225 478 241 [[Gammasphere Detectors]]
rect 550 225 575 242 [[Gammasphere Detectors]]
rect 642 225 665 241 [[Gammasphere Detectors]]
poly 451 211 449 224 481 224 480 213 [[The Slope Box]]
poly 546 212 545 224 575 224 576 216 [[The Slope Box]]
poly 637 209 637 222 667 223 667 214 [[The Slope Box]]
rect 435 211 448 222 [[The Slope Box Extension]]
rect 532 213 544 223 [[The Slope Box Extension]]
rect 624 211 635 221[[The Slope Box Extension]]
</imagemap>

''To view how this system is controlled, go to [[DGS Commander EDM Screens]].''

''Go back to [[Digital Gammasphere Upgrade Project]]''

Building the Entire System

2023-04-01T00:30:53Z

Jta:

Building the Entire System

2023-04-01T00:28:11Z

Jta:

DAQ system

2023-03-30T01:25:39Z

Jta: /* DAQ System Function */

'''''This is an image map. Click on a section of the picture to go to the page for that item.'''''
<imagemap>
Image:GammasphereDAQupgrade.jpg|700px|center|thumb|Figure 1. DAQ System circled in red; one rack for each of the four "hemispheres" of Gammasphere
poly 135 204 209 219 258 192 250 266 213 293 137 268 [[VME Crates]]
poly 904 385 977 402 1030 373 1029 438 979 470 904 452 [[VME Crates]]
poly 1039 326 1097 339 1143 308 1148 378 1096 406 1058 376 1027 364 [[VME Crates]]
poly 134 167 135 197 209 217 257 184 256 162 208 185 [[Collector Box]]
poly 906 347 906 367 977 395 1022 369 1025 345 977 367 [[Collector Box]]
poly 1034 287 1103 301 1146 275 1146 299 1100 323 1042 311 [[Collector Box]]
poly 199 104 137 158 206 175 269 139 [[DAQ Power Supply]]
poly 312 42 253 96 317 113 375 58 [[DAQ Power Supply]]
poly 902 339 966 285 1034 321 976 356 [[DAQ Power Supply]]
poly 1021 274 1081 225 1140 242 1089 293 [[DAQ Power Supply]]
poly 445 151 432 123 398 113 351 138 305 218 291 285 290 337 300 382 336 429 370 423 421 413 356 454 276 423 251 353 252 293 267 219 304 138 344 95 379 79 428 88 472 135 [[Liquid Nitrogen]]
poly 838 557 809 506 804 446 808 384 828 320 865 258 911 222 960 212 1010 233 1021 293 991 288 969 251 950 241 935 239 901 264 876 300 860 331 846 378 839 428 839 470 847 516 850 532[[Liquid Nitrogen]]
poly 502 374 499 305 519 251 564 207 615 184 660 181 713 195 759 233 783 277 796 329 788 382 764 427 710 470 648 483 587 471 533 431 [[Gammasphere|Gammasphere frame (without detectors in it)]]
</imagemap>
Gammasphere's DAQ system (data acquisition system) is now placed on relay racks by each side of its "hemispheres". Each of the racks for the DAQ consists of a [[DAQ Power Supply|power supply]], a [[Collector Box|collector box]], and a [[VME Crates|VME crate]]. The data acquisition system observes, interprets, and modifies data taken from [[Gammasphere]] and appropriately presents it to the user.

The picture above provides an overall map to the naming conventions associated with the system. Cardinal directions are shown in '''purple''' text, process variable (EPICS) names are shown in '''green''' text and network IDs are shown in '''red''' text. There are multiple computers within the DAQ system:

{| class="wikitable"
|+ Network names and IP addresses of the devices within Digital Gammasphere
|-
! Network name !! IP address !! Description
|-
| ioc01: || 192.168.203.141 || MVME5500 VME processor used for control and readout
|-
| ioc02: || 192.168.203.142 || MVME5500 VME processor used for control and readout
|-
| ioc03: || 192.168.203.143 || MVME5500 VME processor used for control and readout
|-
| ioc04: || 192.168.203.144 || MVME5500 VME processor used for control and readout
|-
| ioc05: || 192.168.203.145 || MVME5500 VME processor used for control and readout
|-
| ioc06: || 192.168.203.177 || MVME5500 VME processor used for control and readout
|-
| ioc07: || 192.168.203.178 || MVME5500 VME processor used for control and readout
|-
| ioc08: || 192.168.203.179 || MVME5500 VME processor used for control and readout
|-
| ioc09: || 192.168.203.180 || MVME5500 VME processor used for control and readout
|-
| ioc10: || 192.168.203.183 || MVME5500 VME processor used for control and readout
|-
| ioc11: || 192.168.203.181 || MVME5500 VME processor used for control and readout
|-
| ioc12: || 192.168.203.182 || MVME5500 VME processor used for control and readout
|-
| gs-cne || 192.168.203.88 || Raspberry Pi inside the North East Collector box
|-
| gs-cnw || 192.168.203.149 || Raspberry Pi inside the North West Collector box
|-
| gs-cse || 192.168.203.42 || Raspberry Pi inside the South East Collector box
|-
| gs-csw || 192.168.203.26 || Raspberry Pi inside the South West Collector box
|-
| gs-pdu-north || 192.168.203.224 || Power Distribution Unit for the North Hemisphere
|-
| gs-pdu_south || 192.168.203.225 || Power Distribution Unit for the North Hemisphere
|-
| gs-ts-north || 192.168.203.91 || Terminal server providing console port access for ioc07 through ioc12
|-
| gs-ts_south || 192.168.203.186 || Terminal server providing console port access for ioc01 through ioc06
|-
| lnfill || 192.168.203.121 || Embedded VME processor that hosts the EPICS databases for valve status and valve control
|-
ln2con || 192.168.203.148 || Linux computer that lnfill boots from
|}

When [[Gammasphere]] collects data, single-ended [[Detector Signals|signals]] are first collected from the slope box for the Ge Center, Ge Sides, and BGO segment. The signals are converted to differential signals by the [[The Slope Box Extension|SBX]], and are then sent to the collector box so the signals can properly be routed to the digitizers. The digitizers process and output the desired information to the user based upon their data specifications. The DAQ system is an FPGA-based design that provides communication hub interfacing the [[Preamplifier|preamp]], power board, dongle and slope box to EPICS through serial interface. Analog signal paths are completely software controlled.
==DAQ System Function==
The Gammasphere DAQ system consists of VME crates, IOC Modules, Digitizers and Trigger Modules. The original "analog" implementation of Gammasphere using the VXI modules used a charge-integrating ADC methodology and did not continuously digitize the data from the detectors. The Digital Gammasphere system introduced the digitizers as a replacement for the charge-integrating ADC functions of the VXI modules and replaces the "analog" system's trigger by a new trigger system, requiring a redesign of the DAQ. The later "Gammasphere Upgrade" project that resulted in the SBX, preamp and collector box hardware did not materially affect the DAQ but replaced all of the remaining control, monitoring and power distribution functions of the VXI system allowing removal of the VXI system and associated cable plant.

There are two types of Digitizers (Master and Slave) and well as Trigger (Master and Router). All channels in all digitizers run continuously. When discriminator logic within the digitizer firmware marks edges of gamma-ray signals, energy sums, timing and other data are stored in a header identifying the event. If the event is selected for readout by the trigger system, the header and a programmable amount of waveform is transferred from the channel to the board-wide FIFO (first in, first out) data holder. Similarly the trigger modules have FIFO buffers that store information each time a trigger acceptance message is issued to the digitizers. The IOC scans the FIFOs of all modules to see if there is data to read out through a series of programs named inLoop, outLoop and MiniSender. If data is available, the inLoop program reads it and stores the data read into memory buffers. Program outLoop verifies the integrity of the buffers and then hands control of the buffers to the MiniSender program. A separate program running on a different computer called “gtReceiver” sends messages to each IOC's MiniSender program when it is capable of receiving data. The MiniSender program of each IOC, in response to requests from gtReceiver, then breaks apart buffers into UDP packets and sends them to gtReceiver. The gtReceiver program then stores the data received to files that may be organized by digitizer or by channel.
<imagemap>
Image:DAQSystem.png|center|thumb|700px|Figure 2. Diagram of the DAQ system process.
rect 454 225 478 241 [[Gammasphere Detectors]]
rect 550 225 575 242 [[Gammasphere Detectors]]
rect 642 225 665 241 [[Gammasphere Detectors]]
poly 451 211 449 224 481 224 480 213 [[The Slope Box]]
poly 546 212 545 224 575 224 576 216 [[The Slope Box]]
poly 637 209 637 222 667 223 667 214 [[The Slope Box]]
rect 435 211 448 222 [[The Slope Box Extension]]
rect 532 213 544 223 [[The Slope Box Extension]]
rect 624 211 635 221[[The Slope Box Extension]]
</imagemap>

''To view how this system is controlled, go to [[DGS Commander EDM Screens]].''

''Go back to [[Digital Gammasphere Upgrade Project]]''

DAQ system

2023-03-30T01:18:29Z

Jta: /* DAQ System Function */

'''''This is an image map. Click on a section of the picture to go to the page for that item.'''''
<imagemap>
Image:GammasphereDAQupgrade.jpg|700px|center|thumb|Figure 1. DAQ System circled in red; one rack for each of the four "hemispheres" of Gammasphere
poly 135 204 209 219 258 192 250 266 213 293 137 268 [[VME Crates]]
poly 904 385 977 402 1030 373 1029 438 979 470 904 452 [[VME Crates]]
poly 1039 326 1097 339 1143 308 1148 378 1096 406 1058 376 1027 364 [[VME Crates]]
poly 134 167 135 197 209 217 257 184 256 162 208 185 [[Collector Box]]
poly 906 347 906 367 977 395 1022 369 1025 345 977 367 [[Collector Box]]
poly 1034 287 1103 301 1146 275 1146 299 1100 323 1042 311 [[Collector Box]]
poly 199 104 137 158 206 175 269 139 [[DAQ Power Supply]]
poly 312 42 253 96 317 113 375 58 [[DAQ Power Supply]]
poly 902 339 966 285 1034 321 976 356 [[DAQ Power Supply]]
poly 1021 274 1081 225 1140 242 1089 293 [[DAQ Power Supply]]
poly 445 151 432 123 398 113 351 138 305 218 291 285 290 337 300 382 336 429 370 423 421 413 356 454 276 423 251 353 252 293 267 219 304 138 344 95 379 79 428 88 472 135 [[Liquid Nitrogen]]
poly 838 557 809 506 804 446 808 384 828 320 865 258 911 222 960 212 1010 233 1021 293 991 288 969 251 950 241 935 239 901 264 876 300 860 331 846 378 839 428 839 470 847 516 850 532[[Liquid Nitrogen]]
poly 502 374 499 305 519 251 564 207 615 184 660 181 713 195 759 233 783 277 796 329 788 382 764 427 710 470 648 483 587 471 533 431 [[Gammasphere|Gammasphere frame (without detectors in it)]]
</imagemap>
Gammasphere's DAQ system (data acquisition system) is now placed on relay racks by each side of its "hemispheres". Each of the racks for the DAQ consists of a [[DAQ Power Supply|power supply]], a [[Collector Box|collector box]], and a [[VME Crates|VME crate]]. The data acquisition system observes, interprets, and modifies data taken from [[Gammasphere]] and appropriately presents it to the user.

The picture above provides an overall map to the naming conventions associated with the system. Cardinal directions are shown in '''purple''' text, process variable (EPICS) names are shown in '''green''' text and network IDs are shown in '''red''' text. There are multiple computers within the DAQ system:

{| class="wikitable"
|+ Network names and IP addresses of the devices within Digital Gammasphere
|-
! Network name !! IP address !! Description
|-
| ioc01: || 192.168.203.141 || MVME5500 VME processor used for control and readout
|-
| ioc02: || 192.168.203.142 || MVME5500 VME processor used for control and readout
|-
| ioc03: || 192.168.203.143 || MVME5500 VME processor used for control and readout
|-
| ioc04: || 192.168.203.144 || MVME5500 VME processor used for control and readout
|-
| ioc05: || 192.168.203.145 || MVME5500 VME processor used for control and readout
|-
| ioc06: || 192.168.203.177 || MVME5500 VME processor used for control and readout
|-
| ioc07: || 192.168.203.178 || MVME5500 VME processor used for control and readout
|-
| ioc08: || 192.168.203.179 || MVME5500 VME processor used for control and readout
|-
| ioc09: || 192.168.203.180 || MVME5500 VME processor used for control and readout
|-
| ioc10: || 192.168.203.183 || MVME5500 VME processor used for control and readout
|-
| ioc11: || 192.168.203.181 || MVME5500 VME processor used for control and readout
|-
| ioc12: || 192.168.203.182 || MVME5500 VME processor used for control and readout
|-
| gs-cne || 192.168.203.88 || Raspberry Pi inside the North East Collector box
|-
| gs-cnw || 192.168.203.149 || Raspberry Pi inside the North West Collector box
|-
| gs-cse || 192.168.203.42 || Raspberry Pi inside the South East Collector box
|-
| gs-csw || 192.168.203.26 || Raspberry Pi inside the South West Collector box
|-
| gs-pdu-north || 192.168.203.224 || Power Distribution Unit for the North Hemisphere
|-
| gs-pdu_south || 192.168.203.225 || Power Distribution Unit for the North Hemisphere
|-
| gs-ts-north || 192.168.203.91 || Terminal server providing console port access for ioc07 through ioc12
|-
| gs-ts_south || 192.168.203.186 || Terminal server providing console port access for ioc01 through ioc06
|-
| lnfill || 192.168.203.121 || Embedded VME processor that hosts the EPICS databases for valve status and valve control
|-
ln2con || 192.168.203.148 || Linux computer that lnfill boots from
|}

When [[Gammasphere]] collects data, single-ended [[Detector Signals|signals]] are first collected from the slope box for the Ge Center, Ge Sides, and BGO segment. The signals are converted to differential signals by the [[The Slope Box Extension|SBX]], and are then sent to the collector box so the signals can properly be routed to the digitizers. The digitizers process and output the desired information to the user based upon their data specifications. The DAQ system is an FPGA-based design that provides communication hub interfacing the [[Preamplifier|preamp]], power board, dongle and slope box to EPICS through serial interface. Analog signal paths are completely software controlled.
==DAQ System Function==
The DAQ system prior to upgrades consisted of VME crates, IOC Modules, Digitizers and Trigger Modules. There were two types of Digitizers (Master and Slave) and well as Trigger (Master and Router). All channels in all digitizers run continuously. When discriminator logic within the digitizer firmware marks edges of gamma-ray signals, energy sums, timing and other data are stored in a header identifying the event. If the event is selected for readout by the trigger system, the header and a programmable amount of waveform is transferred from the channel to the board-wide FIFO (first in, first out) data holder. Similarly the trigger modules have FIFO buffers that store information each time a trigger acceptance message is issued to the digitizers. The IOC scans the FIFOs of all modules to see if there is data to read out through a series of programs named inLoop, outLoop and MiniSender. If data is available, the inLoop program reads it and stores the data read into memory buffers. Program outLoop verifies the integrity of the buffers and then hands control of the buffers to the MiniSender program. A separate program running on a different computer called “gtReceiver” sends messages to each IOC's MiniSender program when it is capable of receiving data. The MiniSender program of each IOC, in response to requests from gtReceiver, then breaks apart buffers into UDP packets and sends them to gtReceiver. The gtReceiver program then stores the data received to files that may be organized by digitizer or by channel.
<imagemap>
Image:DAQSystem.png|center|thumb|700px|Figure 2. Diagram of the DAQ system process.
rect 454 225 478 241 [[Gammasphere Detectors]]
rect 550 225 575 242 [[Gammasphere Detectors]]
rect 642 225 665 241 [[Gammasphere Detectors]]
poly 451 211 449 224 481 224 480 213 [[The Slope Box]]
poly 546 212 545 224 575 224 576 216 [[The Slope Box]]
poly 637 209 637 222 667 223 667 214 [[The Slope Box]]
rect 435 211 448 222 [[The Slope Box Extension]]
rect 532 213 544 223 [[The Slope Box Extension]]
rect 624 211 635 221[[The Slope Box Extension]]
</imagemap>

''To view how this system is controlled, go to [[DGS Commander EDM Screens]].''

''Go back to [[Digital Gammasphere Upgrade Project]]''

DAQ system

2023-03-30T01:13:32Z

Jta: /* DAQ System Function */

'''''This is an image map. Click on a section of the picture to go to the page for that item.'''''
<imagemap>
Image:GammasphereDAQupgrade.jpg|700px|center|thumb|Figure 1. DAQ System circled in red; one rack for each of the four "hemispheres" of Gammasphere
poly 135 204 209 219 258 192 250 266 213 293 137 268 [[VME Crates]]
poly 904 385 977 402 1030 373 1029 438 979 470 904 452 [[VME Crates]]
poly 1039 326 1097 339 1143 308 1148 378 1096 406 1058 376 1027 364 [[VME Crates]]
poly 134 167 135 197 209 217 257 184 256 162 208 185 [[Collector Box]]
poly 906 347 906 367 977 395 1022 369 1025 345 977 367 [[Collector Box]]
poly 1034 287 1103 301 1146 275 1146 299 1100 323 1042 311 [[Collector Box]]
poly 199 104 137 158 206 175 269 139 [[DAQ Power Supply]]
poly 312 42 253 96 317 113 375 58 [[DAQ Power Supply]]
poly 902 339 966 285 1034 321 976 356 [[DAQ Power Supply]]
poly 1021 274 1081 225 1140 242 1089 293 [[DAQ Power Supply]]
poly 445 151 432 123 398 113 351 138 305 218 291 285 290 337 300 382 336 429 370 423 421 413 356 454 276 423 251 353 252 293 267 219 304 138 344 95 379 79 428 88 472 135 [[Liquid Nitrogen]]
poly 838 557 809 506 804 446 808 384 828 320 865 258 911 222 960 212 1010 233 1021 293 991 288 969 251 950 241 935 239 901 264 876 300 860 331 846 378 839 428 839 470 847 516 850 532[[Liquid Nitrogen]]
poly 502 374 499 305 519 251 564 207 615 184 660 181 713 195 759 233 783 277 796 329 788 382 764 427 710 470 648 483 587 471 533 431 [[Gammasphere|Gammasphere frame (without detectors in it)]]
</imagemap>
Gammasphere's DAQ system (data acquisition system) is now placed on relay racks by each side of its "hemispheres". Each of the racks for the DAQ consists of a [[DAQ Power Supply|power supply]], a [[Collector Box|collector box]], and a [[VME Crates|VME crate]]. The data acquisition system observes, interprets, and modifies data taken from [[Gammasphere]] and appropriately presents it to the user.

The picture above provides an overall map to the naming conventions associated with the system. Cardinal directions are shown in '''purple''' text, process variable (EPICS) names are shown in '''green''' text and network IDs are shown in '''red''' text. There are multiple computers within the DAQ system:

{| class="wikitable"
|+ Network names and IP addresses of the devices within Digital Gammasphere
|-
! Network name !! IP address !! Description
|-
| ioc01: || 192.168.203.141 || MVME5500 VME processor used for control and readout
|-
| ioc02: || 192.168.203.142 || MVME5500 VME processor used for control and readout
|-
| ioc03: || 192.168.203.143 || MVME5500 VME processor used for control and readout
|-
| ioc04: || 192.168.203.144 || MVME5500 VME processor used for control and readout
|-
| ioc05: || 192.168.203.145 || MVME5500 VME processor used for control and readout
|-
| ioc06: || 192.168.203.177 || MVME5500 VME processor used for control and readout
|-
| ioc07: || 192.168.203.178 || MVME5500 VME processor used for control and readout
|-
| ioc08: || 192.168.203.179 || MVME5500 VME processor used for control and readout
|-
| ioc09: || 192.168.203.180 || MVME5500 VME processor used for control and readout
|-
| ioc10: || 192.168.203.183 || MVME5500 VME processor used for control and readout
|-
| ioc11: || 192.168.203.181 || MVME5500 VME processor used for control and readout
|-
| ioc12: || 192.168.203.182 || MVME5500 VME processor used for control and readout
|-
| gs-cne || 192.168.203.88 || Raspberry Pi inside the North East Collector box
|-
| gs-cnw || 192.168.203.149 || Raspberry Pi inside the North West Collector box
|-
| gs-cse || 192.168.203.42 || Raspberry Pi inside the South East Collector box
|-
| gs-csw || 192.168.203.26 || Raspberry Pi inside the South West Collector box
|-
| gs-pdu-north || 192.168.203.224 || Power Distribution Unit for the North Hemisphere
|-
| gs-pdu_south || 192.168.203.225 || Power Distribution Unit for the North Hemisphere
|-
| gs-ts-north || 192.168.203.91 || Terminal server providing console port access for ioc07 through ioc12
|-
| gs-ts_south || 192.168.203.186 || Terminal server providing console port access for ioc01 through ioc06
|-
| lnfill || 192.168.203.121 || Embedded VME processor that hosts the EPICS databases for valve status and valve control
|-
ln2con || 192.168.203.148 || Linux computer that lnfill boots from
|}

When [[Gammasphere]] collects data, single-ended [[Detector Signals|signals]] are first collected from the slope box for the Ge Center, Ge Sides, and BGO segment. The signals are converted to differential signals by the [[The Slope Box Extension|SBX]], and are then sent to the collector box so the signals can properly be routed to the digitizers. The digitizers process and output the desired information to the user based upon their data specifications. The DAQ system is an FPGA-based design that provides communication hub interfacing the [[Preamplifier|preamp]], power board, dongle and slope box to EPICS through serial interface. Analog signal paths are completely software controlled.
==DAQ System Function==
The DAQ system prior to upgrades consisted of VME crates, IOC Modules, Digitizers and Trigger Modules. There were two types of Digitizers (Master and Slave) and well as Trigger (Master and Router). All channels in all digitizers run continuously. When discriminator logic marks leading edges of gamma-ray signals, energy sums, timing and other data are stored in a header identifying the event. If the event is selected for readout by the trigger system, the header and a programmable amount of waveform is transferred from the channel to the board-wide FIFO (first in, first out) data holder. The IOC scans the FIFOs to see if there is data to read out. If so, the IOC reads it out into buffers. A program called “gtReceiver” sends messages to each IOC when the receiver is ready for more data. The IOC then breaks apart buffers into UDP packets and sends them to gtReceiver. The gtReceiver program then routes the packets to files that may be organized by digitizer or by channel.
<imagemap>
Image:DAQSystem.png|center|thumb|700px|Figure 2. Diagram of the DAQ system process.
rect 454 225 478 241 [[Gammasphere Detectors]]
rect 550 225 575 242 [[Gammasphere Detectors]]
rect 642 225 665 241 [[Gammasphere Detectors]]
poly 451 211 449 224 481 224 480 213 [[The Slope Box]]
poly 546 212 545 224 575 224 576 216 [[The Slope Box]]
poly 637 209 637 222 667 223 667 214 [[The Slope Box]]
rect 435 211 448 222 [[The Slope Box Extension]]
rect 532 213 544 223 [[The Slope Box Extension]]
rect 624 211 635 221[[The Slope Box Extension]]
</imagemap>

''To view how this system is controlled, go to [[DGS Commander EDM Screens]].''

''Go back to [[Digital Gammasphere Upgrade Project]]''

DAQ system

2023-03-29T20:53:27Z

Jta:

'''''This is an image map. Click on a section of the picture to go to the page for that item.'''''
<imagemap>
Image:GammasphereDAQupgrade.jpg|700px|center|thumb|Figure 1. DAQ System circled in red; one rack for each of the four "hemispheres" of Gammasphere
poly 135 204 209 219 258 192 250 266 213 293 137 268 [[VME Crates]]
poly 904 385 977 402 1030 373 1029 438 979 470 904 452 [[VME Crates]]
poly 1039 326 1097 339 1143 308 1148 378 1096 406 1058 376 1027 364 [[VME Crates]]
poly 134 167 135 197 209 217 257 184 256 162 208 185 [[Collector Box]]
poly 906 347 906 367 977 395 1022 369 1025 345 977 367 [[Collector Box]]
poly 1034 287 1103 301 1146 275 1146 299 1100 323 1042 311 [[Collector Box]]
poly 199 104 137 158 206 175 269 139 [[DAQ Power Supply]]
poly 312 42 253 96 317 113 375 58 [[DAQ Power Supply]]
poly 902 339 966 285 1034 321 976 356 [[DAQ Power Supply]]
poly 1021 274 1081 225 1140 242 1089 293 [[DAQ Power Supply]]
poly 445 151 432 123 398 113 351 138 305 218 291 285 290 337 300 382 336 429 370 423 421 413 356 454 276 423 251 353 252 293 267 219 304 138 344 95 379 79 428 88 472 135 [[Liquid Nitrogen]]
poly 838 557 809 506 804 446 808 384 828 320 865 258 911 222 960 212 1010 233 1021 293 991 288 969 251 950 241 935 239 901 264 876 300 860 331 846 378 839 428 839 470 847 516 850 532[[Liquid Nitrogen]]
poly 502 374 499 305 519 251 564 207 615 184 660 181 713 195 759 233 783 277 796 329 788 382 764 427 710 470 648 483 587 471 533 431 [[Gammasphere|Gammasphere frame (without detectors in it)]]
</imagemap>
Gammasphere's DAQ system (data acquisition system) is now placed on relay racks by each side of its "hemispheres". Each of the racks for the DAQ consists of a [[DAQ Power Supply|power supply]], a [[Collector Box|collector box]], and a [[VME Crates|VME crate]]. The data acquisition system observes, interprets, and modifies data taken from [[Gammasphere]] and appropriately presents it to the user.

The picture above provides an overall map to the naming conventions associated with the system. Cardinal directions are shown in '''purple''' text, process variable (EPICS) names are shown in '''green''' text and network IDs are shown in '''red''' text. There are multiple computers within the DAQ system:

{| class="wikitable"
|+ Network names and IP addresses of the devices within Digital Gammasphere
|-
! Network name !! IP address !! Description
|-
| ioc01: || 192.168.203.141 || MVME5500 VME processor used for control and readout
|-
| ioc02: || 192.168.203.142 || MVME5500 VME processor used for control and readout
|-
| ioc03: || 192.168.203.143 || MVME5500 VME processor used for control and readout
|-
| ioc04: || 192.168.203.144 || MVME5500 VME processor used for control and readout
|-
| ioc05: || 192.168.203.145 || MVME5500 VME processor used for control and readout
|-
| ioc06: || 192.168.203.177 || MVME5500 VME processor used for control and readout
|-
| ioc07: || 192.168.203.178 || MVME5500 VME processor used for control and readout
|-
| ioc08: || 192.168.203.179 || MVME5500 VME processor used for control and readout
|-
| ioc09: || 192.168.203.180 || MVME5500 VME processor used for control and readout
|-
| ioc10: || 192.168.203.183 || MVME5500 VME processor used for control and readout
|-
| ioc11: || 192.168.203.181 || MVME5500 VME processor used for control and readout
|-
| ioc12: || 192.168.203.182 || MVME5500 VME processor used for control and readout
|-
| gs-cne || 192.168.203.88 || Raspberry Pi inside the North East Collector box
|-
| gs-cnw || 192.168.203.149 || Raspberry Pi inside the North West Collector box
|-
| gs-cse || 192.168.203.42 || Raspberry Pi inside the South East Collector box
|-
| gs-csw || 192.168.203.26 || Raspberry Pi inside the South West Collector box
|-
| gs-pdu-north || 192.168.203.224 || Power Distribution Unit for the North Hemisphere
|-
| gs-pdu_south || 192.168.203.225 || Power Distribution Unit for the North Hemisphere
|-
| gs-ts-north || 192.168.203.91 || Terminal server providing console port access for ioc07 through ioc12
|-
| gs-ts_south || 192.168.203.186 || Terminal server providing console port access for ioc01 through ioc06
|-
| lnfill || 192.168.203.121 || Embedded VME processor that hosts the EPICS databases for valve status and valve control
|-
ln2con || 192.168.203.148 || Linux computer that lnfill boots from
|}

When [[Gammasphere]] collects data, single-ended [[Detector Signals|signals]] are first collected from the slope box for the Ge Center, Ge Sides, and BGO segment. The signals are converted to differential signals by the [[The Slope Box Extension|SBX]], and are then sent to the collector box so the signals can properly be routed to the digitizers. The digitizers process and output the desired information to the user based upon their data specifications. The DAQ system is an FPGA-based design that provides communication hub interfacing the [[Preamplifier|preamp]], power board, dongle and slope box to EPICS through serial interface. Analog signal paths are completely software controlled.
==DAQ System Function==
The DAQ system prior to upgrades consisted of VME crates, IOC Modules, Digitizers and Trigger Modules. There were two types of Digitizers (Master and Slave) and well as Trigger (Master and Router). In the current version of the upgraded Gammasphere DAQ system, some of the old hardware is still used, but in a different way. All channels in all digitizers run continuously. When discriminator logic marks leading edges of gamma-ray signals, energy sums, timing and other data are stored in a header identifying the event. If the event is selected for readout by the trigger system, the header and a programmable amount of waveform is transferred from the channel to the board-wide FIFO (first in, first out) data holder. The IOC scans the FIFOs to see if there is data to read out. If so, the IOC reads it out into buffers. A program called “gtReceiver” sends messages to each IOC when the receiver is ready for more data. The IOC then breaks apart buffers into UDP packets and sends them to gtReceiver. The gtReceiver program then routes the packets to files that may be organized by digitizer or by channel.
<imagemap>
Image:DAQSystem.png|center|thumb|700px|Figure 2. Diagram of the DAQ system process.
rect 454 225 478 241 [[Gammasphere Detectors]]
rect 550 225 575 242 [[Gammasphere Detectors]]
rect 642 225 665 241 [[Gammasphere Detectors]]
poly 451 211 449 224 481 224 480 213 [[The Slope Box]]
poly 546 212 545 224 575 224 576 216 [[The Slope Box]]
poly 637 209 637 222 667 223 667 214 [[The Slope Box]]
rect 435 211 448 222 [[The Slope Box Extension]]
rect 532 213 544 223 [[The Slope Box Extension]]
rect 624 211 635 221[[The Slope Box Extension]]
</imagemap>

''To view how this system is controlled, go to [[DGS Commander EDM Screens]].''

''Go back to [[Digital Gammasphere Upgrade Project]]''

DAQ system

2023-03-29T20:38:26Z

Jta:

'''''This is an image map. Click on a section of the picture to go to the page for that item.'''''
<imagemap>
Image:GammasphereDAQupgrade.jpg|700px|center|thumb|Figure 1. DAQ System circled in red; one rack for each of the four "hemispheres" of Gammasphere
poly 135 204 209 219 258 192 250 266 213 293 137 268 [[VME Crates]]
poly 904 385 977 402 1030 373 1029 438 979 470 904 452 [[VME Crates]]
poly 1039 326 1097 339 1143 308 1148 378 1096 406 1058 376 1027 364 [[VME Crates]]
poly 134 167 135 197 209 217 257 184 256 162 208 185 [[Collector Box]]
poly 906 347 906 367 977 395 1022 369 1025 345 977 367 [[Collector Box]]
poly 1034 287 1103 301 1146 275 1146 299 1100 323 1042 311 [[Collector Box]]
poly 199 104 137 158 206 175 269 139 [[DAQ Power Supply]]
poly 312 42 253 96 317 113 375 58 [[DAQ Power Supply]]
poly 902 339 966 285 1034 321 976 356 [[DAQ Power Supply]]
poly 1021 274 1081 225 1140 242 1089 293 [[DAQ Power Supply]]
poly 445 151 432 123 398 113 351 138 305 218 291 285 290 337 300 382 336 429 370 423 421 413 356 454 276 423 251 353 252 293 267 219 304 138 344 95 379 79 428 88 472 135 [[Liquid Nitrogen]]
poly 838 557 809 506 804 446 808 384 828 320 865 258 911 222 960 212 1010 233 1021 293 991 288 969 251 950 241 935 239 901 264 876 300 860 331 846 378 839 428 839 470 847 516 850 532[[Liquid Nitrogen]]
poly 502 374 499 305 519 251 564 207 615 184 660 181 713 195 759 233 783 277 796 329 788 382 764 427 710 470 648 483 587 471 533 431 [[Gammasphere|Gammasphere frame (without detectors in it)]]
</imagemap>
Gammasphere's DAQ system (data acquisition system) is now placed on relay racks by each side of its "hemispheres". Each of the racks for the DAQ consists of a [[DAQ Power Supply|power supply]], a [[Collector Box|collector box]], and a [[VME Crates|VME crate]]. The data acquisition system observes, interprets, and modifies data taken from [[Gammasphere]] and appropriately presents it to the user.

The picture above provides an overall map to the naming conventions associated with the system. Cardinal directions are shown in '''purple''' text, process variable (EPICS) names are shown in '''green''' text and network IDs are shown in '''red''' text. There are multiple computers within the DAQ system:

{| class="wikitable"
|+ Network names and IP addresses of the devices within Digital Gammasphere
|-
! Network name !! IP address !! Description
|-
| ioc01: || 192.168.203.141 || MVME5500 VME processor used for control and readout
|-
| ioc02: || 192.168.203.142 || MVME5500 VME processor used for control and readout
|-
| ioc03: || 192.168.203.143 || MVME5500 VME processor used for control and readout
|-
| ioc04: || 192.168.203.144 || MVME5500 VME processor used for control and readout
|-
| ioc05: || 192.168.203.145 || MVME5500 VME processor used for control and readout
|-
| ioc06: || 192.168.203.177 || MVME5500 VME processor used for control and readout
|-
| ioc07: || 192.168.203.178 || MVME5500 VME processor used for control and readout
|-
| ioc08: || 192.168.203.179 || MVME5500 VME processor used for control and readout
|-
| ioc09: || 192.168.203.180 || MVME5500 VME processor used for control and readout
|-
| ioc10: || 192.168.203.183 || MVME5500 VME processor used for control and readout
|-
| ioc11: || 192.168.203.181 || MVME5500 VME processor used for control and readout
|-
| ioc12: || 192.168.203.182 || MVME5500 VME processor used for control and readout
|-
| gs-cne || 192.168.203.88 || Raspberry Pi inside the North East Collector box
|-
| gs-cnw || 192.168.203.149 || Raspberry Pi inside the North West Collector box
|-
| gs-cse || 192.168.203.42 || Raspberry Pi inside the South East Collector box
|-
| gs-csw || 192.168.203.26 || Raspberry Pi inside the South West Collector box
|-
| gs-pdu-north || 192.168.203.224 || Power Distribution Unit for the North Hemisphere
|-
| gs-pdu_south || 192.168.203.225 || Power Distribution Unit for the North Hemisphere
|-
| gs-ts-north || 192.168.203.91 || Terminal server providing console port access for ioc07 through ioc12
|-
| gs-ts_south || 192.168.203.186 || Terminal server providing console port access for ioc01 through ioc06
|-
| ln2con || 192.168.203.148 || Linux computer that controls and monitors the liquid nitrogen fill system
|-
| lnfill || 192.168.203.121 || Embedded VME processor that hosts the EPICS databases for valve status and valve control
|}

When [[Gammasphere]] collects data, single-ended [[Detector Signals|signals]] are first collected from the slope box for the Ge Center, Ge Sides, and BGO segment. The signals are converted to differential signals by the [[The Slope Box Extension|SBX]], and are then sent to the collector box so the signals can properly be routed to the digitizers. The digitizers process and output the desired information to the user based upon their data specifications. The DAQ system is an FPGA-based design that provides communication hub interfacing the [[Preamplifier|preamp]], power board, dongle and slope box to EPICS through serial interface. Analog signal paths are completely software controlled.
==DAQ System Function==
The DAQ system prior to upgrades consisted of VME crates, IOC Modules, Digitizers and Trigger Modules. There were two types of Digitizers (Master and Slave) and well as Trigger (Master and Router). In the current version of the upgraded Gammasphere DAQ system, some of the old hardware is still used, but in a different way. All channels in all digitizers run continuously. When discriminator logic marks leading edges of gamma-ray signals, energy sums, timing and other data are stored in a header identifying the event. If the event is selected for readout by the trigger system, the header and a programmable amount of waveform is transferred from the channel to the board-wide FIFO (first in, first out) data holder. The IOC scans the FIFOs to see if there is data to read out. If so, the IOC reads it out into buffers. A program called “gtReceiver” sends messages to each IOC when the receiver is ready for more data. The IOC then breaks apart buffers into UDP packets and sends them to gtReceiver. The gtReceiver program then routes the packets to files that may be organized by digitizer or by channel.
<imagemap>
Image:DAQSystem.png|center|thumb|700px|Figure 2. Diagram of the DAQ system process.
rect 454 225 478 241 [[Gammasphere Detectors]]
rect 550 225 575 242 [[Gammasphere Detectors]]
rect 642 225 665 241 [[Gammasphere Detectors]]
poly 451 211 449 224 481 224 480 213 [[The Slope Box]]
poly 546 212 545 224 575 224 576 216 [[The Slope Box]]
poly 637 209 637 222 667 223 667 214 [[The Slope Box]]
rect 435 211 448 222 [[The Slope Box Extension]]
rect 532 213 544 223 [[The Slope Box Extension]]
rect 624 211 635 221[[The Slope Box Extension]]
</imagemap>

''To view how this system is controlled, go to [[DGS Commander EDM Screens]].''

''Go back to [[Digital Gammasphere Upgrade Project]]''

DAQ system

2023-03-29T20:36:31Z

Jta:

'''''This is an image map. Click on a section of the picture to go to the page for that item.'''''
<imagemap>
Image:GammasphereDAQupgrade.jpg|700px|center|thumb|Figure 1. DAQ System circled in red; one rack for each of the four "hemispheres" of Gammasphere
poly 135 204 209 219 258 192 250 266 213 293 137 268 [[VME Crates]]
poly 904 385 977 402 1030 373 1029 438 979 470 904 452 [[VME Crates]]
poly 1039 326 1097 339 1143 308 1148 378 1096 406 1058 376 1027 364 [[VME Crates]]
poly 134 167 135 197 209 217 257 184 256 162 208 185 [[Collector Box]]
poly 906 347 906 367 977 395 1022 369 1025 345 977 367 [[Collector Box]]
poly 1034 287 1103 301 1146 275 1146 299 1100 323 1042 311 [[Collector Box]]
poly 199 104 137 158 206 175 269 139 [[DAQ Power Supply]]
poly 312 42 253 96 317 113 375 58 [[DAQ Power Supply]]
poly 902 339 966 285 1034 321 976 356 [[DAQ Power Supply]]
poly 1021 274 1081 225 1140 242 1089 293 [[DAQ Power Supply]]
poly 445 151 432 123 398 113 351 138 305 218 291 285 290 337 300 382 336 429 370 423 421 413 356 454 276 423 251 353 252 293 267 219 304 138 344 95 379 79 428 88 472 135 [[Liquid Nitrogen]]
poly 838 557 809 506 804 446 808 384 828 320 865 258 911 222 960 212 1010 233 1021 293 991 288 969 251 950 241 935 239 901 264 876 300 860 331 846 378 839 428 839 470 847 516 850 532[[Liquid Nitrogen]]
poly 502 374 499 305 519 251 564 207 615 184 660 181 713 195 759 233 783 277 796 329 788 382 764 427 710 470 648 483 587 471 533 431 [[Gammasphere|Gammasphere frame (without detectors in it)]]
</imagemap>
Gammasphere's DAQ system (data acquisition system) is now placed on relay racks by each side of its "hemispheres". Each of the racks for the DAQ consists of a [[DAQ Power Supply|power supply]], a [[Collector Box|collector box]], and a [[VME Crates|VME crate]]. The data acquisition system observes, interprets, and modifies data taken from [[Gammasphere]] and appropriately presents it to the user.

The picture above provides an overall map to the naming conventions associated with the system. Cardinal directions are shown in '''purple''' text, process variable (EPICS) names are shown in '''green''' text and network IDs are shown in '''red''' text. There are multiple computers within the DAQ system:

{| class="wikitable"
|+ Caption text
|-
! NodeName(ssh) !! IP address !! Description
|-
| ioc01: || 192.168.203.141 || MVME5500 VME processor used for control and readout
|-
| ioc02: || 192.168.203.142 || MVME5500 VME processor used for control and readout
|-
| ioc03: || 192.168.203.143 || MVME5500 VME processor used for control and readout
|-
| ioc04: || 192.168.203.144 || MVME5500 VME processor used for control and readout
|-
| ioc05: || 192.168.203.145 || MVME5500 VME processor used for control and readout
|-
| ioc06: || 192.168.203.177 || MVME5500 VME processor used for control and readout
|-
| ioc07: || 192.168.203.178 || MVME5500 VME processor used for control and readout
|-
| ioc08: || 192.168.203.179 || MVME5500 VME processor used for control and readout
|-
| ioc09: || 192.168.203.180 || MVME5500 VME processor used for control and readout
|-
| ioc10: || 192.168.203.183 || MVME5500 VME processor used for control and readout
|-
| ioc11: || 192.168.203.181 || MVME5500 VME processor used for control and readout
|-
| ioc12: || 192.168.203.182 || MVME5500 VME processor used for control and readout
|-
| gs-cne || 192.168.203.88 || Raspberry Pi inside the North East Collector box
|-
| gs-cnw || 192.168.203.149 || Raspberry Pi inside the North West Collector box
|-
| gs-cse || 192.168.203.42 || Raspberry Pi inside the South East Collector box
|-
| gs-csw || 192.168.203.26 || Raspberry Pi inside the South West Collector box
|-
| gs-pdu-north || 192.168.203.224 || Power Distribution Unit for the North Hemisphere
|-
| gs-pdu_south || 192.168.203.225 || Power Distribution Unit for the North Hemisphere
|-
| gs-ts-north || 192.168.203.91 || Terminal server providing console port access for ioc07 through ioc12
|-
| gs-ts_south || 192.168.203.186 || Terminal server providing console port access for ioc01 through ioc06
|-
| ln2con || 192.168.203.148 || Linux computer that controls and monitors the liquid nitrogen fill system
|-
| lnfill || 192.168.203.121 || Embedded VME processor that hosts the EPICS databases for valve status and valve control
|}

When [[Gammasphere]] collects data, single-ended [[Detector Signals|signals]] are first collected from the slope box for the Ge Center, Ge Sides, and BGO segment. The signals are converted to differential signals by the [[The Slope Box Extension|SBX]], and are then sent to the collector box so the signals can properly be routed to the digitizers. The digitizers process and output the desired information to the user based upon their data specifications. The DAQ system is an FPGA-based design that provides communication hub interfacing the [[Preamplifier|preamp]], power board, dongle and slope box to EPICS through serial interface. Analog signal paths are completely software controlled.
==DAQ System Function==
The DAQ system prior to upgrades consisted of VME crates, IOC Modules, Digitizers and Trigger Modules. There were two types of Digitizers (Master and Slave) and well as Trigger (Master and Router). In the current version of the upgraded Gammasphere DAQ system, some of the old hardware is still used, but in a different way. All channels in all digitizers run continuously. When discriminator logic marks leading edges of gamma-ray signals, energy sums, timing and other data are stored in a header identifying the event. If the event is selected for readout by the trigger system, the header and a programmable amount of waveform is transferred from the channel to the board-wide FIFO (first in, first out) data holder. The IOC scans the FIFOs to see if there is data to read out. If so, the IOC reads it out into buffers. A program called “gtReceiver” sends messages to each IOC when the receiver is ready for more data. The IOC then breaks apart buffers into UDP packets and sends them to gtReceiver. The gtReceiver program then routes the packets to files that may be organized by digitizer or by channel.
<imagemap>
Image:DAQSystem.png|center|thumb|700px|Figure 2. Diagram of the DAQ system process.
rect 454 225 478 241 [[Gammasphere Detectors]]
rect 550 225 575 242 [[Gammasphere Detectors]]
rect 642 225 665 241 [[Gammasphere Detectors]]
poly 451 211 449 224 481 224 480 213 [[The Slope Box]]
poly 546 212 545 224 575 224 576 216 [[The Slope Box]]
poly 637 209 637 222 667 223 667 214 [[The Slope Box]]
rect 435 211 448 222 [[The Slope Box Extension]]
rect 532 213 544 223 [[The Slope Box Extension]]
rect 624 211 635 221[[The Slope Box Extension]]
</imagemap>

''To view how this system is controlled, go to [[DGS Commander EDM Screens]].''

''Go back to [[Digital Gammasphere Upgrade Project]]''

DAQ system

2023-03-29T20:30:08Z

Jta:

File:GammasphereDAQupgrade.jpg

2023-03-29T20:17:09Z

Jta: Jta uploaded a new version of File:GammasphereDAQupgrade.jpg

DAQ System circled in red

File:GammasphereDAQupgrade.jpg

2023-03-29T20:15:44Z

Jta: Jta uploaded a new version of File:GammasphereDAQupgrade.jpg

DAQ System circled in red

EPICS control of digitizers

2023-03-29T18:28:25Z

Jta: Created page with "EPICS (xperimental Physics and Industrial Control System) is a framework of software that provides a distributed database of ''process variables'' (PVs) shared among an arbitr..."

EPICS (xperimental Physics and Industrial Control System) is a framework of software that provides a distributed database of ''process variables'' (PVs) shared among an arbitrary number of computers, known within EPICS documentation as IOCs (Input-Output Controllers). By itself, EPICS does nothing of use, but it is a communications framework upon which control systems are built. The ''process variables'' are bits, multi-bit groups, integer words and floating point values that represent states or values within the data acquisition system. Process variables are connected to actual hardware by developing ''device driver'' software that communicates with the hardware in the format the hardware requires and by developing ''device support'' software that connects process variables to the device drivers to either read information from the hardware for display to the user (monitoring) or to cause writes to the hardware when the user changes the value of a process variable (control).

== User interface to process variables ==
The user interfaces with process variables either through graphical user interfaces (GUIs) or by command-line operations. Digital Gammasphere uses the EDM (Extensible Display Manager) as its GUI. Everything in the GUI screens is either text, simplistic graphics, monitoring objects that display the value of PVs, control objects that allow users to change the value of PVs or links to other screens or scripts. On the command line, the 'caget' command allows the user to read the value of a PV and the 'caput' command allows the user to set a PV to a new value.

== Databases ==
Process variables are defined using database files that enumerate all the PVs in the system. Each PV is a 'record' that defines the type of PV that it is and has a field (INP or OUT) that provides the linkage information needed to connect the PV to the name of some hardware register. Each PV also has a DTYP field that defines which device support software package will process the PV. "Input", or "read", or "monitoring" PVs will typically have a SCAN field that specifies how often they are read and processed. "Output", "write" or "control" PVs only process when changed.

== Building the DGS EPICS system ==
DGS (Digital Gammasphere) contains multiple VME crates each with some number of digitizer and/or trigger boards under the control of an IOC (MVME5500 processor board running the VxWorks operating system). Each VME IOC runs '''''multiple''''' threads of software of which EPICS is just one. EPICS is a lower priority thread than the readout software, and EPICS is not the readout software.

In addition to the VME IOCs, the four Collector Boxes each contain a Raspberry Pi model 3b+ running Raspbian Linux, and one of the threads running on each Collector Box is EPICS making each of these four Raspberry Pis an IOC.

There is also an embedded VME processor board in the liquid nitrogen system that is an EPICS IOC, and finally Linux machine DGS1 is also an IOC.

All of these IOCs host databases containing PVs related to the hardware that each IOC is directly connected to, with the exception of DGS1. The IOC of DGS1 connects to no data acquisition hardware directly, and is used only to run process variables that connect to other process variables. Examples of this are

* Overall system controls such as Run/Stop or Save/NoSave
* Global values that, once changed, then propagate throughout the system to cause many hardware-connected PVs to all take on the value of the global PV
* Miscellaneous conversion/calculation PVs that take values from hardware-related PVs to generate monitoring values in a more pleasant format for the human to read

== Root sources of information ==
The root source of all EPICS information are the '''Code Generating Spreadsheets''' maintained in a Subversion repository by the engineers of the Low Energy Technical Support group. These Excel spreadsheets enumerate all the registers within the firmware of each device (digitizer, SBX, collector box, trigger, etc.) throughout Digital Gammasphere. Code within these spreadsheets (Visual Basic for Applications, or VBA) uses text template files to write all EPICS database files used throughout the system. If a firmware upgrade occurs, the engineer updates the physical register maps in the spreadsheet, hits a button and a few seconds later all the databases are rewritten to match.

=== Building the IOC device support ===
The device support for the VME IOCs is a mix of C and C++ code that is maintained on the same Subversion repository (https://svn.inside.anl.gov/repos/dgs) as the code generating spreadsheets. As the MVME5500 VME processors run VxWorks, a cross-compiler is required. An ancient Solaris machine (con6.phy.anl.gov) is the sole and only host of the cross-compiler license. This ancient machine has no disk drives of its own and uses a part of the shared disk structure used by all the Linux boxes in the data room. However, one must log in to this machine to use its software.

* The full path to where the code is stored is /dk/fs2/dgs/global_sandbox/devel/.
* When logged into machine con6 as user dgs, this path now shows as /global/devel
* Beneath this path are two subfolders, dgsDrivers and dgsIoc.
** dgsDrivers is the device support code.
** dgsIoc is a "psuedo project" in that there's no code here, it's just used for the cross compilation.

==== Specific compilation steps on con6 ====

* log in to machine con6 as user dgs.
* cd /global/devel/dgsDrivers
* make clean
* make
** You should get 0 warnings and 0 errors. Anything else is failure.
* cd ../dgsIoc
* make clean
* make
** You should get 0 warnings and 0 errors. Anything else is failure.

==== Updating the code from the code generating spreadsheets ====
If the firmware has been updated and the spreadsheets modified, running the VBA code for the different spreadsheets will, in addition to writing databases, also write C code that is part of the con6 compile. There are three spreadsheets associated with this:

* The DGS_CSDigitizer spreadsheet models the digitizers and writes two files used by con6.
* The DGS_MTrig spreadsheet models the master trigger and writes two files used by con6.
* The DGS_RTrig spreadsheet models the router triggers and writes two files used by con6.

If any spreadsheet has been changed and re-run, the files generated thereby must be copied to machine con6 before a recompile. This is done by entering the commands

* cd /global/devel/dgsDrivers/dgsDriverApp/src
* ./Export_SVN_ParameterFiles.sh

The Bash script will ask for a username and password for access to the Subversion repository and also ask for the password to ssh into machine DGS1 for the Subversion operations, because machine con6 has no working copy of the Subversion client.

File:Dig pic 53.png

2021-09-20T15:53:28Z

Jta:

File:Dig pic 52.png

2021-09-20T15:53:18Z

Jta:

File:Dig pic 51.png

2021-09-20T15:53:08Z

Jta:

File:Dig pic 50.png

2021-09-20T15:52:58Z

Jta:

File:Dig pic 47.png

2021-09-20T15:52:49Z

Jta:

File:Dig pic 44.png

2021-09-20T15:52:39Z

Jta:

File:Dig pic 43.png

2021-09-20T15:52:26Z

Jta:

File:Dig pic 42.png

2021-09-20T15:52:17Z

Jta:

File:Dig pic 41.png

2021-09-20T15:52:07Z

Jta:

File:Dic pic 40.png

2021-09-20T15:51:46Z

Jta:

File:Dig pic 39.png

2021-09-20T15:51:09Z

Jta: cfd discriminator pre-arming

== Summary ==
cfd discriminator pre-arming

File:Dig pic 38.png

2021-09-20T15:50:40Z

Jta: led mode waveform overlay

== Summary ==
led mode waveform overlay