|
Back
Midas
Rome
Roody
Rootana
|
Midas DAQ System, Page 125 of 142 |
Not logged in |
|
|
ID |
Date |
Author |
Topic |
Subject |
2769
|
17 May 2024 |
Konstantin Olchanski | Bug Report | midas alarm borked condition evaluation | > This is a common problem I also encountered in the past. You get a low-level ODB access error (could also be a read of a non-existing key) and you
> have no idea where this comes from. Could be the alarm system, a mhttpd web page, even some user code in a front-end over which the midas library
> has no control.
committed a partial fix, added an error message in alarm condition evaluation code to report alarm name and odb paths when we cannot get something from
ODB. Now at least midas.log gives some clue that ODB errors are coming from alarms.
and the errors are actually coming from the alarms web page.
the alarms web page shows all the alarms even if alarms are disabled and it shows evaluated alarm conditions and current values even for alarms that
are disabled.
I could change it to show "disabled" for disabled alarms, but I think it would not be an improvement,
right now it is quite convenient to see the alarm values for disabled/inactive alarms,
it is easy to see if they will immediately trip if I enable them. Hiding the values would make
them blind.
And I think I know what caused the original problem in IRIS experiment, I think the list of EPICS variables got truncated from 30 to 20 and EPICS
values 29 and 30 used in the alarm conditions have become lost.
So the next step is to fix feepics to not truncate the list of variables (right now it is hardwired to 20 variables) and restore
the lost variable definition from a saved odb dump.
K.O.
>
> One option would be to add a complete stack dump to each of these error (ROOT does something like that), but I hear already people shouting "my
> midas.log is flooded with stack dumps!". So what I do in this case is I run a midas program in the debugger and set a breakpoint (in your case at
> odb.cxx:6967). If the breakpoint triggers, I inspect the stack and find out where this comes from.
>
> Not that I print a stack dump for such error in the odbxx API. This goes to stdout, not the midas log, and it helped me in the past. Unfortunately
> stack dumps work only under linux (not MacOSX), and they do not contain all information a debugger can show you.
>
> It is not true that alarm conditions are evaluated when the alarm system is off. I just tried and it works fine. The code is here:
>
> alarm.cxx:591
>
> /* check global alarm flag */
> flag = TRUE;
> size = sizeof(flag);
> db_get_value(hDB, 0, "/Alarms/Alarm system active", &flag, &size, TID_BOOL, TRUE);
> if (!flag)
> return AL_SUCCESS;
>
> so no idea why you see this error if you correctly st "Alarm system active" to false.
>
> Stefan |
2770
|
17 May 2024 |
Konstantin Olchanski | Bug Report | odbedit load into the wrong place | Trying to restore IRIS ODB was a nasty surprise, old save files are in .odb format and odbedit "load xxx.odb"
does an unexpected thing.
mkdir tmp
cd tmp
load odb.xml loads odb.xml into the current directory "tmp"
load odb.json same thing
load odb.odb loads into "/" unexpectedly overwriting everything in my ODB with old data
this makes it impossible for me to restore just /equipment/beamline from old .odb save file (without
overwriting all of my odb with old data).
I look inside db_paste() and it looks like this is intentional, if ODB path names in the odb save file start
with "/" (and they do), instead of loading into the current directory it loads into "/", overwriting existing
data.
The fix would be to ignore the leading "/", always restore into the current directory. This will make odbedit
load consistent between all 3 odb save file formats.
Should I apply this change?
K.O. |
2771
|
17 May 2024 |
Konstantin Olchanski | Bug Report | midas alarm borked condition evaluation | >
> And I think I know what caused the original problem in IRIS experiment, I think the list of EPICS variables got truncated from 30 to 20 and EPICS
> values 29 and 30 used in the alarm conditions have become lost.
>
> So the next step is to fix feepics to not truncate the list of variables (right now it is hardwired to 20 variables) and restore
> the lost variable definition from a saved odb dump.
for the record, I restored the old ODB settings from feepics, my EPICS variables now have the correct size and the alarm now works correctly.
I also updated the example feepics to read the number of EPICS variables from ODB instead of always truncating them to 20 (IRIS MIDAS had a local change
setting number of variables to 40).
I think I will make no more changes to the alarms, leave well enough alone.
K.O. |
Draft
|
18 May 2024 |
Stefan Ritt | Bug Report | midas alarm borked condition evaluation | For everybody using EPICS: There is now a new system called MSetPoint (Midas Set Point) to control whole beamlines via EPICS.
It's under midas/msetpoint and the documentation is here:
https://bitbucket.org/tmidas/midas/wiki/MSetPoint
It is basically an EPICS frontend and two custom pages. The special thing is that the EPICS elements are not hardcoded in
the frontend but come from the ODB. There is even an editor for the beamline elements (second custom page). By loading different
ODB settings, one can switch easily between completely different beamlines without having to recompile the frontend. The system
can be operated standalone (all other MIDAS pages do not appear), or as a custom page in a normal midas setup. At PSI, this
system is now used as the standard editor for our beamlines.
Attached and example screen.
Stefan |
2773
|
18 May 2024 |
Stefan Ritt | Bug Report | midas alarm borked condition evaluation | For everybody using EPICS: There is now a new system called MSetPoint (Midas Set Point) to control whole beamlines via EPICS.
It's under midas/msetpoint and the documentation is here:
https://bitbucket.org/tmidas/midas/wiki/MSetPoint
It is basically an EPICS frontend and two custom pages. The special thing is that the EPICS elements are not hardcoded in
the frontend but come from the ODB. There is even an editor for the beamline elements (second custom page). By loading different
ODB settings, one can switch easily between completely different beamlines without having to recompile the frontend. The system
can be operated standalone (all other MIDAS pages do not appear), or as a custom page in a normal midas setup. At PSI, this
system is now used as the standard editor for our beamlines.
Attached and example screen.
Stefan |
Attachment 1: MSetPoint.png
|
|
2774
|
18 May 2024 |
Stefan Ritt | Bug Report | odbedit load into the wrong place | Taht's strange. I always was under the impression that .odb files are loaded relatively to the current location in
the ODB. The behaviour should not be different for different data formats, so I agree to change the .odb loading to
behave like the .xml and .json save/load.
Stefan |
2775
|
21 May 2024 |
Nikolay | Bug Report | experiment from midas/examples | There are 2 bugs in midas/examples/experiment:
1) In fronted bank named "PRDC" is created for scaler event. But in analyzer
module scaler.cxx the bank named "SCLR" is searched for the same event.
2) In mana.cxx linked from analyzer.cxx is "Invalid name "/Analyzer/Tests/Always
true/Rate [Hz]" passed to db_create_key: should not contain "["".
Looks like ODB doesn't like '[', ']' characters. |
Attachment 1: analyzer.jpg
|
|
2776
|
21 May 2024 |
Thomas Senger | Bug Report | Params not initialized when starting sequencer | Hi all,
On develop, the issue seems to be still there and is not fixed.
The parameters are currently "never" correctly initialized, only as "empty". Tried several times.
Thomas |
2777
|
21 May 2024 |
Zaher Salman | Bug Report | Params not initialized when starting sequencer | I traced the problem to a mjsonrpc_db_ls call where I read /Sequencer/Param... . It seems that this sometimes returns a status 312 (DB_NO_KEY) although I am sure all keys are there in the ODB.
I am still trying to solve this but I may need some help on the mjsonrpc.cxx code.
Zaher
Thomas Senger wrote: | Hi all,
On develop, the issue seems to be still there and is not fixed.
The parameters are currently "never" correctly initialized, only as "empty". Tried several times.
Thomas |
|
2778
|
21 May 2024 |
Zaher Salman | Bug Report | Params not initialized when starting sequencer | Hi Thomas,
I have a fix for the issue and I would be happy with testers if you are willing. Simply "git checkout newfeature_ZS" and give it a go. No need to recompile anything.
A change in /Sequencer/Param triggers a save of the values which is then used to produce the parameter dialog. This allows us to bypass the slow response in mjsonrpc calls just before the dialog.
Zaher
Thomas Senger wrote: | Hi all,
On develop, the issue seems to be still there and is not fixed.
The parameters are currently "never" correctly initialized, only as "empty". Tried several times.
Thomas |
|
|
2779
|
22 May 2024 |
Thomas Senger | Bug Report | Params not initialized when starting sequencer |
Hi Zaher,
thanks for your help.
I just tried the bug fix, but it still seems not to work properly.
It seems that if the script is short, it will work, but if many SUBROUTINES are integrated, it does not work and the parameter are initialized empty.
Best regards,
Thomas |
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 |
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 |
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 |
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? |
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 |
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) |
2799
|
07 Aug 2024 |
Stefan Ritt | Bug Report | File name bug in csv export |
Thanks. Fixed. Committed. Pulled on megon02.
Stefan |
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. |
2801
|
07 Aug 2024 |
Stefan Ritt | Bug Report | File name bug in csv export |
Fixed as well. |