DRS4 Forum
  DRS4 Discussion Forum  Not logged in ELOG logo
Entry  Thu Nov 10 04:41:24 2016, Abhishek Rajput, Break Statements in DRS4 Binary to ROOT Macro 
    Reply  Thu Nov 10 09:56:04 2016, Stefan Ritt, Break Statements in DRS4 Binary to ROOT Macro 
       Reply  Thu Nov 10 19:24:52 2016, Abhishek Rajput, Break Statements in DRS4 Binary to ROOT Macro 
          Reply  Thu Nov 10 22:07:40 2016, Stefan Ritt, Break Statements in DRS4 Binary to ROOT Macro 
Message ID: 562     Entry time: Thu Nov 10 22:07:40 2016     In reply to: 560
Author: Stefan Ritt 
Subject: Break Statements in DRS4 Binary to ROOT Macro 

You're right, fread() return the number of objects read, so indeed it should be one if successful.

Abhishek Rajput wrote:

Hello,

I am wondering why the code should be changed to i < sizeof(eh), since doesn't fread(&eh,sizeof(eh),1,f) return 1 in this scenario? I've confirmed with a cout statement that this is the case, so this break condition will therefore always trigger as sizeof(eh) is 32 bytes. 

Either way, I believe I figured out my problem. In my revised version of your code, I had two nested loops, the outer one being a loop over the channels and the inner one being a loop over the events. However, I really should have been doing the reverse considering the binary structure of the file.  Otherwise, the end of the file will be reached for only a single iteration of the channel loop if I choose to loop through all the events in the data file.

Once I modified the code to have the outer loop be over all the events and the inner one be over all the channels, I no longer suffered from breaks in the loops. 

Many thanks for your assistance. 

Abhishek 

Stefan Ritt wrote:

Hi,

fread() returns the number of bytes read and zero (I believe) if there is an end of file. So this break statement is a simple end-of-file test. There might be other erros such as hard disk failures, but these are extremely rare. 

If course the file should not end in the middle of an event header. If it does, it means the file is corrupted and truncated, and we should not continue to read that file, that's why there is the break. The internal file is just a series of bytes, it does not know about the event header, so there will be no "error" if we have for example a missing event header but a voltage array. To be correct, the code should actually read

for (n=0 ; n<5 ; n++) {
      // read event header
      i = fread(&eh, sizeof(eh), 1, f);
      if (i < sizeof(eh))
         break;

Hope this helps,

Stefan

Abhishek Rajput wrote:

Hello,

I recently modified the binary to ROOT convertor written by Stefan (https://midas.psi.ch/elogs/DRS4+Forum/361) so it can decode data taken with any channel or set of channels  on the DRS4. In the process of testing this modifed version for data taken on all 4 channels, I encountered problems with decoding some of the event data. More specifically, upon hitting a certain event in some channel, the histograms for that channel would no longer be filled and the histograms for subsequent channels would not be filled with any event at all. 

After considerable bug hunting, I discovered the source of this problem was due to the break statement in the following code extract from the ROOT to binary macro:

 for (n=0 ; n<5 ; n++) {
      // read event header
      i = fread(&eh, sizeof(eh), 1, f);
      if (i < 1)
         break;

For some events apparently, the event header fails to be read properly (fread line returns 0 in this case). Moreover, when I used the feof and ferror functions on a particular file I was testing, the feof function returned a value of 1.

So my questions deal with two scenarios.

Firstly, in the event of an fread error, is a break statement is necessary? Is it not possible to skip the voltage data for those events whose event header fails to be read properly? Or is it the case that when some "corrupted" event header is encountered, all waveform data subsequent to that event is likewise corrupted? If the former is the case, is it advisable to replace the break condition with an fseek line that advances the position indicator of the stream by an additional 2052*n_channels + 32 bytes (in accordance with the binary file specifications of page 25 on the DRS4 manual) so that the next set of voltage data can be read? 

Secondly, in the case of an end of file error, does there exist any possible solution? Or is such an error an indication of a faulty drs4 channel or corrupted binary file? 

Any help with the aforementioned issues would be greatly appreciated.

 

Abhishek

 

 

 

 

ELOG V3.1.4-80633ba