12.9.1 Evaluation Lead-Time for Flow-Control Commands

Parsing of any given list command into output data (galvo position updates, etc.) does not occur instantaneously: some finite time is always required for the calculations.
The output step-period is fixed at 10µs, so ideally each and every command would be parsed in less than 10µs, allowing output data to be generated directly and continuously.
In reality, however, the time required to parse a command varies with the type of command and its parameters.
Consequently, the SP-ICE-3 Card has been designed to (pre-)calculate output data at a higher rate on average than that at which those data are consumed by the 10µs step-period.

The card attempts to pre-calculate about 16ms worth of output data. It parses as many commands as necessary from the list being processed, and pushes the output data into a FIFO buffer from which they can be extracted at the steady 10µs step-rate.

• We define the Pre-Calculation Time (PCT) as the time taken by the card to pre-calculate 16ms worth of output data.
  PCT is generally significant, though usually far less than 16ms.

When the SP-ICE-3 Card parses a conditional flow-control command within a command list, it has to test the specified condition while parsing that command, in order to find out which of the two possible branch-paths to follow.
The card obviously needs to know which commands will be next in sequence after the conditional flow-control command, otherwise it will not be able to carry on pre-calculating more output data.
It cannot simply defer testing the condition until the flow-control command takes effect (i.e. when the immediately preceeding command exits the FIFO), because that would require it either to be clairvoyant(!), or to pre-calculate both of the possible branch-paths.

Testing the condition while parsing the command presents problems of its own, however:

• Due to the FIFO, there is a discrepancy of up to 16ms between the time at which the condition is tested, and the time at which the flow-control command actually takes effect ( i.e. immediately after the preceeding command exits the FIFO ).

• If the condition is being tested within a tight loop, the card will carry on pre-calculating passes through the loop until the FIFO contains 16ms worth of output data.
  Unfortunately, this also means that the card will not react to a change in the tested condition immediately, but only after all of those pre-calculated passes (at least) have been executed.

We can mitigate against these inherent problems by telling the card to test the condition at a specified time before the point at which the flow-control command would take effect.
The Evaluation Lead Time (ELT) may be used to instruct the card not to test the condition immediately upon parsing the flow-control command, but instead to temporarily suspend further parsing until the specified point in time before the end of the Execution Time of Preceeding commands ( ETP) is reached.
Once the condition has been tested, parsing of the subsequent commands on the selected branch-path can resume.

The ProcessVariablesEvaluationLeadTime property allows us to specify an appropriate value for ELT.

Caution

We must be careful not to specify an ELT that is too short. We must take the PCT (defined above) into account. If the condition is tested when the remaining execution time of output data currently in the FIFO is less than the specified ELT, then parsing will become stalled at the conditional flow-control command for at least (PCT - ELT). The danger here is that if the laser was already active when the stall occurs, then it will remain active, at least until (PCT - ELT) has elapsed, which could cause unexpected burn-ins.

For a given application, then, we have to find a compromise between:

• a longer EvaluationLeadTime value, which:

  • tests the condition early enough that parsing will not stall, but...

  • we probably do not want to test for the condition so far ahead of time that it has not yet actually materialised!

• a shorter EvaluationLeadTime value, which:

  • tests for the condition late enough that it has definitely manifested itself, but...

  • might provoke stalling, and as a consequence, unexpected, and possibly dangerous, burn-ins!

Reference

Other Resources