Back Midas Rome Roody Rootana
  Midas DAQ System, Page 1 of 121  Not logged in ELOG logo
New entries since:Wed Dec 31 16:00:00 1969
ID Date Author Topicdown Subject
  160   13 Oct 2004 Konstantin OlchanskiSuggestionNo al_clear_alarm()?
We have al_trigger_alarm(), but no matching al_clear_alarm(), and I need it to
clear my alarm once the alarm condition no longer exists. Any objections if I
add this function? K.O.
  161   13 Oct 2004 Stefan RittSuggestionNo al_clear_alarm()?
> We have al_trigger_alarm(), but no matching al_clear_alarm(), and I need it to
> clear my alarm once the alarm condition no longer exists. Any objections if I
> add this function? K.O.

The idea is that once an alarm got triggered, it stays until the user
acknowledged, even if the alarm condition has been disappeared. Through mhttpd,
the user can press the "Reset" button, which then executes al_reset_alarm().
However, it is possible to call al_reset_alarm() directly from user code to
achieve the same thing.
  162   13 Oct 2004 Konstantin OlchanskiSuggestionNo al_clear_alarm()?
> > We have al_trigger_alarm(), but no matching al_clear_alarm(), and I need it to
> > clear my alarm once the alarm condition no longer exists. Any objections if I
> > add this function? K.O.
> 
> call al_reset_alarm()

Thanks. I must be quite blind as I did not see al_reset_alarm() in midas.h. I se eit
now. Thanks.

K.O.
  189   22 Dec 2004 Stefan RittSuggestionWhat to do with invalid data in the history system?
Dealing with the NaN's in the history system in the past week, a question came
up at PSI about how to deal with invalid history data.

Assume you have several devices going into one history equipment, and one device
has a problem, such that it cannot be read. In the past, the device driver
system returned zero, which was written to the history file. While this is ok in
some cases, it might not be in others, where zero is maybe a valid measurement.
Furthermore, it might confuse some regulations loops.

An alternative is to keep the last correctly measured value. As long as the
device has its problem, the value is kept. However, values are written to the
history system which might look like valid, although they are not. So what about
writing explicitly NaNs to the history system? For the display routine the NaNs
could be omitted, leaving blank regions where no valid measurement is available.
Or one could explicitly mare the region as invalid. Konstantin, do you know how
to write NaN explicitly to a float variable? And what do the others think about
these possibilities?

- Stefan
  190   23 Dec 2004 Stefan RittSuggestionWhat to do with invalid data in the history system?
I preliminary implemented NaNs into the history system. It works such that if a
device driver returns a read error status, the class driver writes a NaN
(Not-a-Number) into the corresponding variable via the new function ss_nan(). The
"mhist" utility directly displays these as "nan" (Linux) or "-1.#IND00" under
Windows, indicating the error status. The history display via mhttpd just skips
these values (see elog:/1). I think this is better than showing just zero values,
because in most cases zero is a valid measurement and could confuse people.

Of course it is not enough just having "gaps" in the history display, so it's
important that the corresponding device driver issues an error message, which could
even trigger an alarm.

I have tested this under Windows, but only compiled under Linux. The only class
driver I modified so far is "multi.c". People should have a look, make some tests,
and let me know if this is a good thing, or if we should change it somehow.

- Stefan
Attachment 1: hist.gif
hist.gif
  191   20 Jan 2005 Konstantin OlchanskiSuggestionHOWTO create ROOT objects in the MIDAS analyzer
With recent changes to mana.c, creation of user ROOT objects in the MIDAS
analyser has changed. Here is the new example code for creating ROOT objects
that are visible in ROODY and are saved into the histogram file.

1) in the "global" context (outside of any function)

#include <TH1D.h>
#include <TProfile.h>

static TH1D* gMyHist1 = 0;
static TProfile* gMyHist2 = 0;

2) In the analyzer "init" or "begin run" method, create the histogram:

//extern TFolder *gManaHistosFolder; // from midas.h
gMyHist1 = new TH1D("gMyHist1",...);
gMyHist2 = new TProfile("gMyHist2",...);
gManaHistosFolder->Add(gMyHist1);
gManaHistosFolder->Add(gMyHist2);

(note: this will produce an warning about "possible memory leak")

3) In the per-event method, fill the histograms

gMyHist1->Fill(x);
gMyHist2->Fill(x,y);

4) In the Makefile, where you compile the frontend, add "-DUSE_ROOT" right after
"-I$(ROOTSYS)/include"

K.O.
  197   25 Jan 2005 John M O'DonnellSuggestionHOWTO create ROOT objects in the MIDAS analyzer
> (preliminary, untested. I will keep this updated as I get testing feedback)
> 
> With recent changes to mana.c, creation of user ROOT objects in the MIDAS
> analyser has changed. Here is the new example code for creating ROOT objects
> that are visible in ROODY and are saved into the histogram file.
> 
> 1) in the "global" context (outside of any function)
> 
> #include <TH1D.h>
> #include <TProfile.h>
> 
> static TH1D* gMyHist1 = 0;
> static TProfile* gMyHist2 = 0;
> 
> 2) In the analyzer "init" or "begin run" method, create the histogram:
> 
> //extern TFolder *gManaHistosFolder; // from midas.h
> gMyHist1 = new TH1D("gMyHist1",...);
> gMyHist2 = new TProfile("gMyHist2",...);
> gManaHistosFolder->Add(gMyHist1);
> gManaHistosFolder->Add(gMyHist2);
> 
> (note: this will produce an warning about "possible memory leak")
> 
> 3) In the per-event method, fill the histograms
> 
> gMyHist1->Fill(x);
> gMyHist2->Fill(x,y);
> 
> K.O.


the book functions provide a convenient place to check against object duplication
and memory leaks etc., and a place to ensure that consistent subfolders are being
used.  eg. a while back we decided that TCutGs should be in a "cuts" subfolder.

To extend the booking to TProfile is fairly easy.  In fact if you want to
use the simple constructor TProfile::TProfile (const char *, const char *, Int_t,
Axis_t, Axis_t), then you could infact just use h1_book<TProfile>.

It now seems to me that the names h1_book, h2_book, cut_book are all too long
and even more upsetting are inconsistent.  Some of them are templates (most) and
some are not.  Perhaps they should all be templates, and all have the same name.
The attached patch accomplishes this (without deleting the old names).  With this
patch you can now do

gMyHist1 = book<TProfile>( "gMyHist2",...);

New book templates are needed when you (1) wish to change the subfolder, or (2)
need to use a different argument list in the constructor.  If you need help with
this for the TProfile constructors which are different from TH1D constructors then
let me know.  They should be easy to do.

For TGraph at lot depends on how you want to initialise the data points.
Attachment 1: book.patch
? linux
? examples/experiment/analyzer
? examples/experiment/frontend
? examples/slowcont/scfe
? gui/hvedit/qt/Makefile
? gui/hvedit/qt/hvEdit
? gui/hvedit/qt/moc_Qt_Connect.cpp
? gui/hvedit/qt/moc_Qt_Pwd.cpp
? gui/hvedit/qt/moc_Qt_hvEdit.cpp
? gui/hvedit/qt/moc_cmExperiment.cpp
? gui/hvedit/qt/Qt_Dlgs/Qt_Connect_Base.cpp
? gui/hvedit/qt/Qt_Dlgs/Qt_Connect_Base.h
? gui/hvedit/qt/Qt_Dlgs/Qt_Pwd_Base.cpp
? gui/hvedit/qt/Qt_Dlgs/Qt_Pwd_Base.h
? gui/hvedit/qt/Qt_Dlgs/Qt_fileList.cpp
? gui/hvedit/qt/Qt_Dlgs/Qt_fileList.h
? gui/hvedit/qt/Qt_Dlgs/Qt_hvEditAbout.cpp
? gui/hvedit/qt/Qt_Dlgs/Qt_hvEditAbout.h
? gui/hvedit/qt/Qt_Dlgs/Qt_hvEdit_Base.cpp
? gui/hvedit/qt/Qt_Dlgs/Qt_hvEdit_Base.h
? gui/hvedit/qt/Qt_Dlgs/moc_Qt_Connect_Base.cpp
? gui/hvedit/qt/Qt_Dlgs/moc_Qt_Pwd_Base.cpp
? gui/hvedit/qt/Qt_Dlgs/moc_Qt_fileList.cpp
? gui/hvedit/qt/Qt_Dlgs/moc_Qt_hvEditAbout.cpp
? gui/hvedit/qt/Qt_Dlgs/moc_Qt_hvEdit_Base.cpp
? gui/hvedit/qt/help/moc_helpwindow.cpp
? include/.midas.h.swp
===================================================================
RCS file: /usr/local/cvsroot/midas/include/midas.h,v
retrieving revision 1.148
diff -r1.148 midas.h
2272a2273,2275
>    template<typename T>
>    T EXPRT *book (const char *name, const char *title,
> 		  int bins, double min, double max)
2276,2278d2278
<    template<typename TH1X>
<    TH1X EXPRT *h1_book(const char *name, const char *title,
< 		       int bins, double min, double max)
2280c2280
<       TH1X *hist;
---
>       T *hist;
2284c2284
<          hist = (TH1X *) gManaHistosFolder->FindObjectAny(name);
---
>          hist = (T *) gManaHistosFolder->FindObjectAny(name);
2286c2286
<          hist = (TH1X *) ((TFolder *)gHistoFolderStack->Last())->FindObjectAny(name);
---
>          hist = (T *) ((TFolder *)gHistoFolderStack->Last())->FindObjectAny(name);
2289c2289
<          hist = new TH1X(name, title, bins, min, max);
---
>          hist = new T(name, title, bins, min, max);
2299,2301c2299,2300
<    template<typename TH1X>
<    TH1X EXPRT *h1_book(const char *name, const char *title,
< 		       int bins, double edges[])
---
>    template<typename T>
>    T EXPRT *book(const char *name, const char *title, int bins, double edges[])
2303c2302
<       TH1X *hist;
---
>       T *hist;
2307c2306
<          hist = (TH1X *) gManaHistosFolder->FindObjectAny(name);
---
>          hist = (T *) gManaHistosFolder->FindObjectAny(name);
2309c2308
<          hist = (TH1X *) ((TFolder *)gHistoFolderStack->Last())->FindObjectAny(name);
---
>          hist = (T *) ((TFolder *)gHistoFolderStack->Last())->FindObjectAny(name);
2312c2311
<          hist = new TH1X(name, title, bins, edges);
---
>          hist = new T(name, title, bins, edges);
2322,2325c2321,2324
<    template<typename TH2X>
<    TH2X EXPRT *h2_book(const char *name, const char *title,
< 	     	       int xbins, double xmin, double xmax,
<                        int ybins, double ymin, double ymax)
---
>    template<typename T>
>    T EXPRT *book(const char *name, const char *title,
> 	     	 int xbins, double xmin, double xmax,
>                  int ybins, double ymin, double ymax)
2327c2326
<       TH2X *hist;
---
>       T *hist;
2331c2330
<          hist = (TH2X *) gManaHistosFolder->FindObjectAny(name);
---
>          hist = (T *) gManaHistosFolder->FindObjectAny(name);
2333c2332
<          hist = (TH2X *) ((TFolder *)gHistoFolderStack->Last())->FindObjectAny(name);
---
>          hist = (T *) ((TFolder *)gHistoFolderStack->Last())->FindObjectAny(name);
2336c2335
<          hist = new TH2X(name, title, xbins, xmin, xmax, ybins, ymin, ymax);
---
>          hist = new T(name, title, xbins, xmin, xmax, ybins, ymin, ymax);
2346,2349c2345,2348
<    template<typename TH2X>
<    TH2X EXPRT *h2_book(const char *name, const char *title,
< 	  	       int xbins, double xmin, double xmax,
<                        int ybins, double yedges[])
---
>    template<typename T>
>    T EXPRT *book(const char *name, const char *title,
> 	         int xbins, double xmin, double xmax,
>                  int ybins, double yedges[])
2351c2350
<       TH2X *hist;
---
>       T *hist;
2355c2354
<          hist = (TH2X *) gManaHistosFolder->FindObjectAny(name);
---
>          hist = (T *) gManaHistosFolder->FindObjectAny(name);
2357c2356
<          hist = (TH2X *) ((TFolder *)gHistoFolderStack->Last())->FindObjectAny(name);
---
>          hist = (T *) ((TFolder *)gHistoFolderStack->Last())->FindObjectAny(name);
2360c2359
<          hist = new TH2X(name, title, xbins, xmin, xmax, ybins, yedges);
---
>          hist = new T(name, title, xbins, xmin, xmax, ybins, yedges);
2370,2373c2369,2372
<    template<typename TH2X>
<    TH2X EXPRT *h2_book(const char *name, const char *title,
< 		       int xbins, double xedges[],
<                        int ybins, double ymin, double ymax)
---
>    template<typename T>
>    T EXPRT *book(const char *name, const char *title,
> 		 int xbins, double xedges[],
>                  int ybins, double ymin, double ymax)
2375c2374
<       TH2X *hist;
---
>       T *hist;
2379c2378
<          hist = (TH2X *) gManaHistosFolder->FindObjectAny(name);
---
>          hist = (T *) gManaHistosFolder->FindObjectAny(name);
2381c2380
<          hist = (TH2X *) ((TFolder *)gHistoFolderStack->Last())->FindObjectAny(name);
---
>          hist = (T *) ((TFolder *)gHistoFolderStack->Last())->FindObjectAny(name);
2384c2383
<          hist = new TH2X(name, title, xbins, xedges, ybins, ymin, ymax);
---
>          hist = new T(name, title, xbins, xedges, ybins, ymin, ymax);
2394,2397c2393,2396
<    template<typename TH2X>
<    TH2X EXPRT *h2_book(const char *name, const char *title,
< 		       int xbins, double xedges[],
<                        int ybins, double yedges[])
---
>    template<typename T>
>    T EXPRT *book(const char *name, const char *title,
> 		 int xbins, double xedges[],
>                  int ybins, double yedges[])
2399c2398
<       TH2X *hist;
---
>       T *hist;
2403c2402
<          hist = (TH2X *) gManaHistosFolder->FindObjectAny(name);
---
>          hist = (T *) gManaHistosFolder->FindObjectAny(name);
2405c2404
<          hist = (TH2X *) ((TFolder *)gHistoFolderStack->Last())->FindObjectAny(name);
---
>          hist = (T *) ((TFolder *)gHistoFolderStack->Last())->FindObjectAny(name);
2408c2407
<          hist = new TH2X(name, title, xbins, xedges, ybins, yedges);
---
>          hist = new T(name, title, xbins, xedges, ybins, yedges);
2422,2423c2421,2422
<    #define H1_BOOK(n,t,b,min,max) (h1_book<TH1F>(n,t,b,min,max))
<    #define H2_BOOK(n,t,xb,xmin,xmax,yb,ymin,ymax) (h2_book<TH2F>(n,t,xb,xmin,xmax,yb,ymin,ymax))
---
>    #define H1_BOOK(n,t,b,min,max) (book<TH1F>(n,t,b,min,max))
>    #define H2_BOOK(n,t,xb,xmin,xmax,yb,ymin,ymax) (book<TH2F>(n,t,xb,xmin,xmax,yb,ymin,ymax))
2425c2424,2469
<    TCutG *cut_book( const char *name);
---
>    /*
>     * The following obsolete calls are here for backwards compatibility.
>     * They are inlined, so incur no performance hit.
>     */
>    template<typename TH1X>
>    inline TH1X EXPRT *h1_book(const char *name, const char *title,
> 		              int bins, double min, double max) {
>      return book<TH1X>( name, title, bins, min, max);
>    }
>    template<typename TH1X>
>    inline TH1X EXPRT *h1_book(const char *name, const char *title,
> 	         	      int bins, double edges[]) {
>      return book<TH1X>( name, title, bins, edges);
>    }
>    template<typename TH2X>
>    inline TH2X EXPRT *h2_book(const char *name, const char *title,
> 	       	              int xbins, double xmin, double xmax,
>                               int ybins, double ymin, double ymax) {
>      return book<TH2X>( name, title, xbins, xmin, xmax, ybins, ymin, ymax);
>    }
>    template<typename TH2X>
>    inline TH2X EXPRT *h2_book(const char *name, const char *title,
> 	  	              int xbins, double xmin, double xmax,
>                               int ybins, double yedges[]) {
>      return book<TH2X>( name, title, xbins, xmin, xmax, ybins, yedges);
>    }
>    template<typename TH2X>
>    inline TH2X EXPRT *h2_book(const char *name, const char *title,
> 		              int xbins, double xedges[],
>                               int ybins, double ymin, double ymax) {
>      return book<TH2X>( name, title, xbins, xedges, ybins, ymin, ymax);
>    }
>    template<typename TH2X>
>    inline TH2X EXPRT *h2_book(const char *name, const char *title,
> 		              int xbins, double xedges[],
>                               int ybins, double yedges[]) {
>      return book<TH2X>( name, title, xbins, xedges, ybins, yedges);
>    }
> 
>    template<typename T>
>    T EXPRT *book (const char *name); // generic object not implemented
>    /*
>     * but some simple objects are implemented via specializations
>     */
>    template<>
>    TCutG EXPRT *book<TCutG> (const char *name);
? src/.mana.c.swp
Index: src/mana.c
===================================================================
RCS file: /usr/local/cvsroot/midas/src/mana.c,v
retrieving revision 1.132
diff -r1.132 mana.c
3945c3945,3946
< TCutG *cut_book (const char *name) {
---
> template<>
> TCutG EXPRT *book<TCutG> (const char *name) {
  208   21 Apr 2005 Konstantin OlchanskiSuggestionCorrect MIDASSYS setting?
Current MIDAS versions nag me about setting the env.variable MIDASSYS to the
"midas installation directory", but I do not have one, so what should I set
MIDASSYS to? I checkout MIDAS from cvs into /home/olchansk/daq/midas, build it
there, run it from there. I never do "make install" (I am not "root" on every
machine; I am not the only MIDAS user on every machine). What should I set
MIDASSYS to? K.O.
  209   22 Apr 2005 Stefan RittSuggestionCorrect MIDASSYS setting?
> Current MIDAS versions nag me about setting the env.variable MIDASSYS to the
> "midas installation directory", but I do not have one, so what should I set
> MIDASSYS to? I checkout MIDAS from cvs into /home/olchansk/daq/midas, build it
> there, run it from there. I never do "make install" (I am not "root" on every
> machine; I am not the only MIDAS user on every machine). What should I set
> MIDASSYS to? K.O.

Then set it to /home/olchansk/daq/midas. The reason for MIDASSYS is the same as
for ROOTSYS. Having it allows other packages like ROME to access the Midas source
code, include files and libraries.
  221   01 Sep 2005 Stefan RittSuggestionnew mvmestd api
Anothe idea which comes to my mind, we could make it kind of object oriented, like

typedef struct {
  int handle;
  int crate;
  int amod;
  int fifo_mode;
  ...
} MVME_INTERFACE;

main()
{
  MVME_INERFACE *vme;

  vme = mvme_init(); // allocated and fills MVME_INTERFACE structure

  mvme_set_crate(vme, crate_no);
  mvme_set_address_mode(vme, A24);
  ...

  mvme_read(vme, vme_address, dest_addr, num_bytes);
  mvme_exit(vme);    // frees memory allocated in mvme_init()
}

------------------------------------------

This way we would only have one structure containing all required parameters, and get/set
functions for it, like the OO textbooks propose it. This would actually make it thread
save. The "vme" pointer from above still has to be passed around to subroutines, but a
single pointer is better than lots of handles.
  232   02 Nov 2005 Stefan RittSuggestionWhere to put drivers?
Hi,

I would like to raise the question where to put the midas drivers.

We have both the example experiment and the MSCB Makefile which both expect to find the midas drivers under $MIDASSYS/drivers/camac or $MIDASSYS/drivers/usb. The documentation does not explicitely mention to define MIDASSYS as /usr/local, but some people do it. That however requires to put all drivers then under /usr/local/drivers, which is not the case in the current Makefile for midas. Do you think that we should add this? Or should we better ask (->documentation) people to define MIDASSYS to wherever they install the midas package (usually /usr/home/<name>/midas or so)?

Looking forward to hear your opinion,

Stefan
  233   06 Nov 2005 Pierre-Andre AmaudruzSuggestionWhere to put drivers?

Stefan Ritt wrote:
Hi,

I would like to raise the question where to put the midas drivers.

We have both the example experiment and the MSCB Makefile which both expect to find the midas drivers under $MIDASSYS/drivers/camac or $MIDASSYS/drivers/usb. The documentation does not explicitely mention to define MIDASSYS as /usr/local, but some people do it. That however requires to put all drivers then under /usr/local/drivers, which is not the case in the current Makefile for midas. Do you think that we should add this? Or should we better ask (->documentation) people to define MIDASSYS to wherever they install the midas package (usually /usr/home/<name>/midas or so)?

Looking forward to hear your opinion,

Stefan



Pierre-André Amaudruz wrote:

The purpose of the MIDASSYS introduction was to permit the placement of the package in the user area as well as publishing the Midas entry point. Doing so, we lessen the necessity to "install" Midas in the standard OS directory such as /opt or /usr/local. Static linking, use of rpath, new "make minimal_install" go in that direction.
Regarding the drivers, organizing the directories per hardware type (camac, vme, fastbus, usb, etc) seems better to me. Originally, we mostly dealt with CAMAC and therefore the diverse Makefile had a default reference to /drivers/bus/(camacrpc). Now that we removed cnaf/rpc from the automatic mfe build, it indicates that CAMAC is no longer the prime hardware. Then we should leave open to the user the selection of the hardware and document the necessity for him/her to adjust the build appropriately ( $MIDASSYS/drivers/<HW_type> ). The different Makefile examples should be adjusted to the proper driver location they're dealing with.
Pierre-André
  234   06 Nov 2005 Stefan RittSuggestionWhere to put drivers?

Stefan Ritt wrote:
We have both the example experiment and the MSCB Makefile which both expect to find the midas drivers under $MIDASSYS/drivers/camac or $MIDASSYS/drivers/usb. The documentation does not explicitely mention to define MIDASSYS as /usr/local, but some people do it. That however requires to put all drivers then under /usr/local/drivers, which is not the case in the current Makefile for midas. Do you think that we should add this? Or should we better ask (->documentation) people to define MIDASSYS to wherever they install the midas package (usually /usr/home/<name>/midas or so)?



Pierre-André Amaudruz wrote:

The purpose of the MIDASSYS introduction was to permit the placement of the package in the user area as well as publishing the Midas entry point. Doing so, we lessen the necessity to "install" Midas in the standard OS directory such as /opt or /usr/local. Static linking, use of rpath, new "make minimal_install" go in that direction.
Regarding the drivers, organizing the directories per hardware type (camac, vme, fastbus, usb, etc) seems better to me. Originally, we mostly dealt with CAMAC and therefore the diverse Makefile had a default reference to /drivers/bus/(camacrpc). Now that we removed cnaf/rpc from the automatic mfe build, it indicates that CAMAC is no longer the prime hardware. Then we should leave open to the user the selection of the hardware and document the necessity for him/her to adjust the build appropriately ( $MIDASSYS/drivers/<HW_type> ). The different Makefile examples should be adjusted to the proper driver location they're dealing with.
Pierre-André


I agree with what you say. So I will include the drivers in the ("full") install to be copied under /usr/local/drivers, just for the people using midas in an "installed" way, but we keep the possibility to use a minimal_install to skip the driver installation.
  244   28 Dec 2005 Konstantin OlchanskiSuggestionHandling multiple identical USB devices
When I wrote the musbstd.h "open" method, I kind of punted on the problem of
handling multiple identical USB devices. Instead of a real solution, I added an
"instance" parameter, which allows one to "open" the "first", "second", etc USB
device, as listed in a magic random system dependant order.

Normally, USB devices are identified by two 16-bit integers: manufacturer ID and
product ID (i.e. as reported by "lsusb"). This works well until one has more
than one "identical" device. Two years ago, I had 5 identical USB cameras
(optical alignement system for TRIUMF-TWIST); last year, I had multiple USB
serial adapters; today I have two identical USB-TPC interfaces.

Most of the time, the devices are plugged into the same USB ports, so
theoretically, one should be able to tell exactly which one is which ("upstream
camera is plugged into port 1, downstream camera is plugged into port 2"). But
in the magic system dependant enumeration order, they keep moving around,
depending on the order of enumeration, history of powering up and down, phase of
the Moon, etc.

So my generic "musbstd" method of "open first", "open second", etc turned out to
be completely disfunctional.

So far, I am unable to come up with a system independant solution. But I have a
solution for Linux and maybe for MacOSX:

1) on Linux, I can use the information parsed from /proc/bus/usb/devices to say
"please open the USB device on USB bus 1, port 1", the so called USB device
"path", as seen in the system log and in /sys/bus/usb/devices.

2) on MacOSX, I was unable to find a way to discover the USB topology, but they
seem to maintain an uint32_t "location", which they promise to keep at least
across reboots (did not check this yet).

3) Windows I did not look at yet.

So we have a choice:

a) use system dependant "musb_open_linux(usbpath,vendor,product)",
"musb_open_macosx(???,vendor,product)", etc

b) create order out of chaos by manually keeping a map of "instances" (first,
second, third device) to "persistant addresses". On Linux, it would be a file
containing something like this: "USB-TPC-0 is on bus1-port1, USB-TPC-1 is on
bus1-port2". Then again, I can say "please open USB-TPC interface instance 0" or
"instance 1", etc. There is a small difficulty with dealing with devices
temporarily or permanantly going away, or changing physical addresses ("I moved
the USB device from port 1 to port 3"). This could be handled by telling the
user "hmm... USB topology has changed, please delete the map file and try
again", or we could come up with something more user friendly.

Any thoughts?

P.S. For my immediate need (I need this tomorrow), I will write a
musb_open_linux(usbpath,vendor,product) function.

K.O.
  247   03 Jan 2006 Stefan RittSuggestionHandling multiple identical USB devices
> Any thoughts?

I got an idea of how to solve this problem in an OS-independent manner. The USB
devices and hubs form a tree, like this

  Root  HUB
  0   1   2
  |   |   \__...
  |   \___
 DevY     \
         HUB
        0 1 2
        |   |
        |  DevX
       HUB
      0 1 2
          |
        DevZ

This tree can be considered as an ordered tree, if you read it from left to right.
In that order, the devices are orderd

DevY - DevZ - DevX

Since the devices are ordered, the "instance" parameter from musb_init can be used
to identify them uniquely, like

instance==0   => DevY
instance==1   => DevZ
instance==2   => DevX

So I would say that we can use the current API using the "instance" parameter to
uniquely access a device. All we have to do is to build that tree, sort it, and then
use the instance parameter as an entry to that tree. The sorting takes care of
different ordering, which can happen during enumeration (depeding on power-up
sequence, phase of the Moon etc.). So if you have three devices like above, DevZ
should alway be at "instance==1". The only problem is if you unplug DevY for
example, then you get the map

instance==0   => DevZ
instance==1   => DevX

which is different from above. But if you have a different number of devices, you
likely have to change your frontend cody anyhow, so you can change the device
mapping there as well. 

In order to simplify the code, I would not build a complete tree and sort it, but
scan the whole tree hierarchically, i.e. look at

Bus1/Port1
Bus1/Port2
Bus1/...
Bus2/Port1
Bus2/Port2
...

Since there is a maximum of toal 127 USB devices, this scan should be pretty quick.
If you find a device with matching vendor and product ID, you increment an internal
counter. If that counter matches your instance parameter, you open that device.

The ultimate solution of course is to put an additional address into each device, so
you can distinguish them easily. For a out-of-the box Web cam you probably have no
chance, but for the home-made MSCB nodes I put such an address into each node, so I
can distinguish them even if the have the same product and vendor ID.
  302   20 Sep 2006 Stefan RittSuggestionIncrease of maximum event size
Dear midas users,

The current event size in midas is limited to 512k (MAX_EVENT_SIZE in midas.h). This is mainly due to old (pre 2.2) linux kernels which had only a very limited shared memory pool. These days this limit has increased considerably and I question if we should increase the default event size and to which size we should increase it.

The drawback of a larger event size is that the SYSTEM event buffer has to hold at least two events, and when the last midas program is stopped or started, this buffer has to be written to or read from the .SYSTEM.SHM file, which slows down the start/stop of the program. But writing/reading a few MB is fast these days anyhow so this again might now be a big problem. So what do you think how big we should make the default max event size?

- Stefan
  303   20 Sep 2006 Stefan RittSuggestionIncrease of maximum event size
Since nobody complained so far, I increased MAX_EVENT_SIZE to 2MB. If anybody has problems with this setting, please report. Note that after updating to SVN revision 3327 it will be necessary to recompile all midas programs and to delete any old SYSTEM.SHM or .SYSTEM.SHM. I added some code which should check for inconsistent SYSTEM.SHM sizes, but I'm not sure if it works everywhere.
  308   27 Sep 2006 Konstantin OlchanskiSuggestionIncrease of maximum event size
> The current event size in midas is limited to 512k (MAX_EVENT_SIZE in midas.h)

Yes, 512 kBytes is rather small. For the T2K prototype TPC DAQ, I built and ran
MIDAS with 4 MByte events, and it worked fine.

Now, we have per-buffer tunable size (see message
https://ladd00.triumf.ca/elog/Midas/283) and in the long run, I would prefer the
compiled-in limit to go away: already all memory is allocated dynamically and
the MAX_EVENT_SIZE is only useful as kind of a sanity check against frontend
misconfiguration or against malformed events.

If MAX_EVENT_SIZE goes away, the maximum event size becomes limited by the
largest SysV shared memory segment permitted by Linux (via sysctl kernel.shmmax).

To go beyound the limit on SysV shared memories, on can use mmap() based shared
memory: this is limited by available RAM+swap (and disk space for the
.SYSTEM.SHM file). Current MIDAS system.c has an experimental implementation of
mmap() shared memory, but AFAIK it has not been used in any production system, yet.

K.O.
  309   28 Sep 2006 Stefan RittSuggestionIncrease of maximum event size

K.O. wrote:
Now, we have per-buffer tunable size (see message
https://ladd00.triumf.ca/elog/Midas/283) and in the long run, I would prefer the
compiled-in limit to go away: already all memory is allocated dynamically and
the MAX_EVENT_SIZE is only useful as kind of a sanity check against frontend
misconfiguration or against malformed events.

If MAX_EVENT_SIZE goes away, the maximum event size becomes limited by the
largest SysV shared memory segment permitted by Linux (via sysctl kernel.shmmax).

To go beyound the limit on SysV shared memories, on can use mmap() based shared
memory: this is limited by available RAM+swap (and disk space for the
.SYSTEM.SHM file). Current MIDAS system.c has an experimental implementation of
mmap() shared memory, but AFAIK it has not been used in any production system, yet.


MAX_EVENT_SIZE is also used for the RPC layer, since the receiving buffer must hold at
least one event. It is right that this can and should be made dynamically. Concerning
the shared memory there is the problem that it cannot be increased when any program is
running and attached to the shared memory, so it can only be defined at startup of the
first program creating the shared memory.

The sanity check in the frontend is done against max_event_size defined in frontend.c which can be smaller than MAX_EVENT_SIZE (some front-ends have limited memory).

So I agree that this issue may need revision, maybe something for me next visit Wink
  317   05 Jan 2007 Eric-Olivier LE BIGOTSuggestionAccess to out_info from mana.c
Would it be relevant to transform out_info into a *non-static* variable of a type
defined by a *named* struct?
Currently,  programs that  try to access out_info cannot do it anymore; and they
typically copy the struct definition from mana.c, which is not robust against future
changes in mana.c.

If mana.c could be changed in the way described above, that would be great . 
Otherwise, is it safe to patch it myself for local use?  or is there a better way of
accessing out_info from mana.c?

As always, any help would be much appreciated :)

EOL

> Hello,
> 
> Is it possible to access out_info (defined in mana.c) from another program?
> 
> In fact, out_info is now defined as an (anonymous) "static struct" in mana.c,
> which it seems to me precludes any direct use in another program.  Is there an
> indirect way of getting ahold of out_info?  or of the information it contains?
> 
> out_info used to be defined as a *non-static* struct, and the code I'm currently
> modifying used to compile seamlessly: it now stops the compilation during
> linking time, as out_info is now static and the program I have to compile
> contains an "extern struct {} out_info".
> 
> Any help would be much appreciated!  I searched in vain in this forum for
> details about out_info and I really need to access the information it contains!
> 
> EOL (a pure MIDAS novice)
ELOG V3.1.4-2e1708b5