 04 Nov 2004, Jan Wouters, Forum, Frontend code and the ODB
|
I would like to know whether all parameters used by the frontend code have to be in the "Experiment/
Run Parameters" section. This section can become big and difficult to maintain, because it is one single
big section of experim.h (EXP_PARAM_DEFINED). I have parameters the various frontends read at the
|
 04 Nov 2004, Stefan Ritt, Forum, Frontend code and the ODB
|
Hi Jan,
I usually keep under /Experiment/Run Parameters only those settings which are kind of "global" and thus of
|
|
24 Jun 2009, Razvan Stefan Gornea, Forum, Frontend and manual trigger question
|
Hi,
I have a question related to the frontend and I would need some suggestions
|
|
25 Jun 2009, Stefan Ritt, Forum, Frontend and manual trigger question
|
> I would like to add manual trigger capability and so I added the EQ_MANUAL_TRIG
> flag to the "CAEN" equipment type but the problem is that the framework calls
> directly the readout function on "Midas manual trigger". To trigger manually the
|
|
19 Feb 2008, Petr Nomokonov, Info, Frontend - Backend c onnection
|
Backend computer with SLC4.4 Linux did'not work as mserver because some security
protection under iptables service (could not connect with frontend computers).
The connection established if to make ( under root ) iptables disable
|
|
26 Jan 2007, Carl Metelko, Forum, Front end electronics broadcast data over ethernet, can midas read this in
|
Hi,
the system I'm building will have data read into the frontend nodes
via ethernet (optic). Is this possible?> |
|
26 Feb 2007, Stefan Ritt, Info, Fragmented polled events
|
Fragmented polled events have been implemented in SVN revision 3625.
Fragmentation is a method of breaking down large (>MB) events into smaller
pieces and send them through the shared memory buffers, reassembling them at the
|
|
05 Sep 2006, Konstantin Olchanski, Forum, Forums moved from dasdevpc.triumf.ca to ladd00.triumf.ca
|
For the record, the MIDAS (& co) forums have been physically moved from
dasdevpc.triumf.ca to our new server machine ladd00.triumf.ca. This change
should be transparent to all users, but if anything stops working, please let me
|
|
29 Jan 2020, Pintaudi Giorgio, Info, Force triggering of idle routine of a frontend
|
Hello!
As you know, the generic MIDAS frontend has a class driver, device driver, bus driver
structure. Assuming a slow device frontend, its class driver should have a routine of type
|
|
02 Feb 2020, Konstantin Olchanski, Info, Force triggering of idle routine of a frontend
|
Hi, Giorgio - I think you encountered a fundamental problem with what to do at the begin of
run. There are two ways of thinking about it.
|
|
02 Feb 2020, Pintaudi Giorgio, Info, Force triggering of idle routine of a frontend
|
Dear Konstantin,
thank you very much for the explanation. I already have an idea of how to solve my problem by bypassing the class driver altogether or by slightly modifying
the mfe.cxx frontend.
|
|
03 Feb 2020, Stefan Ritt, Info, Force triggering of idle routine of a frontend
|
It is important to note that slow control readout and sending of midas events are two separate things. Readout is done as fast as possible, even multi-threaded
if selected. On fast devices this can be 100 Hz readout rate and even more. This data is stored in an internal buffer. When one of the values changes by
more than the update threshold, then the ODB gets updated. The midas events are composed from this internal buffer when a new event has to be sent. This |
|
04 Feb 2020, Pintaudi Giorgio, Info, Force triggering of idle routine of a frontend
|
Dear Stefan,
thank you very much for the clarification. I knew about the DF_XXX flags and I am making good use of them in all my frontends. Anyway, what I really needed
was to change the readout rate depending on the run status (in particular DF_RUNNING or DF_TRANSITION).
|
|
07 Feb 2020, Stefan Ritt, Info, Force triggering of idle routine of a frontend
|
Dear Giorgio,
ok, now I'm slowly getting your point.
|
|
07 Feb 2020, Pintaudi Giorgio, Info, Force triggering of idle routine of a frontend
|
Dear Stefan,
Thank you for the advice. I will try to modify the driver as you say. As for the dynamical change of readout rate, basically you are telling me that is
not achievable without dirty hacks like mine and it is better to find a way to avoid it.
|
|
09 Feb 2020, Stefan Ritt, Info, Force triggering of idle routine of a frontend
|
You dirty hacks will probably work, but what you REALLY want is to read out your HV always as fast as possible, not only during run transitions or ramping.
We had a case where a detector produced electrostatic discharges which only lasted for a second or so, and we were happy to detect this in spikes in the
HV current. With measurements of only one per minute we would not have realized that so quicky.
|
|
10 Feb 2020, Konstantin Olchanski, Info, Force triggering of idle routine of a frontend
|
> We had a case where a detector produced electrostatic discharges which only lasted for a second or so
> and we were happy to detect this in spikes in the HV current. With measurements of only one per minute
> we would not have realized that so quicky.
|
|
12 Feb 2020, Stefan Ritt, Info, Force triggering of idle routine of a frontend
|
I had a look again at the issue. If you sett the event limit to zero in the EQUIPMENT list, then the idle() routine of your class driver is called as often
as possible. Typically with 100 Hz. It's then up to you what to do in the class driver. The hv_idle() routine of the HV class driver shipped in the distribution
for example read a channel more often if it has been changed recently. Look at the lines
|
|
10 May 2013, Konstantin Olchanski, Bug Fix, Fixed: crash if alarm "write elog message" is enabled
|
If the MIDAS Alarm property "write elog message" is enabled, an uninitialized variable "tag" is passed to
el_submit() and depending on your luck, cause a crash. "tag" is supposed to be and is now a NUL-
terminated string. The only other use of el_submit() is in mhttpd.cxx and mserver.c, where it is called
|
|
15 Jan 2014, Konstantin Olchanski, Bug Fix, Fixed spurious symlinks to midas.log
|
In some experiments (i.e. DEAP), we see spurious symlinks to midas.log scattered just about everywhere. I
now traced this to an uninitialized variable in cm_msg_log() and it should be fixed now. K.O. |