(* =====================================================================
   91_config_sim.st - CONFIGURATION, simulation build

   Replaces 90_config_field.st in `--mode sim`.  Identical to it except
   for the third program instance.

   Scan task: 100 ms cyclic, section 4.  The interval must stay at
   100 ms: FB_PUMP, FB_LEVEL_CTRL and FB_HEADROOM all integrate against
   a hardcoded SCAN_S := 0.1, as does PROGRAM SIMULATION.

   Declaration order sets execution order within the task:

     SIMULATION  first  - models the plant, using the run commands and
                          speed CONTROL published on the previous scan
     IO_MUX      second - simulated image in, previous scan's outputs out
     CONTROL     third  - reads only the process image

   Section 8.2 says SIMULATION runs AFTER CONTROL.  It runs first here,
   deliberately.  With it last, the first scan after every start has no
   simulated image yet, so IO_MUX falls back to the (all zero) field
   inputs - and an all-zero field means ThermalOK FALSE and LSLL dry,
   which makes FB_PUMP latch a trip on all three units and the station
   enter dry-run lockout.  Those latch until a reset command, so every
   demo would have to begin by clearing trips that never happened.

   The cost of running it first is that SIMULATION reacts to run
   commands one scan late - 100 ms at 1x.  That is the same lag IO_MUX
   already has on published outputs, and it is invisible next to a
   3 s pump start delay.

   Simulation time scaling (%MW23) applies only inside SIMULATION.
   CONTROL's timers stay in real seconds; see README.md.
   ===================================================================== *)

CONFIGURATION Config0

  RESOURCE Res0 ON PLC
    TASK plc_task(INTERVAL := T#100ms, PRIORITY := 0);

    PROGRAM inst_sim WITH plc_task : SIMULATION;
    PROGRAM inst_mux WITH plc_task : IO_MUX;
    PROGRAM inst_ctl WITH plc_task : CONTROL;
  END_RESOURCE

END_CONFIGURATION