filewriter: runlog/icp_event #92

Activity

1. Tom-Willemsen

   added

   filewriter

   on Jul 27, 2026
2. Tom-Willemsen

   added this to Data streaming for HRPD-X & SANDALS-IIon Jul 27, 2026
3. Tom-Willemsen

   moved this to research/needs discussion in Data streaming for HRPD-X & SANDALS-IIon Jul 27, 2026
4. Tom-Willemsen

   added this to the March 2027 milestone on Jul 27, 2026
5. Tom-Willemsen commented on Jul 28, 2026

   

   Tom-Willemsen

   on Jul 28, 2026

   MemberAuthor

   More actions

   Tris has confirmed that GudRun does not use runlog/icp_event.
6. martyngigg commented on Aug 3, 2026

   

   martyngigg

   on Aug 3, 2026

   More actions

   What what Mantid does with the icp_event (it actually checks for both this and icpevent names). It has a hardcoded set of commands that it interprets:

     if (newStyle) {
       command_map["START_COLLECTION"] = commands::BEGIN;
       command_map["STOP_COLLECTION"] = commands::END;
       command_map["CHANGE"] = commands::CHANGE_PERIOD;
       command_map["CHANGE_PERIOD"] = commands::CHANGE_PERIOD;
       command_map["ABORT"] = commands::ABORT;
     } else {
       command_map["BEGIN"] = commands::BEGIN;
       command_map["RESUME"] = commands::BEGIN;
       command_map["END_SE_WAIT"] = commands::BEGIN;
       command_map["PAUSE"] = commands::END;
       command_map["END"] = commands::END;
       command_map["ABORT"] = commands::ABORT;
       command_map["UPDATE"] = commands::END;
       command_map["START_SE_WAIT"] = commands::END;
       command_map["CHANGE"] = commands::CHANGE_PERIOD;
       command_map["CHANGE_PERIOD"] = commands::CHANGE_PERIOD;
     }

   It then builds two separate time-series logs that it adds to the workspace:

   • A boolean value log where true marks the timestamp of when BEGIN was last called and false marks the timestamp of when END was last called.
   • An integer value log where each time CHANGE_PERIOD n is encountered it appends a (timestamp, n) pair to define the period number at that time.

   There seems to be no parsing of numbers in GF x RF x GUAH x nor anything related to any other commands than those listed above.
7. Tom-Willemsen commented on Aug 3, 2026

   

   Tom-Willemsen

   on Aug 3, 2026

   Last edited by Tom-Willemsen

   MemberAuthor

   More actions

   Thanks @martyngigg .

   Did you have any thoughts on:

   • CHANGE_PERIOD will account for hardware periods as well as software periods (they look the same to the filewriter in the streaming system). This means that there could be a much higher frequency of CHANGE_PERIOD events than previously.
   • START_COLLECTION and STOP_COLLECTION will account for hardware vetos as well as pause/runcontrol (they look the same to the filewriter in the streaming system). This means that there could be a much higher frequency of START_COLLECTION and STOP_COLLECTION events than previously.

   Do you have a feeling for whether a high frequency of START_COLLECTION and STOP_COLLECTION events would cause performance or other problems in Mantid? For example:

   • On a TS1 instrument you may get the TS2 pulse veto coming on and off at 10Hz continuously.
   • On an instrument using hardware periods, we will likely implement dwell periods as a veto, this could in principle cause a 'bounce' every other frame for a DAQ/DWELL/DAQ/DWELL sequence

   Similarly for hardware periods, as hardware/software periods look the same to the streaming system, you may now see a lot more period changes than previously as you'll also see the hardware-triggered ones which may change once-per-frame repeatedly - so in theory could get updates at 50Hz.

   We can add extra logic to 'debounce' / filter out these high-frequency runstate transitions if we need to... at the cost of increasing complexity the more of this 'special' logic we need to add.