Back Midas Rome Roody Rootana
  Midas DAQ System, Page 121 of 136  Not logged in ELOG logo
ID Date Author Topicup Subject
  1854   16 Mar 2020 Konstantin OlchanskiReleasemidas-2020-03-a
midas-2020-03-a is here.

Accumulated changes and bug fixes since last tag midas-2019-09-i.

After this release, expect some instability on the develop branch as I commit the update of mhttpd to mongoose web server library 
version 6.16. More on that later.

To obtain this release, either checkout the top of branch release/midas-2020-03 (recommended)
or checkout the tag midas-2020-03-a.

K.O.
  1917   22 May 2020 Konstantin OlchanskiReleasemidas-2020-03-a
> midas-2020-03-a is here.
> checkout the top of branch release/midas-2020-03 (recommended) or
> checkout the tag midas-2020-03-a.

Since the release of midas-2020-03, we are in a cycle of rapid development of midas,
with many changes made daily.

For production use, unless you rely on latest changes and/or bug fixes, please use the midas-2020-03 release branch.

Some of the recent changes broke compatibility with ROOTANA.

The current ROOTANA release 2020-03 is meant to work with and is compatible with midas-2020-03. Going forward
we will try to keep releases of midas and rootana in "lock step".

K.O.
  Draft   24 Aug 2020 Konstantin OlchanskiReleasemidas-2020-12
midas-2020-12-a is here.

new features and notable updates since midas-2020-03:

- new C++ ODB interface odbxx.h
- image history
- much improved history plots
- new sequencer pages
- UTF-8 clean ODB (complains if any TID_STRING is invalid UTF-8)
- mhttpd update to mongoose 6.16 with much improved mulththreading
- mhttpd update to use MBEDTLS in preference to problematic OpenSSL
- MidasConfig.cmake contributed by Mathieu Guigue

plans for next development: major update of mlogger to simplify channel 
configuration in odb, improvements to mhttpd multithreading, new history plot 
configuration page, more c++ification.

To obtain this release, either checkout the top of branch release/midas-2020-08 
(recommended) or checkout the tag midas-2020-08-a.

K.O.
  2089   10 Feb 2021 Konstantin OlchanskiReleasemidas-2020-12-a
midas-2020-12-a is here, see https://midas.triumf.ca/MidasWiki/index.php/Changelog#2020-12

notable change from previous midas releases:

Use of ODB "Common" by mfe.c frontends has changed. New preferred behaviour
is to have the values defined in the equipment structure in the source code
to always overwrite values in ODB /Equipment/Foo/Common, except for the value
of "Common/enabled" (equipment_common_overwrite set to TRUE).

All mfe.c frontends will need to be modified for this change:

- for old behaviour (use ODB "Common"), add: BOOL equipment_common_overwrite = false;
- for new behaviour (use equipment values in the source code), add: BOOL equipment_common_overwrite = true;

The TMFE C++ frontend does not implement this change yet, it uses all "Common" values from ODB
and there is no way to overwrite things like the MIDAS event buffer name from C++ code. This may
change with the next version.

notable updates since midas-2020-08:

- new ODB variable /Experiment/Enable sound can be used to globally prevent mhttpd from playing sounds.
- Lazylogger now supports writing data over SFTP.
- odbvalue elements on custom pages now support an onload() callback as well as onchange(). Most elements now also 
support a data-validate callback.
- custom pages can now tie a select drop-down box to an ODB value using modbselect.
- ability to choose whether the code or the current ODB values take precendence for the "Common" settings of an 
equipment when starting a frontend. See elog thread 2014 for more details, and the "Upgrade guide" below for 
instructions.
- minor improvements to mdump program - support for 64-bit data types and ability to load larger events if needed.
- minor improvements to History plots and Buffers webpage.
- bug fixes

plans for next development: major update of mlogger to simplify channel 
configuration in odb, improvements to mhttpd multithreading, new history plot 
configuration page, more c++ification.

To obtain this release, either checkout the top of branch release/midas-2020-12 
(recommended) or checkout the tag midas-2020-12-a.

K.O.
  2416   18 Jul 2022 Konstantin OlchanskiReleasemidas-2022-05
There is a release branch for midas-2022-05 and corresponding git tag midas-2022-
05-b. This branch is known to be stable and is working well for the ALPHA 
experiment at CERN. Latest update to this branch fixes two problems in the 
mserver (rpc timeout and a use-after-free internal error).

https://bitbucket.org/tmidas/midas/branch/release/midas-2022-05
K.O.
  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.
ELOG V3.1.4-2e1708b5