ELOG Midas

Back Midas Rome Roody Rootana

Midas DAQ System, Page 137 of 137

Not logged in

Find | Login | Help

Full | Summary | Threaded | Hide attachments

2726 Entries

Goto page Previous 1, 2, 3 ... 135, 136, 137

ID	Date	Author	Topic	Subject
2747	30 Apr 2024	Scott Oser	Forum	Midas Sequencer with less than 1 second wait
> While I will do it, i'm not sure if this is what you want. If I understand correctly, some process gets triggered and then writes some values to the ODB, then the sequencer > should continue. Putting a wait there is dangerous. Maybe your process always takes like 10-20 ms, so you put a wait of let's say 100ms, and things are fine with you. Your > script runs many days, but then once in a while your machine is on heavy load because someone starts a web browser, and your process takes 110ms, and you script crashes. > > I would rather go following path: put a "done" flag in the ODB, which is the last one which gets set by your process. Then the sequencer does a > > WAIT ODBvalue, /path/value, =, 1 > > which will work always, independend of the delay of your process. > > Stefan Our use case is pretty simple and I don't think is affected by the scenario you envision. We want to turn on a setting in our equipment, and turn it off again some 0.2 s later. We don't need msec timing. So something like: ODBSET /somekey 1 # this will cause a front-end to flip a bit in our hardware WAIT seconds, 0.2 ODBSET /somekey 0 # this will cause a front-end to reset a bit in our hardware It is true that if the load is high there could be a little delay, and the time that the bit is set will not be 0.2 seconds, but on average it should work, and it should be good enough we think. Yes, we could also check an ODB key to see that something is done, but we'd still need the ability to wait for time intervals less than 1 second, which right now doesn't exist.
2748	02 May 2024	Stefan Ritt	Forum	Midas Sequencer with less than 1 second wait
Ok, I implemented the float second wait function. Internally it works in ms, so the maximum resolution is 0.001 s. Best, Stefan
2749	02 May 2024	Scott Oser	Forum	Midas Sequencer with less than 1 second wait
> Ok, I implemented the float second wait function. Internally it works in ms, so the maximum resolution is 0.001 s. > > Best, > Stefan Thank you, we will test this soon and let you know if we see any issues (but we're not expecting any).
2750	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. thanks, Zaher > Good afternoon, > > After updating Midas to the latest develop commit > (0f5436d901a1dfaf6da2b94e2d87f870e3611cf1) we found out a bug when starting > sequencer. If we have a simple loop from start value to stop value and step > size, just printing the value at each iteration, we see everything good (see > first attachment). Then we included another script though, which contains > several subroutines we defined for our detector, and we try to run the same > script. Unfortunately after this the parameters seem uninitialized, and the > value at each loop does not make sense (see second attachment). Also, sometimes > when pressing run the set parameter window would pop-up, but sometimes not. > > The script is this one: > > >>> > COMMENT Test script to check for a specific bug > > INCLUDE global_basic_functions > > #CALL setup_paths > #CALL generate_DUT_params > > PARAM lv_start, "Start of LV", 1.8 > PARAM lv_stop, "Stop of LV", 2.1 > PARAM lv_step, "Step of LV", 0.02 > > n_iterations = (($lv_stop - $lv_start)/$lv_step) > > MSG "Parameters:" > MSG $lv_start > MSG $lv_stop > MSG $lv_step > MSG $n_iterations > > MSG "Start of looping" > > LOOP n, $n_iterations > lv_now = $lv_start + $n * $lv_step > MSG $lv_now > WAIT SECONDS, 1 > ENDLOOP > <<< > > and the only difference comes from commenting the line: > > >>> > INCLUDE global_basic_functions > <<< > > as global_basic_functions is defined as a LIBRARY and it includes 75 (!) > subroutines... > > Is it possible that when loading a large script it messes up the loading of > parameters? > > Thank you very much, > Regards, > Luigi.
2751	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. The interesting thing is that this works sometimes, and sometimes not. I'm not sure if this in the GUI or in the sequencer program, so we have to sort out who can fix it ;-) Best, Stefan
Attachment 1: param_test.msl
INCLUDE functions PARAM lv_start, "Start of LV", 1.8 PARAM lv_stop, "Stop of LV", 2.1 PARAM lv_step, "Step of LV", 0.02 n_iterations = (($lv_stop - $lv_start)/$lv_step) MSG "Parameters:" MSG $lv_start MSG $lv_stop MSG $lv_step MSG $n_iterations MSG "Start of looping" LOOP n, $n_iterations lv_now = $lv_start + $n * $lv_step MSG $lv_now WAIT SECONDS, 1 ENDLOOP
Attachment 2: functions.msl
SUBROUTINE sub1 WAIT seconds, 1 ENDSUBROUTINE SUBROUTINE sub2 WAIT seconds, 1 ENDSUBROUTINE SUBROUTINE sub3 WAIT seconds, 1 ENDSUBROUTINE SUBROUTINE sub4 WAIT seconds, 1 ENDSUBROUTINE SUBROUTINE sub5 WAIT seconds, 1 ENDSUBROUTINE SUBROUTINE sub6 WAIT seconds, 1 ENDSUBROUTINE
Attachment 3: Sequencer.json
{ "/MIDAS version": "2.1", "/filename": "Sequencer.json", "/ODB path": "/Sequencer", "State": { "New File/key": { "type": 8, "access_mode": 7, "last_written": 1714720819 }, "New File": false, "Path/key": { "type": 12, "item_size": 256, "access_mode": 7, "last_written": 1714720819 }, "Path": "", "Filename/key": { "type": 12, "item_size": 256, "access_mode": 7, "last_written": 1714720819 }, "Filename": "param_test.msl", "SFilename/key": { "type": 12, "item_size": 256, "access_mode": 7, "last_written": 1714720819 }, "SFilename": "/Users/ritt/online/userfiles/sequencer/param_test.msl", "Next Filename/key": { "type": 12, "num_values": 10, "item_size": 256, "access_mode": 7, "last_written": 1714720819 }, "Next Filename": [ "", "", "", "", "", "", "", "", "", "" ], "Error/key": { "type": 12, "item_size": 256, "access_mode": 7, "last_written": 1714720819 }, "Error": "", "Error line/key": { "type": 7, "access_mode": 7, "last_written": 1714720819 }, "Error line": 0, "SError line/key": { "type": 7, "access_mode": 7, "last_written": 1714720819 }, "SError line": 0, "Message/key": { "type": 12, "item_size": 256, "access_mode": 7, "last_written": 1714720819 }, "Message": "", "Message Wait/key": { "type": 8, "access_mode": 7, "last_written": 1714720819 }, "Message Wait": false, "Running/key": { "type": 8, "access_mode": 7, "last_written": 1714720819 }, "Running": true, "Finished/key": { "type": 8, "access_mode": 7, "last_written": 1714720819 }, "Finished": false, "Paused/key": { "type": 8, "access_mode": 7, "last_written": 1714720819 }, "Paused": false, "Debug/key": { "type": 8, "access_mode": 7, "last_written": 1714720819 }, "Debug": false, "Current line number/key": { "type": 7, "access_mode": 7, "last_written": 1714720819 }, "Current line number": 46, "SCurrent line number/key": { "type": 7, "access_mode": 7, "last_written": 1714720819 }, "SCurrent line number": 20, "Follow Libraries/key": { "type": 8, "access_mode": 7, "last_written": 1714720819 }, "Follow Libraries": true, "Stop after run/key": { "type": 8, "access_mode": 7, "last_written": 1714720819 }, "Stop after run": false, "Transition request/key": { "type": 8, "access_mode": 7, "last_written": 1714720819 }, "Transition request": false, "Loop start line/key": { "type": 7, "num_values": 10, "access_mode": 7, "last_written": 1714720819 }, "Loop start line": [ 43, 0, 0, 0, 0, 0, 0, 0, 0, 0 ], "SLoop start line/key": { "type": 7, "num_values": 10, "access_mode": 7, "last_written": 1714720819 }, "SLoop start line": [ 17, 0, 0, 0, 0, 0, 0, 0, 0, 0 ], "Loop end line/key": { "type": 7, "num_values": 10, "access_mode": 7, "last_written": 1714720819 }, "Loop end line": [ 47, 0, 0, 0, 0, 0, 0, 0, 0, 0 ], "SLoop end line/key": { "type": 7, "num_values": 10, "access_mode": 7, "last_written": 1714720819 }, "SLoop end line": [ 21, 0, 0, 0, 0, 0, 0, 0, 0, 0 ], "Loop counter/key": { "type": 7, "num_values": 10, "access_mode": 7, "last_written": 1714720819 }, "Loop counter": [ 6, 0, 0, 0, 0, 0, 0, 0, 0, 0 ], "Loop n/key": { "type": 7, "num_values": 10, "access_mode": 7, "last_written": 1714720819 }, "Loop n": [ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 ], "Subdir/key": { "type": 12, "item_size": 256, "access_mode": 7, "last_written": 1714720819 }, "Subdir": "", "Subdir end line/key": { "type": 7, "access_mode": 7, "last_written": 1714720819 }, "Subdir end line": 0, "Subdir not notify/key": { "type": 7, "access_mode": 7, "last_written": 1714720819 }, "Subdir not notify": 0, "If index/key": { "type": 7, "access_mode": 7, "last_written": 1714720819 }, "If index": 0, "If line/key": { "type": 7, "num_values": 10, "access_mode": 7, "last_written": 1714720819 }, "If line": [ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 ], "If else line/key": { "type": 7, "num_values": 10, "access_mode": 7, "last_written": 1714720819 }, "If else line": [ 0, 0, 0, 0, 0, ... 379 more lines ...
Attachment 4: Screenshot_2024-05-03_at_09.19.29.png

Attachment 5: Screenshot_2024-05-03_at_09.20.47.png

2752	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). > 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. > > thanks, > Zaher > > > > Good afternoon, > > > > After updating Midas to the latest develop commit > > (0f5436d901a1dfaf6da2b94e2d87f870e3611cf1) we found out a bug when starting > > sequencer. If we have a simple loop from start value to stop value and step > > size, just printing the value at each iteration, we see everything good (see > > first attachment). Then we included another script though, which contains > > several subroutines we defined for our detector, and we try to run the same > > script. Unfortunately after this the parameters seem uninitialized, and the > > value at each loop does not make sense (see second attachment). Also, sometimes > > when pressing run the set parameter window would pop-up, but sometimes not. > > > > The script is this one: > > > > >>> > > COMMENT Test script to check for a specific bug > > > > INCLUDE global_basic_functions > > > > #CALL setup_paths > > #CALL generate_DUT_params > > > > PARAM lv_start, "Start of LV", 1.8 > > PARAM lv_stop, "Stop of LV", 2.1 > > PARAM lv_step, "Step of LV", 0.02 > > > > n_iterations = (($lv_stop - $lv_start)/$lv_step) > > > > MSG "Parameters:" > > MSG $lv_start > > MSG $lv_stop > > MSG $lv_step > > MSG $n_iterations > > > > MSG "Start of looping" > > > > LOOP n, $n_iterations > > lv_now = $lv_start + $n * $lv_step > > MSG $lv_now > > WAIT SECONDS, 1 > > ENDLOOP > > <<< > > > > and the only difference comes from commenting the line: > > > > >>> > > INCLUDE global_basic_functions > > <<< > > > > as global_basic_functions is defined as a LIBRARY and it includes 75 (!) > > subroutines... > > > > Is it possible that when loading a large script it messes up the loading of > > parameters? > > > > Thank you very much, > > Regards, > > Luigi.
Attachment 1: seq1.PNG

Attachment 2: seq2.PNG

Attachment 3: seq3.PNG

Goto page Previous 1, 2, 3 ... 135, 136, 137

ELOG V3.1.4-2e1708b5