 03 May 2024, Zaher Salman, Bug Report, Params not initialized when starting sequencer
|
Could you please export and send me the /Sequencer ODB tree (or just /Sequencer/Param and /Sequencer/Variables) in both cases while the sequence is running.
|
03 May 2024, Stefan Ritt, Bug Report, Params not initialized when starting sequencer 
|
Ok, here is the complete code to reproduce the problem. Load parameter_test.msl which includes functions.msl. From the screenshot you see the variables
containing
garbage, and you also see that from the ODB screenshot. For completeness, I added Sequencer.json which contains the whole sequencer tree.
|
|
03 May 2024, Luigi Vigani, Bug Report, Params not initialized when starting sequencer
|
It is pretty much the same as Stefan, I attach here the screenshots. Also in my case it works sometimes, and sometimes partially (one or 2 params, like
in
attachment 3).
|
|
03 May 2024, Zaher Salman, Bug Report, Params not initialized when starting sequencer
|
I have been able to reproduce the problem only once. From what I see, it seems that the Variables ODB tree is not initialized properly from the Param tree.
Below are the messages from the failed run compared to a successful one. As far as I could see, the javascript code does not change anything in the Variables
ODB tree (only monitors it). The actual changes are done by the sequencer program, or am I wrong?
|
|
03 May 2024, Stefan Ritt, Bug Report, Params not initialized when starting sequencer
|
Ahh, that rings a bell:
1) JS opens start dialog box
|
|
03 May 2024, Zaher Salman, Bug Report, Params not initialized when starting sequencer
|
Thanks for the hint Stefan. I pushed a possible fix but I cannot test it since I cannot reproduce the issue.
> Ahh, that rings a bell:
|
|
03 May 2024, Stefan Ritt, Bug Report, Params not initialized when starting sequencer
|
Seems to me like the problem happens less frequently, but I still see it (1 out of 5 or so). The fact that /Sequencer/Params/Value is empty tells me that
the GUI
has the problem and not the sequencer side.
|
|
10 May 2024, Zaher Salman, Bug Report, Params not initialized when starting sequencer
|
I think that I finally managed to fix the problem. The default values of the parameters are now written first in one go, then the sequencer waits for confirmation
that everything is completed before proceeding. Please test and let me know if there are still any issues.
|
|
13 May 2024, Luigi Vigani, Bug Report, Params not initialized when starting sequencer
|
[quote="Zaher Salman"]I think that I finally managed to fix the problem. The default values of the parameters are now written first in one
go, then the sequencer waits for confirmation that everything is completed before proceeding. Please test and let me know if there are still any issues.
Zaher [/quote] |
|
13 May 2024, Luigi Vigani, Bug Report, Params not initialized when starting sequencer
|
[quote="Zaher Salman"]I think that I finally managed to fix the problem. The default values of the parameters are now written first in one go, then the
sequencer waits for confirmation that everything is completed before proceeding. Please test and let me know if there are still any issues.
|
 16 May 2024, Konstantin Olchanski, Bug Report, midas alarm borked condition evaluation
|
I am updating the TRIUMF IRIS experiment to the latest version of MIDAS. I see following error messages in midas.log:
19:06:16.806 2024/05/16 [mhttpd,ERROR] [odb.cxx:6967:db_get_data_index,ERROR] index (29) exceeds array length (20) for key
|
|
17 May 2024, Stefan Ritt, 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.
|
|
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.
|
|
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.
|
|
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.
|
|
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:
|
|
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:
|
|
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.
|
|
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
|
|
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.
|