mfe.c RO_STOPPED is now forbidden?

[dd1]

unexpectedly I have an mfe.c frontend stop working after I updated MIDAS to a newer version. it turns out there is a commit to mfe.c that forbids the use of RO_STOPPED for most equipment types. there is no explanation and there is no announcement of this change on the midas forum. why was it done? certainly reading and generating events always worked when run is stopped and sometimes it is useful. tmfe c++ frontend supports this. so what happened? K.O.

[dd1]

actually the frontend uses RO_ALWAYS, not RO_STOPPED. I did not write this frontend and it will cost me additional time to track down the author and have him confirm that replacing RO_AWAYS with RO_ALWAYS&~RO_RUNNING is okey. K.O.

[dd1]

https://bitbucket.org/tmidas/midas/commits/1961af0d657e4f76ab9db17f9b70c0c492172b6d

[Stefan Ritt]

We had a problem in one of our experiments that people accidentally had RO_STOPPED enabled for triggered events. While RO_STOPPED is perfectly fine for periodic events, it does not make sense for triggered events. Why should we have run start/stop if you send triggered events always?

[Stefan Ritt]

Are you sure that your RO_ALWAYS is for triggered events? (meaning EQ_POLLED, EQ_INTERRUPT, EQ_USER, EQ_MULTITHREAD). RO_ALWAYS is to my knowledge only used for EQ_PERIODIC or EQ_SLOW.

‌

‌

[dd1]

BTW, in the past, we used EQ_MULTITHREAD for multithreaded slow control events.

[dd1]

all new frontends use the tmfe c++ frontend, which does not have your check. so whatever problem exists with sending events when there is no run is not fixed.

[dd1]

so why exactly are we in trouble if events are generated and written to event buffer when there is no run? writing to a custom event buffer I do not see any problems. writing to the SYSTEM buffer, there may be a problem with mlogger at the end of run - it will wait for “buffer_level” to be zero - and if frontend generates events faster than logger writes them, the run will never stop. but typical case, mlogger writes data faster than all frontends generate it. any other problem places? K.O.

[Stefan Ritt]

Using EQ_MULTITHREAD with slow control events is wrong. Have a look at the documentation at https://daq00.triumf.ca/MidasWiki/index.php/Equipment_Flags where it’s clearly stated that EQ_MULTITHREAD has to be used together with polled events, and slow control events are not polled. Multi-threading for slow control events is controlled via the DF_MULTITHREAD flag in the slow control device driver tree.

[Stefan Ritt]

So to summarize this discussion: EQ_POLLED events together with RO_STOPPED or RO_ALWAYS is an invalid parameter combination. Up to now, this wrong parameter combination was allowed, leading possibly to strange side effects. With the new check the user is at least warned that this is an invalid combination. I did not originally post this change via the forum since I thought it’s just fixing a bug. Like if we have a function where we later add testing for invalid parameters like

void f(int p) {
   if (p < 0) {
      printf("Error: Invalid parameter p\n");
      ...
   }
}

I simply did not expect that people were using this invalid parameter combination and RELY on it for their frontend to start. Now it’s announce and users should fix it everywhere.

[Stefan Ritt]

@dd1 Can we resolve now that issue? Better you resolve it to confirm you agree with the solution.