Difference between revisions of "Translation Table"
(Created page with "=Introduction= The translation table is responsible for converting digitized values indexed by Crate, Slot, Channel into detector specific indexing. For example, BCAL: Module, La...") |
|||
| Line 1: | Line 1: | ||
| − | =Introduction= | + | = Introduction = |
| − | The translation table is responsible for converting digitized values indexed by Crate, Slot, Channel into detector specific indexing. For example, BCAL: Module, Layer, Sector, End. Over 27k channels are defined for the GlueX detector with each subsystem having its own natural indexing system. The BCAL, for instance requires 4 indices (Module, Layer, Sector, End) while the Start Counter requires only one (Sector). | + | The translation table is responsible for converting digitized values indexed by Crate, Slot, Channel into detector specific indexing. For example, BCAL: Module, Layer, Sector, End. Over 27k channels are defined for the GlueX detector with each subsystem having its own natural indexing system. The BCAL, for instance requires 4 indices (Module, Layer, Sector, End) while the Start Counter requires only one (Sector). This page provides information on the Translation Table including how to access it and how to change it. |
| + | = History = | ||
The origin of the TT data was a large Excel Spreadsheet maintained by Fernando Barbosa in [http://argus.phys.uregina.ca/cgi-bin/private/DocDB/ShowDocument?docid=2293 DocDB with document ID=2293]. [https://halldsvn.jlab.org/repos/trunk/online/packages/TranslationTable Scripts] were written to read from this and write the information into a SQLite DB file. The SQLite DB file was then modified to include information formatted in a way convenient for use in the control system applications. This single SQLite file now serves as the definitive source of translation table information for both the controls and DAQ electronics. The file is kept in the subversion repository here: | The origin of the TT data was a large Excel Spreadsheet maintained by Fernando Barbosa in [http://argus.phys.uregina.ca/cgi-bin/private/DocDB/ShowDocument?docid=2293 DocDB with document ID=2293]. [https://halldsvn.jlab.org/repos/trunk/online/packages/TranslationTable Scripts] were written to read from this and write the information into a SQLite DB file. The SQLite DB file was then modified to include information formatted in a way convenient for use in the control system applications. This single SQLite file now serves as the definitive source of translation table information for both the controls and DAQ electronics. The file is kept in the subversion repository here: | ||
| Line 7: | Line 8: | ||
This, however, is not the end of the story. Offline software requires a history mechanism for the TT so if values are changed (e.g. a cable is swapped during a maintenance period), then a new version can be used without preventing us from processing data taken with the old TT. Thus, for the purposes of Offline Software, the TT is converted into an XML file and stored in the CCDB. This also makes it easily accessible to offline software using the existing CCDB interface. In order to put the TT into the CCDB, it must first be converted into XML using one script and then inserted using another script. It is important to emphasize that the above mentioned SQLite file should be maintained as the definitive source of TT information, even for the offline software. If a change needs to be made, it should be made to that file and then regenerate the tt.xml file from that. Don't just modify a tt.xml file downloaded from the CCDB and reinsert it! | This, however, is not the end of the story. Offline software requires a history mechanism for the TT so if values are changed (e.g. a cable is swapped during a maintenance period), then a new version can be used without preventing us from processing data taken with the old TT. Thus, for the purposes of Offline Software, the TT is converted into an XML file and stored in the CCDB. This also makes it easily accessible to offline software using the existing CCDB interface. In order to put the TT into the CCDB, it must first be converted into XML using one script and then inserted using another script. It is important to emphasize that the above mentioned SQLite file should be maintained as the definitive source of TT information, even for the offline software. If a change needs to be made, it should be made to that file and then regenerate the tt.xml file from that. Don't just modify a tt.xml file downloaded from the CCDB and reinsert it! | ||
| + | |||
| + | = Implementation = | ||
| + | |||
| + | == Controls == | ||
| + | |||
| + | == Offline Analysis of DAQ Data == | ||
| + | |||
| + | == Simulated Data == | ||
= Useful Links= | = Useful Links= | ||
Revision as of 22:38, 12 April 2014
Contents
Introduction
The translation table is responsible for converting digitized values indexed by Crate, Slot, Channel into detector specific indexing. For example, BCAL: Module, Layer, Sector, End. Over 27k channels are defined for the GlueX detector with each subsystem having its own natural indexing system. The BCAL, for instance requires 4 indices (Module, Layer, Sector, End) while the Start Counter requires only one (Sector). This page provides information on the Translation Table including how to access it and how to change it.
History
The origin of the TT data was a large Excel Spreadsheet maintained by Fernando Barbosa in DocDB with document ID=2293. Scripts were written to read from this and write the information into a SQLite DB file. The SQLite DB file was then modified to include information formatted in a way convenient for use in the control system applications. This single SQLite file now serves as the definitive source of translation table information for both the controls and DAQ electronics. The file is kept in the subversion repository here:
https://halldsvn.jlab.org/repos/trunk/controls/epics/app/hvCaenApp/src/tt.db
This, however, is not the end of the story. Offline software requires a history mechanism for the TT so if values are changed (e.g. a cable is swapped during a maintenance period), then a new version can be used without preventing us from processing data taken with the old TT. Thus, for the purposes of Offline Software, the TT is converted into an XML file and stored in the CCDB. This also makes it easily accessible to offline software using the existing CCDB interface. In order to put the TT into the CCDB, it must first be converted into XML using one script and then inserted using another script. It is important to emphasize that the above mentioned SQLite file should be maintained as the definitive source of TT information, even for the offline software. If a change needs to be made, it should be made to that file and then regenerate the tt.xml file from that. Don't just modify a tt.xml file downloaded from the CCDB and reinsert it!
Implementation
Controls
Offline Analysis of DAQ Data
Simulated Data
Useful Links
The following are some useful links:
- scripts in svn repository:
https://halldsvn.jlab.org/repos/trunk/online/packages/TranslationTable - Visual translation table broswer
