ID |
Date |
Author |
Topic |
Subject |
563
|
04 Mar 2009 |
Dawei Liu | Forum | Analyzer gets killed cm_watchdog |
Hello Midas experts:
We have setup a DAQ using MIDAS to readout two ADCs in the crate.
We are running into problem of analyzer getting killed between
runs. Sometimes it would crash after a few runs and sometimes it
would go on for many many runs before analyzer gets killed. It always
occurred between runs not when we are taking data. Any suggestions
on what we could try? The error message from the midas.log file is
appended below.
Thanks,
Dawei
Wed Mar 4 11:53:11 2009 [Analyzer,ERROR] [midas.c:1739:,ERROR]
cm_disconnect_experiment not called at end of program
Wed Mar 4 11:53:22 2009 [mhttpd,INFO] Client 'Analyzer' on buffer 'SYSMSG'
removed by cm_watchdog (idle 10.7s,TO 10s)
Wed Mar 4 11:53:22 2009 [mhttpd,INFO] Client 'Analyzer' (PID 1) on buffer 'ODB'
removed by cm_watchdog (idle 10.7s,TO 10s)
Wed Mar 4 11:53:22 2009 [AL Experiment Frontend,INFO] Client 'Analyzer' on
buffer 'SYSTEM' removed by cm_watchdog (idle 10.9s,TO 10s)
Wed Mar 4 11:53:29 2009 [AL Experiment Frontend,TALK] starting new run
Wed Mar 4 11:53:29 2009 [AL Experiment Frontend,ERROR]
[midas.c:8264:rpc_client_check,ERROR] Connection broken to "Analyzer" on host
tsunami |
564
|
24 Mar 2009 |
Stefan Ritt | Forum | Analyzer gets killed cm_watchdog | Hi,
your log script sound to me like the analyzer either got into an infinite loop or
did a segment violation and just died. I would recommend to run the analyzer from
inside the debugger. When you then get the segment violation, you can inspect the
stack trace and see where the bad things happen. Since the analyzer works nicely in
other experiment, I expect that your problem is related to the user code. Maybe it
happens at the end of the run, but there is a timeout before the crashed process
gets cleaned from the ODB, that's why you might think that it happens "between"
runs.
Best regards,
Stefan
>
> Hello Midas experts:
>
> We have setup a DAQ using MIDAS to readout two ADCs in the crate.
> We are running into problem of analyzer getting killed between
> runs. Sometimes it would crash after a few runs and sometimes it
> would go on for many many runs before analyzer gets killed. It always
> occurred between runs not when we are taking data. Any suggestions
> on what we could try? The error message from the midas.log file is
> appended below.
>
> Thanks,
>
> Dawei
>
> Wed Mar 4 11:53:11 2009 [Analyzer,ERROR] [midas.c:1739:,ERROR]
> cm_disconnect_experiment not called at end of program
> Wed Mar 4 11:53:22 2009 [mhttpd,INFO] Client 'Analyzer' on buffer 'SYSMSG'
> removed by cm_watchdog (idle 10.7s,TO 10s)
> Wed Mar 4 11:53:22 2009 [mhttpd,INFO] Client 'Analyzer' (PID 1) on buffer 'ODB'
> removed by cm_watchdog (idle 10.7s,TO 10s)
> Wed Mar 4 11:53:22 2009 [AL Experiment Frontend,INFO] Client 'Analyzer' on
> buffer 'SYSTEM' removed by cm_watchdog (idle 10.9s,TO 10s)
> Wed Mar 4 11:53:29 2009 [AL Experiment Frontend,TALK] starting new run
> Wed Mar 4 11:53:29 2009 [AL Experiment Frontend,ERROR]
> [midas.c:8264:rpc_client_check,ERROR] Connection broken to "Analyzer" on host
> tsunami |
436
|
18 Feb 2008 |
Jimmy Ngai | Bug Report | Analyzer cannot run as Daemon | Hi All,
I'm testing MIDAS SVN rev-4113 on Scientific Linux 5.1 (i386) and the Analyzer
can't start as Daemon. What I mean "can't" is that it stops running
immediately without leaving any error messages. However, it can run offline or
without becoming a Daemon. I have tested with ROOT 5.14e/5.16/5.18 and
the "Experiment" example coming with MIDAS and this problem always happens.
Any ideas?
Best Regards,
Jimmy |
2438
|
14 Oct 2022 |
Lars Martin | Suggestion | Allow onchange to refer to arbitrary js function | Maybe this is already possible, I have a hard time understanding the mhttpd source code.
I would like to use a function defined in the <script> block of my custom page as an onchange callback.
Specific example:
I have an modbthermo that I would like to change to three different colours for "too cold", "just right", and "too hot" (measuring porridge, presumably). The examples only show the explicit (condition)?(val1):(val2) syntax, which doesn't allow more than two values, so I had hoped to replace
onchange="this.dataset.color=this.value > 40?'red':'blue';"
with something like
onchange="this.dataset.color=check_Temp(this.value);"
or
onchange="check_Temp(this.value, this.dataset.color);"
if that's easier somehow. The function itself would then return the colour string, or set the color argument to that string (I'm not sure if JS passes references or just values.)
Is this a possibility? |
2439
|
14 Oct 2022 |
Ben Smith | Info | Allow onchange to refer to arbitrary js function | > I would like to use a function defined in the <script> block of my custom page as an onchange callback.
>
> Is this a possibility?
Yes, this is already possible. An example was shown in the "modb" section of the custom page documentation, but not in the "Changing properties of controls dynamically" section. I've updated the wiki with an example.
https://daq00.triumf.ca/MidasWiki/index.php/Custom_Page#Changing_properties_of_controls_dynamically |
2440
|
22 Oct 2022 |
Lars Martin | Info | Allow onchange to refer to arbitrary js function | I figured I wasn't the first to have this idea.
Works great, thanks! |
2442
|
22 Oct 2022 |
Lars Martin | Info | Allow onchange to refer to arbitrary js function | Actually, now that I look again, there is a mistake in the instructions:
you say
onchange="this.dataset.color=check_therm(this)"
but check_therm doesn't return anything and instead changes the color itself. So you either want the function to return the string and use the above assignment, or use the function you provide and use
onchange="check_therm(this)" |
1191
|
23 Aug 2016 |
Andreas Suter | Forum | Alarm/Warning | Midas has a nice alarm system. I am wondering whether it is easily possible to
get the Alarm/Warning banner also on top of custom pages?! |
1192
|
23 Aug 2016 |
Stefan Ritt | Forum | Alarm/Warning | > Midas has a nice alarm system. I am wondering whether it is easily possible to
> get the Alarm/Warning banner also on top of custom pages?!
K.O. made nice JavaScript routines to access the alarm status. The new alarm page is completely
made dynamically from JavaScript code (mhttpd does not supply any HTML code any more, only
functions to obtain ODB values etc). Part of this new dynamic page must be some code to display
the alarm status. You just need to copy this to your custom page. K.O. can tell you details.
Stefan |
1206
|
30 Sep 2016 |
Konstantin Olchanski | Forum | Alarm/Warning | > > Midas has a nice alarm system. I am wondering whether it is easily possible to
> > get the Alarm/Warning banner also on top of custom pages?!
>
> K.O. made nice JavaScript routines to access the alarm status. The new alarm page is completely
> made dynamically from JavaScript code (mhttpd does not supply any HTML code any more, only
> functions to obtain ODB values etc). Part of this new dynamic page must be some code to display
> the alarm status. You just need to copy this to your custom page. K.O. can tell you details.
>
Yes, please look at resources/alarm.html and the "get_alarms" JSON-RPC method. The "get_alarms" example in
resources/example.html probably already does exactly what you need. Also note the presence of "al_reset_alarm" and
"al_trigger_alarm" JSON_RPC methods.
K.O. |
2411
|
19 Jun 2022 |
Francesco Renga | Forum | Alarm on variable not updating | Dear all,
I've an ODB equipment that sometimes loses the connection with the hardware, so that the variables are not updated anymore. The connection can be restored by restarting the frontend. It would be useful to have an alarm based on the time from the last update of some variable (i.e. the alarm is triggered if the variable is not updated for more than X seconds). Is there a method to implement such an alarm in MIDAS?
Thank you very much,
Francesco |
2413
|
20 Jun 2022 |
Stefan Ritt | Forum | Alarm on variable not updating | There are two functions to do that, one check the last write access, the other the last write access if the run is running. The alarm condition looks like:
access(/Equipment/.../Variables/Input[10]) > 60
which will cause an alarm if the Input[10] is not written for more than 60 seconds. The other function which checks the run status as well is like:
access_running(...odb key...) > 60
You can actually see an example on the MEG alarm page.
Rather than having an alarm for that I would however recommend that you program you frontend such that it realizes if it looses connections, then tries automatically to reconnect or trigger an alarm itself (so-called "internal" alarm). This is also how the MSCB system is working and is much more robust.
Stefan |
2
|
11 Aug 2003 |
Konstantin Olchanski | | Alarm on no ping? | I want midas alarms to go off when I cannot ping arbitrary remote hosts. Is
there is easy/preferred way to do this? K.O. |
4
|
18 Dec 2003 |
Stefan Ritt | | Alarm on no ping? | > I want midas alarms to go off when I cannot ping arbitrary remote hosts. Is
> there is easy/preferred way to do this? K.O.
There are "internal alarms" with type AT_EVALUATED. Just find a program
where you can put some code which gets periodically executed (like the idle
loop in the frontend), and so something like:
DWORD last = 0;
if (ss_time() > last+60)
{
last = ss_time();
/* do a ping via socket(), bind() and connect() */
...
if (status != CM_SUCCESS)
al_trigger_alarm("XYZ Ping", str, "Warning",
"Host is dead", AT_INTERNAL);
}
Pierre does the same thing in lazylogger.c, just have a look. I don't know
how to do a ping correctly in C, I guess you have to send an UDP packet
somewhere, but I never did it. If you find it out, please post it.
|
412
|
17 Oct 2007 |
Randolf Pohl | Forum | Adding MIDAS .root-files | Dear MIDAS users,
I want to add several .root-files produced by the MIDAS analyzer, in a fast
and convenient way. ROOT's hadd fails because it does not know how to treat
TFolders. I guess this problem is not unique to me, so I hope that somebody of
you might already have found a solution.
Why don't I just run "analyzer -r 1 10000"?
We have taken lots of runs under (rapidly) varying conditions, so it would be
lots of "-r". And the analysis is quite involved, so rerunning all data takes
about one hour on a fast PC making this quite painful.
Therefore, I would like to rerun all data only once, and then add the result
files depending on different criteria.
Of course, I tried to write a script that does the adding. But somehow it is
incredibly slow. And I am not the Master Of C++, too.
Is there any deeper reason for MIDAS using TFolders, not TDirectorys? ROOT's
hadd can treat TDirectory. Can I simply patch "my" MIDAS? Is there general
interest in a change like this? (Does anyone have experience with the speed of
hadd?)
Looking forward to comments from the Forum.
Cheers,
Randolf |
415
|
17 Oct 2007 |
John M O'Donnell | Forum | Adding MIDAS .root-files | The following program handles regular directories in a file, or folders (ugh).
Most histograms are added bin by bin.
For scaler events it is convenient to see the counts as a function of time (ala
sclaer history plots in mhttpd). If the histogram looks like a scaler plot versus
time, then new bins are added on to the end (or into the middle!) of the histogram.
All different versions of cuts are kept.
TTrees are not explicitly supported, so probably don't do the right thing...
John.
> Dear MIDAS users,
>
> I want to add several .root-files produced by the MIDAS analyzer, in a fast
> and convenient way. ROOT's hadd fails because it does not know how to treat
> TFolders. I guess this problem is not unique to me, so I hope that somebody of
> you might already have found a solution.
>
> Why don't I just run "analyzer -r 1 10000"?
> We have taken lots of runs under (rapidly) varying conditions, so it would be
> lots of "-r". And the analysis is quite involved, so rerunning all data takes
> about one hour on a fast PC making this quite painful.
> Therefore, I would like to rerun all data only once, and then add the result
> files depending on different criteria.
>
> Of course, I tried to write a script that does the adding. But somehow it is
> incredibly slow. And I am not the Master Of C++, too.
>
> Is there any deeper reason for MIDAS using TFolders, not TDirectorys? ROOT's
> hadd can treat TDirectory. Can I simply patch "my" MIDAS? Is there general
> interest in a change like this? (Does anyone have experience with the speed of
> hadd?)
>
> Looking forward to comments from the Forum.
>
> Cheers,
>
> Randolf |
Attachment 1: histoAdd.cxx
|
#include <iostream>
#include <vector>
#include <iterator>
#include <cstring>
using namespace std;
#include "TROOT.h"
#include "TFile.h"
#include "TString.h"
#include "TDirectory.h"
#include "TObject.h"
#include "TClass.h"
#include "TKey.h"
#include "TH1.h"
#include "TAxis.h"
#include "TMath.h"
#include "TCutG.h"
#include "TFolder.h"
bool verbose (false);
TFolder *histosFolder (0);
//==============================================================================
void addObject (TObject *o, const TString &prefix, TFolder *opFolder=0);
/** called for each file to do the addition.
* loops over each object in the file, and
* uses addObject to dispatch the actuall addition.
*/
void add (TFile *file, const TString &prefix) {
//------------------------------------------------------------------------------
TString dirName (file->GetName());
if (verbose) cout << " scanning TFile" << endl;
TString newPrefix (prefix + dirName + "/");
TIter i (file->GetListOfKeys());
while (TKey *k = static_cast<TKey *>( i())) {
TObject *o (file->Get( k->GetName()));
addObject( o, newPrefix);
}
return;
}
//==============================================================================
/** Most histograms are added bin by bin, but if simpleAdd == false,
* the xaxis values are assumed different, in which case we look up
* appropriate bin numbers, and use a new extended xaxis if needed.
*
* Use simpleAdd=false to accumulate scaler rate histograms.
*/
void add (const TH1 *newh, TH1 *&hsum, TFolder *opFolder) {
//------------------------------------------------------------------------------
const bool simpleAdd (newh->GetXaxis()->GetTimeDisplay() ? false : true);
if (!hsum) {
hsum = (TH1 *)newh->Clone();
TString title = "histoAdd: ";
title += hsum->GetTitle();
if (opFolder) hsum->SetDirectory( 0);
}
else if (simpleAdd) hsum->Add( newh);
else { // extend axis - for 1D histos with equal sized bins
size_t nBinsSum = hsum->GetNbinsX();
size_t nBinsNew = newh->GetNbinsX();
vector<Double_t>bin_contents;
vector<Double_t>histo_edges;
Int_t holder_bins;
/* foundBin is either the overflow bin (if the 2 histograms don't overlap)
* or it is the bin number in histoA that has the same low edge as the
* lowest bin edge in histoB. The only time that histograms can overlap
* is when the older scaler.cxx is used to create the histograms with
* fixed bin sizes.
*/
Int_t foundBin = hsum->FindBin( newh->GetBinLowEdge(1) );
histo_edges.resize(foundBin);
bin_contents.resize(foundBin);
for( int i = 1; i <= foundBin; i++ ) {
histo_edges[i-1] = hsum->GetBinLowEdge(i);
bin_contents[i-1] = hsum->GetBinContent(i);
}
if(foundBin < nBinsSum) {
//the histos overlap or we have already made holder bins
holder_bins = 0;
}
else {
//create a "place holder" histo
Int_t width = 10;
holder_bins = (int)((newh->GetXaxis()->GetXmin()
- hsum->GetXaxis()->GetXmax())/width);
if( holder_bins < width ) holder_bins = width;
TH1F *bin_holder = new TH1F("bin_holder", "bin_holder", holder_bins,
hsum->GetXaxis()->GetXmax(),
newh->GetXaxis()->GetXmin() );
histo_edges.resize( foundBin + holder_bins );
bin_contents.resize( foundBin + holder_bins );
for( int i = 0; i < holder_bins; i++ ) {
histo_edges[foundBin+i] = bin_holder->GetBinLowEdge(i+2);
bin_contents[foundBin+i] = 0;
}
delete bin_holder;
} //end else
histo_edges.resize( foundBin + holder_bins + nBinsNew+1 );
bin_contents.resize( foundBin + holder_bins + nBinsNew+1 );
for( int i = 0; i <= nBinsNew; i++ ) {
histo_edges[i+foundBin+holder_bins] = newh->GetBinLowEdge(i+1);
bin_contents[i+foundBin+holder_bins] = newh->GetBinContent(i+1);
}
hsum->SetBins( histo_edges.size()-1, &histo_edges[0] );
for ( int i=1; i<histo_edges.size(); ++i) {
hsum->SetBinContent( i, bin_contents[i-1]);
}
if (opFolder) {
//opFolder->Remove( hsum);
//opFolder->Add( exth);
hsum->SetDirectory( 0);
}
}
if (verbose) {
if (simpleAdd) cout << " adding counts";
else cout << " tagging on bins";
cout << endl;
}
return;
}
//==============================================================================
/** Most cuts are written out just once, but if a cut is different from
* the most recently written version of a cut with the same name, then
* another copy of the cut is written out. Thus if a cut changes during
* a series of runs, all versions of the cut will be present in the
* summed file.
*/
void add (const TCutG *o, TCutG *&oOut, TFolder *opFolder) {
//------------------------------------------------------------------------------
const char *name (o->GetName());
bool write (false);
if (!oOut) write = true;
else {
Int_t n (o->GetN());
if (n != oOut->GetN()) write = true;
else {
double x1, x2, y1, y2;
for (Int_t i=0; i<n; ++i) {
o ->GetPoint( i, x1, y1);
oOut->GetPoint( i, x2, y2);
if ((x1 != x2) || (y1 != y2)) write = true;
}
}
}
if (write) {
if (verbose) {
if (oOut) cout << " changed";
cout << " TCutG" << endl;
}
if (!opFolder) {
oOut = const_cast<TCutG *>( o);
o->Write( name, TObject::kSingleKey);
} else {
TCutG *clone = static_cast<TCutG *>( o->Clone());
if (oOut) opFolder->Add( clone);
oOut = clone;
}
} else if (verbose) cout << endl;
return;
}
//==============================================================================
/** for most objects, we keep just the first version.
*/
void add (const TObject *o, TObject *&oSum, TFolder *opFolder) {
//------------------------------------------------------------------------------
const char *name (o->GetName());
if (!oSum) {
if (verbose) cout << " saving TObject" << endl;
if (!opFolder) o->Write( name, TObject::kSingleKey);
} else {
if (verbose) cout << endl;
}
return;
}
//==============================================================================
/** create the new directory and then start adding its contents
*/
void add (TDirectory *dir, TDirectory *&sumDir,
TFolder *opFolder, const TString &prefix) {
//------------------------------------------------------------------------------
TDirectory *currentDir (gDirectory);
TString dirName (dir->GetName());
if (verbose) cout << " scanning TDirectory" << endl;
TString newPrefix (prefix + dirName + "/");
if (!sumDir) sumDir = gDirectory->mkdir( dirName);
sumDir->cd();
TIter i (dir->GetListOfKeys());
while (TKey *k = static_cast<TKey *>( i())) {
TObject *o (dir->Get( k->GetName()));
addObject( o, newPrefix, opFolder);
}
currentDir->cd();
return;
}
//==============================================================================
/** create a new folder and then start adding its contents
*/
void add (const TFolder *folder, TFolder *&sumFolder,
TFolder *parentFolder, const TString &prefix) {
//------------------------------------------------------------------------------
if (verbose) cout << " scanning TFolder" << endl;
const char *name (folder->GetName());
TString newPrefix (prefix + name + "/");
if (!sumFolder) sumFolder = new TFolder (name, name);
if (!histosFolder) histosFolder = sumFolder;
TIter i (folder->GetListOfFolders());
while (TObject *o = i()) addObject( o, newPrefix, sumFolder);
return;
}
//==============================================================================
int main (int argc, char **argv) {
//------------------------------------------------------------------------------
if (argc < 3) {
cerr << argv[0] << ": out_root_file in_root_file1 in_root_file2 ..." << endl;
return 1;
}
TROOT root ("histoadd", "histoadd");
root.SetBatch();
TString opFileName (argv[1]);
TFile *opFile (TFile::Open( opFileName, "RECREATE"));
if (!opFile) {
cerr << argv[0] << ": unable to open file: " << argv[1] << endl;
return 1;
}
--argc;
++argv;
... 95 more lines ...
|
1012
|
10 Jul 2014 |
Clemens Sauerzopf | Forum | Adding Interrupt handling to SIS3100 driver | Hello,
we are using the Struck SIS 3100 VME interface for our experiment, but the midas
driver doesn't have interrupt control integrated. Previously we were happy with
just periodic readout, but our requirements have changed so I thought I could
just implement this as there is a demo program provided by Struck on how to use
their driver with interrupts.
Could you recommend an existing midas driver that has a good implementation of
the midas interrupt functions (mvme_interrupt_*) just for me too use as a guideline?
Best regards,
Clemens Sauerzopf |
1013
|
11 Jul 2014 |
Pierre-Andre Amaudruz | Forum | Adding Interrupt handling to SIS3100 driver | > Hello,
>
> we are using the Struck SIS 3100 VME interface for our experiment, but the midas
> driver doesn't have interrupt control integrated. Previously we were happy with
> just periodic readout, but our requirements have changed so I thought I could
> just implement this as there is a demo program provided by Struck on how to use
> their driver with interrupts.
>
> Could you recommend an existing midas driver that has a good implementation of
> the midas interrupt functions (mvme_interrupt_*) just for me too use as a guideline?
>
> Best regards,
> Clemens Sauerzopf
Hi Clemens,
We did have interrupt handling at some point under VxWorks and later with Linux, but it
has always been a challenge.
As you may have found, the current frontend (mfe.c) still has some code to that purpose.
But I wouldn't guarantee that recent development related to multi-threading didn't
affect the expected interrupt operation (not been tested).
Now-a-days, I would suggest that you encapsulate your interrupt handling function based
on the provided software into a independent thread started by a standard midas frontend.
While the main frontend task could operate a periodic equipment as you've done so far, a
polling equipment would poll on the data availability from the ring buffer. The readout
function would compose the appropriate data bank.
This method has the advantage to decouple all the interrupt timing/restriction related
issues from midas and run a conventional frontend. The ring buffer functions are part of
midas (rb_...()).
Example for multi-threading can be found in examples/mtfe which include the use of the
ring buffer as well.
Cheers, PAA |
1015
|
14 Jul 2014 |
Clemens Sauerzopf | Forum | Adding Interrupt handling to SIS3100 driver | Hi Pierre-Andre,
thanks for your comments. If I understand you correctly you are advising to separate the
triggering based on the interrupt signal and the actual data readout. In principal wouldn't
it be also possible to facilitate the multi-threading equipment type to poll the trigger
signal? Then veto new triggers and start the readout of the different detector modules by a
"manual trigger" ?
I'll check the example you've recommended to compare the different solutions.
By the way I've written a driver for the CAEN V1742 VME module, it's working but the code is
currently not in a "nice" state. but if you are interested I could provide the driver code.
Cheers,
Clemens
> > Hello,
> >
> > we are using the Struck SIS 3100 VME interface for our experiment, but the midas
> > driver doesn't have interrupt control integrated. Previously we were happy with
> > just periodic readout, but our requirements have changed so I thought I could
> > just implement this as there is a demo program provided by Struck on how to use
> > their driver with interrupts.
> >
> > Could you recommend an existing midas driver that has a good implementation of
> > the midas interrupt functions (mvme_interrupt_*) just for me too use as a guideline?
> >
> > Best regards,
> > Clemens Sauerzopf
>
> Hi Clemens,
>
> We did have interrupt handling at some point under VxWorks and later with Linux, but it
> has always been a challenge.
> As you may have found, the current frontend (mfe.c) still has some code to that purpose.
> But I wouldn't guarantee that recent development related to multi-threading didn't
> affect the expected interrupt operation (not been tested).
>
> Now-a-days, I would suggest that you encapsulate your interrupt handling function based
> on the provided software into a independent thread started by a standard midas frontend.
> While the main frontend task could operate a periodic equipment as you've done so far, a
> polling equipment would poll on the data availability from the ring buffer. The readout
> function would compose the appropriate data bank.
>
> This method has the advantage to decouple all the interrupt timing/restriction related
> issues from midas and run a conventional frontend. The ring buffer functions are part of
> midas (rb_...()).
> Example for multi-threading can be found in examples/mtfe which include the use of the
> ring buffer as well.
>
> Cheers, PAA |
1016
|
15 Jul 2014 |
Pierre-Andre Amaudruz | Forum | Adding Interrupt handling to SIS3100 driver | Hello Clemens,
The hardware readout is triggered by the interrupt within this thread. The main thread poll on
the data availability (from the rb) to filter/compose the frontend event.
In a similar multi-threaded implementation presently used in a dark matter experiment we start
as many thread as necessary to constantly poll on the hardware for "data fragment" collection.
The event composition is done in the main thread through polling on the RBs.
Depending on the trigger rate and readout time, we can afford to analyze the data fragment at
the thread level and add computed/summary information to the ring buffer on a event-by-event
basis. This facilitate the overall event filtering happening later on in our event builder.
"polling the trigger signal?", I don't understand. You can poll on the trigger condition but
then you don't need interrupt.
The original Midas interrupt implementation was to let the interrupt function set a acknowledge
flag which is picked up by the standard midas polling function (user code) for triggering the
readout. This method ensure a minimal time spent in the IRQ and works fine for a single thread.
In regards of the CAEN V1742, we do have a VME driver for it, but it hasn't been added to the
Midas yet (quite recent), but please don't hesitate to send us a copy.
Cheers, PAA
> Hi Pierre-Andre,
>
> thanks for your comments. If I understand you correctly you are advising to separate the
> triggering based on the interrupt signal and the actual data readout. In principal wouldn't
> it be also possible to facilitate the multi-threading equipment type to poll the trigger
> signal? Then veto new triggers and start the readout of the different detector modules by a
> "manual trigger" ?
>
> I'll check the example you've recommended to compare the different solutions.
>
> By the way I've written a driver for the CAEN V1742 VME module, it's working but the code is
> currently not in a "nice" state. but if you are interested I could provide the driver code.
>
> Cheers,
> Clemens
>
> > > Hello,
> > >
> > > we are using the Struck SIS 3100 VME interface for our experiment, but the midas
> > > driver doesn't have interrupt control integrated. Previously we were happy with
> > > just periodic readout, but our requirements have changed so I thought I could
> > > just implement this as there is a demo program provided by Struck on how to use
> > > their driver with interrupts.
> > >
> > > Could you recommend an existing midas driver that has a good implementation of
> > > the midas interrupt functions (mvme_interrupt_*) just for me too use as a guideline?
> > >
> > > Best regards,
> > > Clemens Sauerzopf
> >
> > Hi Clemens,
> >
> > We did have interrupt handling at some point under VxWorks and later with Linux, but it
> > has always been a challenge.
> > As you may have found, the current frontend (mfe.c) still has some code to that purpose.
> > But I wouldn't guarantee that recent development related to multi-threading didn't
> > affect the expected interrupt operation (not been tested).
> >
> > Now-a-days, I would suggest that you encapsulate your interrupt handling function based
> > on the provided software into a independent thread started by a standard midas frontend.
> > While the main frontend task could operate a periodic equipment as you've done so far, a
> > polling equipment would poll on the data availability from the ring buffer. The readout
> > function would compose the appropriate data bank.
> >
> > This method has the advantage to decouple all the interrupt timing/restriction related
> > issues from midas and run a conventional frontend. The ring buffer functions are part of
> > midas (rb_...()).
> > Example for multi-threading can be found in examples/mtfe which include the use of the
> > ring buffer as well.
> >
> > Cheers, PAA |
|