ID |
Date |
Author |
Topic |
Subject |
2804
|
15 Aug 2024 |
Scott Oser | Forum | "Safe" abort of sequencer scripts |
We often use the MIDAS sequencer to temporarily control detector settings, such as:
* <change some setting>
* WAIT 60 seconds
* <revert setting to original value>
The question arises of what happens if the sequencer scripts gets aborted during that wait, preventing the value from being reset. Depending on the setting, this could be undesirable or even damage something if left uncorrected for too long.
Is there any way to have a "safe abort" from the sequencer so that the "Stop immediately" button will call some cleanup script to leave things in a safe state? Or what about if the sequencer process itself gets killed in the middle of a script?
How have other experiments using MIDAS protected themselves from unplanned terminations of sequencer scripts? |
2803
|
08 Aug 2024 |
Stefan Ritt | Info | mana.cxx |
We are considering to remove the analyzer framework mana.cxx from MIDAS. It
currently has some compiler warnings and we wonder if we should fix them which
would take some time or just remove the file. We have now to much more modern
analyzer frameworks "manalyzer" and "ROOTANA" which should be used instead.
Is anybody still using the mana.cxx framework?
/Stefan |
2801
|
07 Aug 2024 |
Stefan Ritt | Bug Report | File name bug in csv export |
Fixed as well. |
2800
|
07 Aug 2024 |
Lukas Gerritzen | Bug Report | File name bug in csv export |
Thanks. I think, mplot.js:1844 should be changed as well, but I haven't tried it with mplot. |
2799
|
07 Aug 2024 |
Stefan Ritt | Bug Report | File name bug in csv export |
Thanks. Fixed. Committed. Pulled on megon02.
Stefan |
2798
|
07 Aug 2024 |
Lukas Gerritzen | Bug Report | File name bug in csv export |
When I export data from a history plot, I get nonsensical filenames. For example, for data from today, I got "Xenon-Vacuum-20247107-152815-20247107-160032.csv".
The month shouldn't be 71 but rather 08. The problem is that in the code it's generated as("0" + leftDate.getUTCMonth() + 1).slice(-2) The first '+' is a string concatenation, and so is the second. It should be an addition though. A possible fix is to add parentheses around the addition:("0" + (leftDate.getUTCMonth() + 1)).slice(-2) |
2797
|
06 Aug 2024 |
Stefan Ritt | Suggestion | cmake-installing more files ? |
I don't see any bad side effects at the moment, so I accepted the changes and committed them.
Stefan |
2796
|
06 Aug 2024 |
Stefan Ritt | Forum | mfe.cxx with RO_STOPPED and EQ_POLLED |
> I noticed that a check was added to mfe.cxx in 1961af0d6:
>
> + /* check for consistent common settings */
> + if ((eq_info->read_on & RO_STOPPED) &&
> + (eq_info->eq_type == EQ_POLLED ||
> + eq_info->eq_type == EQ_INTERRUPT ||
> + eq_info->eq_type == EQ_MULTITHREAD ||
> + eq_info->eq_type == EQ_USER)) {
> + cm_msg(MERROR, "register_equipment", "Events \"%s\" cannot be read when run is stopped (RO_STOPPED flag)", equipment[idx].name);
> + return 0;
> + }
>
>
> Can someone explain the purpose of this check and error message? Perhaps it
> was put in place with only DAQ FEs, not SC FEs in mind? And should the
> documentation in the wiki actually be "s/Before stopping run/While run is stopped/"?
Indeed you have two types of events handled by mfe.cxx: Slow control events (EQ_SLOW or EQ_PRIODIC) and triggered events (EQ_POLLED or
EQ_INTERRUPT or EQ_MULTITHREAD or EQ_USER). For slow control events it can make sense to read them also when the run is stopped, that's why you
can specify RO_STOPPED or RO_ALWAYS. This does however not make sense for triggered events. Reading triggered events when the run is stopped
invalidates the concept of runs (= read triggered events only during a run). We had cases where people mixed this up, so the warning was added.
If you have a slow control event you want to read when the run is stopped, make sure it is of type EQ_SLOW or EQ_PERIODIC.
Stefan |
2795
|
31 Jul 2024 |
Stefan Ritt | Bug Report | New history plots: Zooming in on logarithmic y axis does not work as expected |
I fixed that and committed the change to megon02, just reload your browser. I also set ymin and ymax of the Vacuum plot to meaningful
values (not to zero!).
Stefan |
2794
|
31 Jul 2024 |
Lukas Gerritzen | Bug Report | New history plots: Zooming in on logarithmic y axis does not work as expected |
Using the mouse to click and drag on a logarithmic y axis triggers a zooming behaviour as if the user zoomed in on a linear axis.
How to reproduce:
Take a plot that ranges from 1e-20 to 100, for example. Click around the middle of the axis and drag the mouse up to about 3/4.
Expected result:
Limit the y axis to the approximate range 1e-10 to 1e-4
Actual result:
The y axis limits are around 50 and 75.
P.S. Is there a way to configure the history plot in a way that values of 0.00 are ignored rather than showing up as 1e-20? |
2793
|
26 Jul 2024 |
Stefan Ritt | Bug Fix | strlcpy and strlcat added to glibc 2.38 |
Good catch. I added your code to the current develop branch of MIDAS.
Stefan |
2792
|
26 Jul 2024 |
Lukas Gerritzen | Bug Fix | strlcpy and strlcat added to glibc 2.38 |
A year ago, these two function were included in glibc. If trying to compile midas with a recent version of
Ubuntu or Fedora, one gets errors like this:
/usr/include/string.h:506:15: error: declaration of ‘size_t strlcpy(char*, const char*, size_t) noexcept’ has a
different exception specifier
506 | extern size_t strlcpy (char *__restrict __dest,
| ^~~~~~~
In file included from /home/luk/midas/src/midas.cxx:14:
/home/luk/midas/include/midas.h:2190:17: note: from previous declaration ‘size_t strlcpy(char*, const
char*, size_t)’
My proposed solution is a check in midas.h around line 248:
#if (__GLIBC__ > 2) || (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 38)
#ifndef HAVE_STRLCPY
#define HAVE_STRLCPY 1
#endif
#endif
|
2791
|
05 Jul 2024 |
Joseph McKenna | Suggestion | Clean up compiler warning in manalyzer |
This is a super small pull request, simple replace deprecated sprintf with snprintf
https://bitbucket.org/tmidas/manalyzer/pull-requests/9 |
2790
|
05 Jul 2024 |
Joseph McKenna | Suggestion | shared pointers for more flexible memory managment of the analysis 'flow' and TMEvent |
> Hi all, I hope this is the right place to post two pull requests, if not, please let me know where I should be submitting them
>
> Both are fairly small changes, please see them listed below (more details written on the PRs themselves)
>
>
> - Enable ROOT's thread safety when running in multithreaded mode
>
> This helps avoid users having to write their call to a global thread lock when calling ->Fill() on ROOT histograms and Trees
> https://bitbucket.org/tmidas/manalyzer/pull-requests/5
>
>
> - Add command argument to specify an IP of the root HTTP server to bind to
>
> This was a problem I painted around when at ALPHA (quickly hardcoding the right external IP address into the local build. Obviously a bad habit)
> https://bitbucket.org/tmidas/manalyzer/pull-requests/6
Further to the pull manalyzer pull requests, I have another feature I would like to add. Took a little longer to test than planned... here I present an effort to use smart pointers to manage the lifetime of TMEvents and TAFlow.
I will be interested to discuss the implications of this pull request (its possible to return to previous 'raw' pointers via a cmake toggle)
https://bitbucket.org/tmidas/manalyzer/pull-requests/8 |
2789
|
05 Jul 2024 |
Tam Kai Chung | Bug Report | Fail to build in the examples/experiment |
Hello Nick,
I am using the most updated tag: midas-2022-05-c-1284-g4a77127b.
Here would be some of the examples of the error listed:
/usr/bin/ld: /packages/midas/lib/mfe.o: in function
/usr/bin/ld: /packages/midas/src/mfe.cxx:2537: undefined reference to `event_buffer_size'
...
Also several undefined reference. Any idea about it? Thank you.
Best,
Terry
> I think this may only be an issue on the development branch.
> Can you confirm that that is what you are using?
>
> If so, I suggest you try the most recent stable tag 2022-05-c.
>
> > Dear experts,
> > I am a new user of MIDAS. I try to follow the instruction from
> > https://daq00.triumf.ca/MidasWiki/index.php/Quickstart_Linux
> > to install MIDAS in Fedora 39.
> >
> > When I try to have a try in the section of "Clients run on Localhost only"
> > https://daq00.triumf.ca/MidasWiki/index.php/Quickstart_Linux#Clients_run_on_Localhost_only
> >
> > I get the error of "undefined reference to" several variables in the mfe.cxx. For example the variable "max_event_size_frag". May I know any idea about this issue? Thank you.
> >
> >
> > Best,
> > Terry |
Draft
|
04 Jul 2024 |
Nick Hastings | Forum | mfe.cxx with RO_STOPPED and EQ_POLLED |
I just discovered https://bitbucket.org/tmidas/midas/issues/338/mfec-ro_stopped-is-now-forbidden
> Dear Midas experts,
>
> I noticed that a check was added to mfe.cxx in 1961af0d6:
>
> + /* check for consistent common settings */
> + if ((eq_info->read_on & RO_STOPPED) &&
> + (eq_info->eq_type == EQ_POLLED ||
> + eq_info->eq_type == EQ_INTERRUPT ||
> + eq_info->eq_type == EQ_MULTITHREAD ||
> + eq_info->eq_type == EQ_USER)) {
> + cm_msg(MERROR, "register_equipment", "Events \"%s\" cannot be read when run is stopped (RO_STOPPED flag)", equipment[idx].name);
> + return 0;
> + }
>
> This commit was by Stefan in May 2022.
>
> A commit few days later, 28d9c96bd, removed the "return 0;", and updated the
> error message to:
>
> "Equipment \"%s\" contains RO_STOPPED or RO_ALWAYS. This can lead to undesired side-effect and should be removed."
>
> So such FEs can run but there is still an error at start up. The
> documentation at https://daq00.triumf.ca/MidasWiki/index.php/ReadOn_Flags
> states with RO_STOPPED "Readout Occurs" "Before stopping run".
> Which seems to indicate that the removing the RO_STOPPED bit from a SC FE
> would just result in an additional read not happening just prior to a run
> stop. However reading scheduler() in mfe.cxx I see in the the main loop:
>
> if (run_state == STATE_STOPPED && (eq_info->read_on & RO_STOPPED) == 0)
> continue;
>
> So it seems to me that the a EQ_PERIODIC equipment needs RO_STOPPED to be set
> otherwise it will not read out data while there is no DAQ run.
>
> Can someone explain the purpose of this check and error message? Perhaps it
> was put in place with only DAQ FEs, not SC FEs in mind? And should the
> documentation in the wiki actually be "s/Before stopping run/While run is stopped/"?
>
> Thanks,
>
> Nick. |
2787
|
04 Jul 2024 |
Pavel Murat | Suggestion | cmake-installing more files ? |
Dear all,
this posting results from the Fermilab move to a new packaging/build system called spack
which doesn't allow to use the MIDAS install procedure described at
https://daq00.triumf.ca/MidasWiki/index.php/Quickstart_Linux#MIDAS_Package_Installation
as is. Spack specifics aside, building MIDAS under spack took
a) adding cmake install for three directories: drivers, resources, and python/midas,
b) adding one more include file - include/tinyexpr.h - to the list of includes installed by cmake.
With those changes I was able to point MIDASSYS to the spack install area and successfully run mhttpd,
build experiment-specific C++ frontends and drivers, use experiment-specific python frontends etc.
I'm not using anything from MIDAS submodules though.
I'm wondering what the experts would think about accepting the changes above to the main tree.
Installation procedures and changed to cmake files are always a sensitive area with a lot of boundary
constraints coming from the existing use patterns, and even a minor change could have unexpected consequences
So I wouldn't be surprised if the fairly minor changes outlined above had side effects.
The patch file is attached for consideration.
-- regards, Pasha |
Attachment 1: midas-spack.patch
|
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 3c6a4109..57dab96f 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -642,6 +642,7 @@ else()
include/musbstd.h
include/mvmestd.h
include/odbxx.h
+ include/tinyexpr.h
include/tmfe.h
include/tmfe_rev0.h
mxml/mxml.h
@@ -657,6 +658,9 @@ install(TARGETS midas midas-shared midas-c-compat mfe mana rmana
install(EXPORT ${PROJECT_NAME}-targets DESTINATION lib)
+install(DIRECTORY drivers DESTINATION . )
+install(DIRECTORY resources DESTINATION . )
+install(DIRECTORY python/midas DESTINATION python)
#####################################################################
# generate git revision file
#####################################################################
|
2786
|
04 Jul 2024 |
Nick Hastings | Bug Report | Fail to build in the examples/experiment |
I think this may only be an issue on the development branch.
Can you confirm that that is what you are using?
If so, I suggest you try the most recent stable tag 2022-05-c.
> Dear experts,
> I am a new user of MIDAS. I try to follow the instruction from
> https://daq00.triumf.ca/MidasWiki/index.php/Quickstart_Linux
> to install MIDAS in Fedora 39.
>
> When I try to have a try in the section of "Clients run on Localhost only"
> https://daq00.triumf.ca/MidasWiki/index.php/Quickstart_Linux#Clients_run_on_Localhost_only
>
> I get the error of "undefined reference to" several variables in the mfe.cxx. For example the variable "max_event_size_frag". May I know any idea about this issue? Thank you.
>
>
> Best,
> Terry |
2785
|
04 Jul 2024 |
Nick Hastings | Forum | mfe.cxx with RO_STOPPED and EQ_POLLED |
Dear Midas experts,
I noticed that a check was added to mfe.cxx in 1961af0d6:
+ /* check for consistent common settings */
+ if ((eq_info->read_on & RO_STOPPED) &&
+ (eq_info->eq_type == EQ_POLLED ||
+ eq_info->eq_type == EQ_INTERRUPT ||
+ eq_info->eq_type == EQ_MULTITHREAD ||
+ eq_info->eq_type == EQ_USER)) {
+ cm_msg(MERROR, "register_equipment", "Events \"%s\" cannot be read when run is stopped (RO_STOPPED flag)", equipment[idx].name);
+ return 0;
+ }
This commit was by Stefan in May 2022.
A commit few days later, 28d9c96bd, removed the "return 0;", and updated the
error message to:
"Equipment \"%s\" contains RO_STOPPED or RO_ALWAYS. This can lead to undesired side-effect and should be removed."
So such FEs can run but there is still an error at start up. The
documentation at https://daq00.triumf.ca/MidasWiki/index.php/ReadOn_Flags
states with RO_STOPPED "Readout Occurs" "Before stopping run".
Which seems to indicate that the removing the RO_STOPPED bit from a SC FE
would just result in an additional read not happening just prior to a run
stop. However reading scheduler() in mfe.cxx I see in the the main loop:
if (run_state == STATE_STOPPED && (eq_info->read_on & RO_STOPPED) == 0)
continue;
So it seems to me that the a EQ_PERIODIC equipment needs RO_STOPPED to be set
otherwise it will not read out data while there is no DAQ run.
Can someone explain the purpose of this check and error message? Perhaps it
was put in place with only DAQ FEs, not SC FEs in mind? And should the
documentation in the wiki actually be "s/Before stopping run/While run is stopped/"?
Thanks,
Nick. |
2784
|
03 Jul 2024 |
Tam Kai Chung | Bug Report | Fail to build in the examples/experiment |
Dear experts,
I am a new user of MIDAS. I try to follow the instruction from
https://daq00.triumf.ca/MidasWiki/index.php/Quickstart_Linux
to install MIDAS in Fedora 39.
When I try to have a try in the section of "Clients run on Localhost only"
https://daq00.triumf.ca/MidasWiki/index.php/Quickstart_Linux#Clients_run_on_Localhost_only
I get the error of "undefined reference to" several variables in the mfe.cxx. For example the variable "max_event_size_frag". May I know any idea about this issue? Thank you.
Best,
Terry |