|
|
|
Back
Midas
Rome
Roody
Rootana
|
| Midas DAQ System |
Not logged in |
 |
|
|
 29 Jan 2020, Pintaudi Giorgio, Info, Force triggering of idle routine of a frontend
|
 02 Feb 2020, Konstantin Olchanski, Info, Force triggering of idle routine of a frontend
| |
02 Feb 2020, Pintaudi Giorgio, Info, Force triggering of idle routine of a frontend
| |
03 Feb 2020, Stefan Ritt, Info, Force triggering of idle routine of a frontend
| |
04 Feb 2020, Pintaudi Giorgio, Info, Force triggering of idle routine of a frontend
| |
07 Feb 2020, Stefan Ritt, Info, Force triggering of idle routine of a frontend
| |
07 Feb 2020, Pintaudi Giorgio, Info, Force triggering of idle routine of a frontend
| |
09 Feb 2020, Stefan Ritt, Info, Force triggering of idle routine of a frontend
| |
10 Feb 2020, Konstantin Olchanski, Info, Force triggering of idle routine of a frontend
| |
12 Feb 2020, Stefan Ritt, Info, Force triggering of idle routine of a frontend
|
|
|
Message ID: 1821
Entry time: 12 Feb 2020
In reply to: 1812
|
| Author: |
Stefan Ritt |
| Topic: |
Info |
| Subject: |
Force triggering of idle routine of a frontend |
|
|
I had a look again at the issue. If you sett the event limit to zero in the EQUIPMENT list, then the idle() routine of your class driver is called as often as possible. Typically with 100 Hz. It's then up to you what to do in the class driver. The hv_idle() routine of the HV class driver shipped in the distribution for example read a channel more often if it has been changed recently. Look at the lines
/* additionally read channel recently updated if not multithreaded */
if (!(hv_info->driver[hv_info->last_channel]->flags & DF_MULTITHREAD)) {
act_time = ss_millitime();
act = (hv_info->last_channel_updated + 1) % hv_info->num_channels;
while (!(act_time - hv_info->last_change[act] < 10000)) {
act = (act + 1) % hv_info->num_channels;
if (act == hv_info->last_channel_updated) {
/* non found, so return */
return status;
}
}
/* updated channel found, so read it additionally */
status = hv_read(pequipment, act);
hv_info->last_channel_updated = act;
}
You can do similar things there like if you are ramping. On an end-of-run, the class drivers cd_xx_read() routine is called from the framework, which in turn sends a full midas event down the stream, but getting the current slow control values from its local cache, not from the actual device (otherwise stopping a run could be very slow). So if you want all values at the end of the run with good precision, you have to read them DURING the run as fast as possible. That's why I posted my comment about fixing dropped serial connections automatically and reading as fast as possible.
Stefan
| Pintaudi Giorgio wrote: | Dear Stefan,
Thank you for the advice. I will try to modify the driver as you say. As for the dynamical change of readout rate, basically you are telling me that is not achievable without dirty hacks like mine and it is better to find a way to avoid it.
|
|