It would be convenient if the ADAQ file name specified by the user appeared as the preset name when the user clicks the "'ADAQ file name" button to choose a new file name.

For future versions, please add a comment box to save experimental parameters to the root file.

I get the following error when compiling about no member named GetFileComment and SetFileComment.

ssnm2@mri-230-129:~/ADAQAcquisition$ make
-e
Building object file 'build/AAAcquisitionManager.o' ...
clang++ -O2 -Wall -fPIC -pthread -m64 -I/home/ssnm/root/include -ferror-limit=5 -w -I/home/ssnm2/ADAQAcquisition/include -I/home/ssnm2/ADAQ//include -std=c++0x -c -o build/AAAcquisitionManager.o src/AAAcquisitionManager.cc
In file included from src/AAAcquisitionManager.cc:21:
/home/ssnm2/ADAQAcquisition/include/AAAcquisitionManager.hh:93:59: error: no
member named 'GetFileComment' in 'ADAQReadoutManager'
TString GetADAQFileComment() {return TheReadoutManager->GetFileComment();}
~~~~~~~~~~~~~~~~~ ^
/home/ssnm2/ADAQAcquisition/include/AAAcquisitionManager.hh:94:60: error: no
member named 'SetFileComment' in 'ADAQReadoutManager'
void SetADAQFileComment(TString AFC) {TheReadoutManager->SetFileComment(AFC);}
~~~~~~~~~~~~~~~~~ ^
2 errors generated.
make: *** [build/AAAcquisitionManager.o] Error 1

When trigger is set above 4000 ADC, the trigger no longer functions correctly. When viewing waveforms as they are acquired, one sees waveforms below the designated trigger.

In past experiments when two channels were enabled we were forced to run the DPP-PSD firmware in waveform transfer mode. In list mode we were getting empty ROOT files.

Title says it all.

Also ensure that dynamic settings based on PSD mode work properly.

It would be much easier on the user if ADAQAcquisition automatically determined the firmware type, which should be possibly by accessing specific registers/CAENDigitizer functions when first connecting to the device. This would alleviate easy mess-ups on the part of the user. It may also be possible and preferable to use the CAEN provided enumerators to automatically identify the board/device type as well, alleviating the user of yet another place to make mistakes.

Occasionally while using the interface, all radio buttons will have their values reset (not to defaults, but completely cleared). This prevents acquisition until the user manually tracks down all radio buttons across the five settings tabs and resets them.

We are having a LOT of problems because of the unnecessarily complicated data structures. A few clear problems:

• when one channel triggers all the other channels get populated with empty entries
• loading and analyzing of the data is possible only after loading the shared object files that describe the data structure. This makes it impossible (or very hard) to analyze the data on other machines

Currently we have dedicated scripts that have to "filter" the data and write it into a simple TTree.

Instead, I strongly recommend we abandon this data structure and instead write the output to a simple TTree. This will save a lot of headache down the road in the analysis.

Starting the timer does not start data collection.

While in nonupdateable, control-style ttl, and using a timer, the PSD information is not saved. It will save with a continuous graphical display with the same control-style and timer.

For several events, the time stamp value is the same but with different data. I can have up to three events with the same time stamp. My sample rate is 500 with a 40% post-trigger. It appears the smallest time stamp value difference that I can see is 2000.

It appears that when reading out full waveforms with DPP-PSD firmware and applying the PSD integrals that the "short integral" is inverted (e.g. the e-/g "branch" has a greater PSD parameter than the p/n "branch" ...). This is likely to due with how ADAQAcquisition "inverts" CAEN's "short integral" to put it into the more widely used "tail integral".

Correct this behavior for DPP-PSD and full waveform readout/analysis

The DPP-PSD firmware has one very valuable information that we do not use: the trigger count. As the digitizer channel is being triggered, the firmware keeps count of total # of triggers for every channel. This is a very valuable information as it can allow one to empirically determine the total data loss / dead time % , by comparing the trigger count to total event count.

Ensure that the X-axis title is appropriately set for uncalibrated spectra (pulse height, pulse area). At present, it simply says "Pulse value [ADC]"

Self explanatory

PSD Integration regions (short and long) are beginning at the end of the baseline samples rather than at the trigger. This problem occurred on the desktop digitizer and the VT725

Does the ADAQAcquisition have support for optical links such as the A3818?

Signs point to a software bug (hardware tests ruled out equipment failure) that is preventing channels above 0 on the V1725 running DPP-PSD from correctly acquiring data. Triggers occur but no waveform appears. This likely related to device-specific upgrades (V1725 vs DT5790) made in recent versions.

This is something that I have been asking for long time.

Can we please display the count rate (integrated over a second) on the top-right corner of the DAQ window? Back in the days I had implemented a simple cout that would print out the count rate into the terminal. That can be very valuable in diagnosing DAQ issues or understanding what is happening with the system.

Yes, Brian Henderson has implemented a PLOT of the count rate. While that is valuable, very often it doesn't work for a variety of reasons. A simple number would be great.

Pretty much any "clicking" results in a segfault. I am running the older Ubuntu 14.04, via virtual box, and have ROOT 6.04...I'll try to run it on a newer machine.

The persistent storage option to save to a .adaq.root file produces only empty files (plus headers) in Ubuntu 14.04, when using the same saving procedures as on the Red Hat minos desktop lab computer.

Using "Calibrate ADCs" button without connection causes a seg fault. Shouldn't NEED to do this since it can't calibrate without a connection but still annoying to have to restart. Here's the text:

*** Break *** segmentation violation

There was a crash.

This is the entire stack trace of all threads:

#0 0x00007f15cdefc94a in waitpid () from /lib64/libc.so.6
#1 0x00007f15cde77a5b in do_system () from /lib64/libc.so.6
#2 0x00007f15d1878773 in TUnixSystem::StackTrace() () from /usr/local/root-6.06.00/lib/libCore.so
#3 0x00007f15d187a67c in TUnixSystem::DispatchSignals(ESignals) () from /usr/local/root-6.06.00/lib/libCore.so
#4
#5 0x0000000000435125 in AATabSlots::HandleConnectionTextButtons() ()
#6 0x00007f15d65d7027 in ?? ()
#7 0x0000000000000000 in ?? ()

The lines below might hint at the cause of the crash.
If they do not help you then please submit a bug report at
http://root.cern.ch/bugs. Please post the ENTIRE stack trace
from above as an attachment in addition to anything else

that might help us fixing this issue.

#5 0x0000000000435125 in AATabSlots::HandleConnectionTextButtons() ()
#6 0x00007f15d65d7027 in ?? ()
#7 0x0000000000000000 in ?? ()

if the user is saving data to an ADAQ file (waveforms, energy data, PSD data) during an acquisition, attempting to save settings to the ADAQ settings file will cause the ROOT directory to switch from the ADAQ file to the settings file. When the settings file is written and closed, the ROOT directory does not properly return to the ADAQ file. Add a check that prevents saving settings while saving acquired data to an ADAQ file.

When attempting to calibrate, the slider and the dashed red line are offset, and dragging the red line does not update the ADC value shown in the box in the bottom right. Changing the display by adjusting the zoom, etc, tends to make the dashed red line disappear entirely. These issues were not present on the lab desktop computer.

If you need to compile ASIMReadout on Mac OSX then you must change the ASIMReadoutManager.cc to:

include unistd.h

instead of

include sys/unistd.h

During a long 16 hour run. The program froze. Here is the ouput from terminal.

ssnm2@mri-230-129:~$ ADAQAcquisition

*** Break *** segmentation violation

There was a crash.

This is the entire stack trace of all threads:

#0 0x00007f3c6be149be in waitpid () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f3c6bd99f4e in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#2 0x00007f3c6ac38937 in TUnixSystem::StackTrace() () from /home/ssnm/root/lib/libCore.so
#3 0x00007f3c6ac3b223 in TUnixSystem::DispatchSignals(ESignals) () from /home/ssnm/root/lib/libCore.so
#4
#5 0x0000000000435e91 in AAAcquisitionManager::StartAcquisition() ()
#6 0x0000000000482346 in G__ADAQAcquisitionDict_794_0_2 (result7=0x2cbe660, funcname=, libp=, hash=) at build/ADAQAcquisitionDict.cc:3280
#7 0x00007f3c6a0d37cf in Cint::G__CallFunc::Execute(void*) () from /home/ssnm/root/lib/libCint.so
#8 0x00007f3c6abfa90c in TCint::CallFunc_Exec(void_, void_) const () from /home/ssnm/root/lib/libCore.so
#9 0x00007f3c6ab9b527 in TQConnection::ExecuteMethod() () from /home/ssnm/root/lib/libCore.so
#10 0x00007f3c6ab9deb8 in TQObject::Emit(char const*) () from /home/ssnm/root/lib/libCore.so
#11 0x00007f3c6b5ae048 in TGButton::EmitSignals(bool) () from /home/ssnm/root/lib/libGui.so
#12 0x00007f3c6b5aedf6 in TGButton::HandleButton(Event_t*) () from /home/ssnm/root/lib/libGui.so
#13 0x00007f3c6b5f624f in TGFrame::HandleEvent(Event_t*) () from /home/ssnm/root/lib/libGui.so
#14 0x00007f3c6b5c8a6b in TGClient::HandleEvent(Event_t*) () from /home/ssnm/root/lib/libGui.so
#15 0x00007f3c6b5c8bc5 in TGClient::ProcessOneEvent() () from /home/ssnm/root/lib/libGui.so
#16 0x00007f3c6b5c8c2d in TGClient::HandleInput() () from /home/ssnm/root/lib/libGui.so
#17 0x00007f3c6ac3b908 in TUnixSystem::DispatchOneEvent(bool) () from /home/ssnm/root/lib/libCore.so
#18 0x00007f3c6abbc846 in TSystem::InnerLoop() () from /home/ssnm/root/lib/libCore.so
#19 0x00007f3c6abbe524 in TSystem::Run() () from /home/ssnm/root/lib/libCore.so
#20 0x00007f3c6ab61caf in TApplication::Run(bool) () from /home/ssnm/root/lib/libCore.so
#21 0x000000000045f5d2 in main ()

The lines below might hint at the cause of the crash.
If they do not help you then please submit a bug report at
http://root.cern.ch/bugs. Please post the ENTIRE stack trace
from above as an attachment in addition to anything else

that might help us fixing this issue.

#5 0x0000000000435e91 in AAAcquisitionManager::StartAcquisition() ()

When we compute the PSDTotalIntegral and PSDShortIntegral (?) in waveform analysis, we get one result. When we read those values from the DPP-PSD in list mode we get different results. The results are not too different -- about 10% -- but that is still quite significant.

To prevent the user from attempting to store waveform when none are actually readout in DPP-PSD list mode, disable the "Store waveforms" check button under the persistent storage tab when the user is running in DPP-PSD list mode.

We get frequent segmentation faults when two channels are enabled. This happens in particular when the number of samples is vastly different between the two channels.

I did a quick calibration of my detector before acquiring data (in PSD DPP, but using list+waveform mode, saving energy data only). When I open the saved data files, they are not raw ADC, but with my original energy calibration.

Discovered this on Fedora 21, with ADAQAcquisition 1.6.4, acquiring data with a DT590M digitizer and NaI detector. Zach verified with his own equipment (non- PSD DPP).

Sorry if I'm referring to things incorrectly Zach :)

Bug prevents a voltage from being entered into the voltage setpoint in the High Voltage tab. This has only been observed on Channel 1 (-), but has been observed twice on a DT5790M on different computers and digitizers. Channel 0 (+) was behaving normally. Bug was resolved by downloading and running Caen DPP-PSD software. Suspected to be an issue with firmware overcurrent protection.

c++ -g -O2 -Wall -fPIC -pthread -std=c++11 -Wno-deprecated-declarations -m64 -I/usr/local/root/root-6.04.18-build/include -std=c++11 -w -I/home/danagoulianlab/ADAQAcquisition/include -I/home/danagoulianlab/ADAQ/include -c -o build/ADAQAcquisitionDict.o build/ADAQAcquisitionDict.cc
build/ADAQAcquisitionDict.cc:41:43: fatal error: include/AAAcquisitionManager.hh: No such file or directory
 #include "include/AAAcquisitionManager.hh"
                                           ^

Same story here. It looks like too many includes in ADAQAcquisitionDict.cc...

After I select the ultrahigh rate and start acquiring data, it still updates the digitized waveform with the 5730.

Many of the colors used when plotting waveforms/spectra are impossible to see against the white background on almost all monitors. Assign appropriate colors for high-visibility.

While some user actions such as SetLogy() are permissible, attempting to e.g. resize the TCanvas during acquisition will cause a segfault. Is it possible just to "block" such an attempt?

The z-axis for PSD histograms is fixed in log scale. This is sort of annoying particularly given updated color palettes. Either return to linear scale or input an options under the "Graphics" subtab to toggle on/off.

Datafiles are created, but no waveforms (or energy data) are saved when acquiring data with STD firmware (and a HPGe detector). No problems are occurring with DPP firmware (and a LaBr detector). Tried saving data as waveforms, as energy, and with the timed acquisition mode. Files come out with 0 waveforms and ~11 kb in size.

When acquiring data at high rates with channels > 0 and channel != 0, it appears from initial tests that the "Buffer overflow" check does not correctly return that the buffer is overflowing. This is especially apparent when there is a lot of work being done on the "PC side" of the data acquisition (such as plotting every single event and dumping to ROOT, etc, etc). Need to check code both within ADAQAcquisition and within the ADAQControl library.

Zach,

It looks like ADAQ is saving the data with the calibration, i.e. when I save data with the spectrum calibrated, it's saved with the calibration, not with the original ADC values. It did this before and you fixed the issue, so I'm not sure how it's started again. We can troubleshoot sometime if you'd like.

I'm running version 1.6.4,DPP-PSD, running in List only mode, saving energy only.