GIBNEY$:[HANDBOOK]PCS_NOTES.MEM

General interest -- ipcs events:  (01-Nov-2004)
-------------------------------
    Running simulation shots (or any other shots) on the pcs requires
    that certain vms-based programs are actively communicating with
    the evtmgr program on epicsrv.  To prime the pump (as it were):
      o on VMS, start up a shotclock:
          $ setup nstx        !if not already done
          $ shotclock "/big"
      o on rich:
          > usrtest
          Enter ['']:  event nstx_soc 111

    This sequence should cause the shotclock on vms to start
    counting, with the shot number "111" in the display.
    If this does not happen within, say, 20 seconds repeat
    the "event" command, maybe with a different shot number:
          Enter ['']:  event nstx_soc 112

    If this STILL does not work, check
        gibney$:[handbook]ipcs_nstx_restart.mem


Function call sequence:  (30-Sep-2002)
----------------------
  o run_realtime_init
  o initialize_hardware  (not in sw test mode)
  o set_time_zero
  o wait_for_start_signal
  o time_critical
  o hardware_finish_up
  o finish_up  (infra)
  o run_realtime_end

=========================================================================

Timing:
------
    CLOCK_CLEAR_TIME is number of usecs before machine Tzero when the
                    shot clock is reset to zero.
                    On D3D, this is 10 seconds before the shot.
                    On NSTX, it actually occurs at TSOP.  One might
                      initialize the clock to some arbitary number (like,
                      say, PRIMARY_START_TIME_FS) instead of zero.

    PRIMARY_START_TIME (-2.0f)  Time of start of PCS cycle.
                    On D3D this is (-9.0f) seconds.
                    On NSTX, it is TSOP (-2.0f) seconds.

    PRIMARY_START_TIME_FS  should be computed from PRIMARY_START_TIME.
                    It's number of usecs after CLOCK_CLEAR_TIME to the
                      start of the PCS cycle.  I.e., it's TSOP in
                      another guise.

Data acquisition:  16-Jun-1999
    The distinction between the "start_acq" and "get_new_data" routines
    is real, and it appears must be maintained.

    start_acq:  Gets current time.  Triggers digitizer(s) if required.
            Raw data may be placed in r->datavector.

    get_new_data:  Reads data into r->datavector, if not already there.
            Converts data from r->datavector, applying baseline correction
            and appropriate conversion factors.  Corrected data placed
            in current r->dmabuffer.

    In general, "start_acq" runs as the last of the "algorithm" routines.
    The "t" from start_acq is used to compute new targets etc at the
    bottom of the realtime loop in parallel with actual digitization.
    Back to the top of the realtime loop, and "get_new_data" reads the
    newly digitized data.

    NSTX note: since data acquisition is running completely indepently
        from the PCS, "start_acq" might simply return "t" for the next
        intended data set, even if we are well ahead in time.  Then
        we can compute targets etc in preparation for the actual
        arrival of "t" -- "get_new_data" would wait until "t" and then
        do its computations.


=========================================================================

Infrastructure notes:
--------------------

"new_shot_phase_tick" and
"new_continuous_target"
    Both of these routines, which are called consecutively at the end
    of the realtime loop, handle only one "tick" at a time.
    This is because "new_shot_phase_tick" might possibly load in a
    new phase or other change, and then "new_continuous_target" would
    have to act on this new set of information.

    It would seem that "new_shot_phase_tick" could be called multiply
    to bring all info up to date, then a modified "new_continuous_target"
    could be called once to bring individual values up to date.
    Modification to "new_continuous_target" would require adjusting
    pseq->current_time and phs->current_time to match phaseTick, but
    that is easily done.  Formerly, these values were only incremented.
    by one.  In modified version, we'd always be setting
    "pseq->current_time = phaseTick - pseq->first_entry_time".  Similarly
    for "phs".