| ID |
Date |
Author |
Topic |
Subject |
|
720
|
17 Sep 2010 |
Konstantin Olchanski | Info | Added mserver host based access control | In svn rev 4825, I added host based access control to mserver (the MIDAS RPC server). The implementation
is a verbatim copy mhttpd host based access control list (-a command line switch).
Same as for mhttpd, "mserver -a hostname" enables access control and only permits access from listed
host names (supply multiple -a switches for multiple hostnames).
This access control does not apply yet for the MIDAS RPC socket connections between MIDAS clients used
to do RPC callbacks, i.e. to request run transitions. Each MIDAS program is listening for MIDAS RPC
connections on a high TCP port and at present accepts connections from anybody. To implement access
controls one could add "-a" switches to every midas application (lot of work) or fill the access control list
automatically from ODB. mserver still has to use the "-a" command line switches because there is no ODB
connection when it has to accept or reject remote sockets.
svn rev 4825
K.O. |
|
2289
|
14 Oct 2021 |
Amy Roberts | Suggestion | Adding (or improving discoverability) of TID for odbset | Creating an ODB key requires users to know the Type ID that are defined in
https://bitbucket.org/tmidas/midas/src/develop/include/midas.h starting at line 320.
I can't find any information on the Midas Wiki about these values or how to find
them.
Am I missing something obvious? Is there a way to improve how to find these values?
Or is this not the best way to interact with the ODB? |
|
2290
|
15 Oct 2021 |
Stefan Ritt | Suggestion | Adding (or improving discoverability) of TID for odbset | > Creating an ODB key requires users to know the Type ID that are defined in
> https://bitbucket.org/tmidas/midas/src/develop/include/midas.h starting at line 320.
>
> I can't find any information on the Midas Wiki about these values or how to find
> them.
>
> Am I missing something obvious? Is there a way to improve how to find these values?
> Or is this not the best way to interact with the ODB?
Well, you found them in midas.h, so where is the problem?
If you want a more detailed description, just look in the midas documentation (RTFM):
https://midas.triumf.ca/MidasWiki/index.php/Midas_Data_Types
If you want a more modern interface to the ODB without these data types, look here:
https://midas.triumf.ca/MidasWiki/index.php/Odbxx
Best regards,
Stefan |
|
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 |
|
1018
|
06 Aug 2014 |
Clemens Sauerzopf | Forum | Adding Interrupt handling to SIS3100 driver | Hello Pierre-Andre,
thank you for your help with the interrupt handling. To close this case I'll
attach my interrupt
handling code for the SIS 3100 to this post as a reference. Maybe someone wants
to do something
similar in the future.
I've decide to go for a C++ frontend therefore it is a class that handles
everything. The user only
has to provide a function pointer to the constructor that handles the interrupt
bitmask. The
interrupt handling is done with a timedwait within a separate thread.
Cheers,
Clemens
> 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
> |
| Attachment 1: sis3100.hh
|
/*!
\file sis3100.hh
\brief provides an interface for interrupt handling with the Struck SIS3100 VME interface
\author Clemens Sauerzopf <clemens.sauerzopf@oeaw.ac.at>
\date 06.08.2014
\version 1.0
*/
#ifndef __SIS3100_HH__
#define __SIS3100_HH__
#include<stdint.h>
#include<sys/types.h>
#if HAVE_MIDAS__
extern "C" {
#include "midas.h"
#include "sis3100/linux/sis3100_vme_calls.h"
#include "sis3100/linux/sis1100_var.h"
}
#else
#include <pthread.h>
#include "sis3100/linux/sis3100_vme_calls.h"
#include "sis3100/linux/sis1100_var.h"
#endif
//! interrupt frontend handling class for SIS 3100 VME interface with veto gate and trigger generation
/*!
This class provides an easy to use interface for handling interrupts with the Stuck SIS3100 VME
interface. When using this class create an instance and pass an unused device number to the
constructor and a function pointer to handle the interrupt.
The interrupt handling is done in a separate thread that waits with a timeout of 500 ms for a
SIGUSR1 signal from the SIS kernel driver. In case of a timeout the loop checks if a thread stop
signal from midas is present and then waits again for an interrupt. If an interrupt occurs the
interrupt vector is loaded and a veto gate is produced by the @ref startVeto function on the
NIM port 1. Afterwards a user supplied function that takes the interrupt bitask, the highest
interrupt level and its vector as arguments is executed. After that the interrupts get acknowledged
and the veto gate is closed.
This class uses a separate device to avoid race conditions and for the low level interface to the
irq setup.
*/
class sis3100 {
public:
sis3100(int sisDeviceNum, bool (*eventFunction)(int,int,int));
bool enableFrontInterrupts();
bool disbaleFrontInterrupts();
bool enableVMEInterrupts();
bool disbaleVMEInterrupts();
bool enableOutputs();
bool disableOutputs();
static inline void startVeto(int p) {s3100_control_write(p, 0x80, 0x00000001);}
static inline void stopVeto(int p) {s3100_control_write(p, 0x80, 0x00010000);}
static inline void startVeto2(int p) {s3100_control_write(p, 0x80, 0x00000002);}
static inline void stopVeto2(int p) {s3100_control_write(p, 0x80, 0x00020000);}
static inline void generateTrigger(int p) {s3100_control_write(p, 0x80, 0x02000000);}
inline bool isOpen() const {return (p==-1 ? false : true);}
inline void setIsRunning(bool isRun){isRunning = isRun;}
private:
int p; // SIS3100 device handler
u_int32_t iobits;
struct sis1100_irq_ctl irqctl;
struct sis1100_irq_get irqget;
struct sis1100_irq_ack irqack;
sigset_t mask, old_mask;
bool isRunning;
// for testing
#if HAVE_MIDAS__
midas_thread_t thread;
#else
pthread_t thread;
#endif
static
#if HAVE_MIDAS__
INT
#else
void*
#endif
interruptThread(void *param);
struct threadInit {
bool (*eventFunction)(int, int, int);
bool *isRunning;
int p; // SIS3100 device handler
u_int32_t *iobits;
struct sis1100_irq_ctl *irqctl;
struct sis1100_irq_get *irqget;
struct sis1100_irq_ack *irqack;
sigset_t mask;
struct timespec waitTime;
};
threadInit threadData;
};
#endif // compile guard
|
| Attachment 2: sis3100.hh
|
/*!
\file sis3100.hh
\brief provides an interface for interrupt handling with the Struck SIS3100 VME interface
\author Clemens Sauerzopf <clemens.sauerzopf@oeaw.ac.at>
\date 06.08.2014
\version 1.0
*/
#ifndef __SIS3100_HH__
#define __SIS3100_HH__
#include<stdint.h>
#include<sys/types.h>
#if HAVE_MIDAS__
extern "C" {
#include "midas.h"
#include "sis3100/linux/sis3100_vme_calls.h"
#include "sis3100/linux/sis1100_var.h"
}
#else
#include <pthread.h>
#include "sis3100/linux/sis3100_vme_calls.h"
#include "sis3100/linux/sis1100_var.h"
#endif
//! interrupt frontend handling class for SIS 3100 VME interface with veto gate and trigger generation
/*!
This class provides an easy to use interface for handling interrupts with the Stuck SIS3100 VME
interface. When using this class create an instance and pass an unused device number to the
constructor and a function pointer to handle the interrupt.
The interrupt handling is done in a separate thread that waits with a timeout of 500 ms for a
SIGUSR1 signal from the SIS kernel driver. In case of a timeout the loop checks if a thread stop
signal from midas is present and then waits again for an interrupt. If an interrupt occurs the
interrupt vector is loaded and a veto gate is produced by the @ref startVeto function on the
NIM port 1. Afterwards a user supplied function that takes the interrupt bitask, the highest
interrupt level and its vector as arguments is executed. After that the interrupts get acknowledged
and the veto gate is closed.
This class uses a separate device to avoid race conditions and for the low level interface to the
irq setup.
*/
class sis3100 {
public:
sis3100(int sisDeviceNum, bool (*eventFunction)(int,int,int));
bool enableFrontInterrupts();
bool disbaleFrontInterrupts();
bool enableVMEInterrupts();
bool disbaleVMEInterrupts();
bool enableOutputs();
bool disableOutputs();
static inline void startVeto(int p) {s3100_control_write(p, 0x80, 0x00000001);}
static inline void stopVeto(int p) {s3100_control_write(p, 0x80, 0x00010000);}
static inline void startVeto2(int p) {s3100_control_write(p, 0x80, 0x00000002);}
static inline void stopVeto2(int p) {s3100_control_write(p, 0x80, 0x00020000);}
static inline void generateTrigger(int p) {s3100_control_write(p, 0x80, 0x02000000);}
inline bool isOpen() const {return (p==-1 ? false : true);}
inline void setIsRunning(bool isRun){isRunning = isRun;}
private:
int p; // SIS3100 device handler
u_int32_t iobits;
struct sis1100_irq_ctl irqctl;
struct sis1100_irq_get irqget;
struct sis1100_irq_ack irqack;
sigset_t mask, old_mask;
bool isRunning;
// for testing
#if HAVE_MIDAS__
midas_thread_t thread;
#else
pthread_t thread;
#endif
static
#if HAVE_MIDAS__
INT
#else
void*
#endif
interruptThread(void *param);
struct threadInit {
bool (*eventFunction)(int, int, int);
bool *isRunning;
int p; // SIS3100 device handler
u_int32_t *iobits;
struct sis1100_irq_ctl *irqctl;
struct sis1100_irq_get *irqget;
struct sis1100_irq_ack *irqack;
sigset_t mask;
struct timespec waitTime;
};
threadInit threadData;
};
#endif // compile guard
|
|
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 ...
|
|
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.
|
|
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 |
|
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. |
|
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! |
|