<div dir="ltr">Hello Mark, Dave, and all<div><br></div><div>I originally called the tagger fixed hodoscope subsystem TAGF back a few weeks when I started implementing the tagger reconstruction. I see that you have started using this, as you have been integrating these DTAGFHit types into your danaevio plugin. But more recently I discovered that Fernando has been using TAGH as a designation for this subsystem. His nomenclature goes back further than mine, and is included in documentation that is being tracked for the project. Since this is a convention rather than a matter of fact, I think it will be simpler to avoid this ambiguity and switch everything in the offline software over to the name TAGH and "hodoscope" rather than TAGF and "fixed array". </div>
<div><br></div><div>M / F in TAGM / TAGF means "movable" vs "fixed"</div><div>M / H in TAGM / TAGH means "microscope" vs "hodoscope"</div><div><br></div><div>This change has already been made in my working copy of sim-recon branch, and I will start checking it in shortly. I am also reconfiguring the tables in ccdb to support the code in the new hits factories, and will follow this new convention in those as well.</div>
<div><br></div><div>-Richard J.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Aug 3, 2014 at 10:07 PM, Richard Jones <span dir="ltr"><<a href="mailto:richard.t.jones@uconn.edu" target="_blank">richard.t.jones@uconn.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello David,<div><br></div><div>Sounds good.</div><div><br></div><div>-Richard J.</div></div><div class="HOEnZb">
<div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Aug 3, 2014 at 8:30 PM, David Lawrence <span dir="ltr"><<a href="mailto:davidl@jlab.org" target="_blank">davidl@jlab.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Hi Richard,<div><br></div><div> Alex S. is the person officially responsible for that particular page so you can coordinate with him.</div>
<div><br></div><div>It looks from the TT that only half of the last fADC250 is populated so in principle, there may be</div><div>another 8 channels available. The current TT actually just lists those as “SPARE”. I guess there is a </div>
<div>tagger meeting tomorrow. Perhaps you could discuss it there and let me know the outcome. I’ll</div><div>hold off updating the SQLite file until I hear what the final plan is.</div><div><br></div><div>Regards,</div><div>
-David</div><div><div><div><br><div><div>On Aug 3, 2014, at 3:39 PM, Richard Jones <<a href="mailto:richard.t.jones@uconn.edu" target="_blank">richard.t.jones@uconn.edu</a>> wrote:</div><br><blockquote type="cite">
<div dir="ltr">David,<div><br></div><div>I am not sure who came up with those numbers, certainly not anyone in our group. What matters is that the total number of cables, splitters, discriminators, tdc and adc spiggots, etc is no less than 120. Beyond that, it is just a matter of changing the maps as you say. Sounds like it is a simple process.</div>
<div><br></div><div>The fiber bundles have 30 fibers each, so we will actually deliver 102 columns, and have 102 sum channels delivering signals to the backplane. Originally I thought we would just leave those outputs disconnected, but if we have 122 readout channels available, we can use them.</div>
<div><br></div><div>-Richard J.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Aug 3, 2014 at 3:28 PM, David Lawrence <span dir="ltr"><<a href="mailto:davidl@jlab.org" target="_blank">davidl@jlab.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div>Hi Richard,<div><br></div><div> Thanks. This explanation makes it clear and is consistent with what is in the XML </div>
<div>you committed to the CCDB. I’ll go ahead and make the necessary changes to the </div><div>SQLite file. I also need to make changes to fix some issues with the FDC so once I’ve</div><div>got those in, I’ll regenerate the tt.xml file from the SQLite and make a new entry into the</div>
<div>CCDB which hopefully will have all known issues fixed.</div><div><br></div><div> It looks like we do need to update the document I mentioned though. It currently</div><div>states the number of scintillators is “102x5” and the readout channels are “97 (column</div>
<div>sums) + 5 individual columns | 122” .</div><div><br></div><div>Regards,</div><div>-David</div><div><div><div><br></div><div><br><div><div>On Aug 3, 2014, at 3:15 PM, Richard Jones <<a href="mailto:richard.t.jones@uconn.edu" target="_blank">richard.t.jones@uconn.edu</a>> wrote:</div>
<br><blockquote type="cite"><div dir="ltr">Hello David,<div><br></div><div>You are close. The array contains 100 columns of 5 fibers each. They are numbered column 1..100 and row 1..5. A few of the fibers are read out individually, and those channels are numbered by their row, column address. These are columns 7, 25, 79, and 97. Because of the way the backplanes are populated, only a few of the columns are instrumented for individual channel readout, every 18'th column starting with 7. I decided to connect the first two and the last two of these 6 to the available 20 readout channels, so hence the 7, 25, 79, and 97.</div>
<div><br></div><div>All of the columns, including 7, 25, 43, 61, 79, and 97 are instrumented with sum circuits for reading out the column sum. We need all of these, including the ones that are ALSO individually read out, because there is more flexible control over the gain on the sum circuits than there is for the individuals. Only the sum signals will actually be used to make tags to be used in the offline; the individual channels are only there to monitor the vertical electron distribution and to allow us to tune the quadruple field for optimal tagging efficiency. To make the nomenclature clear, we designate the individual channels by non-zero row numbers, and the sums we distinguish using row=0.</div>
<div><br></div><div>In summary, we have row=0, column=1..100, and then row=1..5, column=7,25,79,97</div><div><br></div><div>Does that help?</div><div><br></div><div>-Richard Jones</div></div><div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Sun, Aug 3, 2014 at 1:21 PM, David Lawrence <span dir="ltr"><<a href="mailto:davidl@jlab.org" target="_blank">davidl@jlab.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div>Hi Richard,</div><div><br></div><div> I’m looking at changes you committed to the the Translation Table for the TAGM channels and</div><div>some things don’t seem quite right. This may be due to out of date knowledge of the geometry</div>
<div>on my part so let me first describe how I *thought* the geometry is supposed to be for the tagger</div><div>microscope:</div><div><br></div><div>- Scintillating fibers are arranged in columns with 5 fibers each.</div>
<div>- Most of the columns have the 5 fibers summed into a single DAQ channel.</div><div>- Every 20th column has a separate DAQ channel for each of the 5 fibers.</div><div><br></div><div>This seems mostly consistent with what is described in the summary document:</div>
<div><a href="http://argus.phys.uregina.ca/gluex/DocDB/0023/002376/008/halld_summary.pdf" target="_blank">http://argus.phys.uregina.ca/gluex/DocDB/0023/002376/008/halld_summary.pdf</a></div><div><br></div><div>The exception is that the document indicates 97 summed columns instead of the 95 we had in</div>
<div>the original TT.</div><div><br></div><div>What I see in the XML you committed is:</div><div><br></div><div>- columns 7, 25, 79, and 97 have 6 rows (I would have thought they should have 5 rows and be evenly distributed)</div>
<div>- column numbers start at “1” while row numbers start at “0”</div><div><br></div><div>Please confirm that the values in the CCDB are really correct and I will go ahead and </div><div>update the SQLite file. Also, if these are correct, we’ll need to update the </div>
<div>controlled document D00000-00-00-S006.</div><div><br></div><div>Regards,</div><div>-David</div><div><div><br></div><br><div><div>On Aug 1, 2014, at 6:45 PM, Richard Jones <<a href="mailto:richard.t.jones@uconn.edu" target="_blank">richard.t.jones@uconn.edu</a>> wrote:</div>
<br><blockquote type="cite"><div dir="ltr">Hello Mark and all,<div><br></div><div>As we finalize the assembly of the tagger microscope, we need to update the translation tables with the identifiers of the channels that are actually being connected to the DAQ inputs. After speaking with David, I checked out the latest copy of the tt_xml translation table from ccdb, made the appropriate changes, and checked it back in with a brief comment. To do that, I fetched a copy of the add_custom_data.py script found in the TranslationTable package, and ran it from the machine ifarm1101. This seems to have worked. However... words on the wiki suggests that I have been naughty -- note the exclamation point below.</div>
<div><br></div><div> [quoted from <a href="https://halldweb1.jlab.org/wiki/index.php/Translation_Table" target="_blank">https://halldweb1.jlab.org/wiki/index.php/Translation_Table</a>]</div><b>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!</b><div>
<b><br></b></div><div>Modifying the mysql db is one thing; checking changes into a project with a name like "/trunk/controls/epics/..." sounds like it is a bit above my pay grade. Should I really be fiddling with that? Maybe one of you could manage the updating of the definitive copy from the one I just checked into ccdb? Should we have a policy regarding this? I can imagine that detector channel -> DAQ input maps might change frequently during the initial period, as we try to get things set up and working properly.</div>
<div><br></div><div>-Richard Jones</div></div>
</blockquote></div><br></div></div></blockquote></div><br></div>
</blockquote></div><br></div></div></div></div></blockquote></div><br></div>
</blockquote></div><br></div></div></div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>