The prediction buffer is the second most important part of the prediction chain, because it keeps track of the cycle history of the last X cycles (or timesteps), which are needed as input to the prediction step as context (history).
The prediction buffer does normally not subscribe to any normal CMW events.
Trigger behaviour
The prediction buffer has multiple triggers, and its behaviour/logic depends on what triggered it.
First trigger
A CycleData with current_prog or current_meas set (ideally both), from the Add Measurements before event builder. This trigger must come before cycle starts, and will then be appended to the internal list of CycleData from previous cycles. The internal list is a RingBuffer, and is set to timesteps, and will remove the oldest item automatically.
In addition, when triggered, if the internal buffer is sufficiently long (has enough history), a buffer will be created with all the stored CycleData, in sequence, and emitted to prediction. Normally this is called newBufferAvailable in sps-app-hysteresis.
Economy mode
A CycleData that has been detected as an Dynamic Economy or Full Economy, which happens either ~200 ms after cycle start, or 1150 ms before cycle start, respectively, needs to be re-predicted, if in the predictions are in autoregressive mode. This is because the last prediction serves as “past”/context to the prediction of the cycle that will come next, and therefore the predicted field must what was played (i.e. an economy mode cycle). The buffer does not distinguish between dynamic or full economy.
When triggered, the CycleData in the internal buffer corresponding to the cycle stamp will be replaced with the economy mode CycleData. Note that the CycleData.cycle will now be lsaCycleName_DYNECO or lsaCycleName_FULLECO instead of lsaCycleName, i.e. the cycle has “changed names”. After replacing the information in the internal buffer, a new buffer with the internal CycleData will be created and emitted for prediction.
This is called onEcoBufferAvailable, to allow the prediction to distinguish whether its a first prediction, or second one (in which case the previous state must be re-used…).
New programs
After a cycle has been trimmed, new programmed current will be computed in LSA, and added to the CycleData object. However this is not known until after the cycle has started (i.e. after prediction…), so the buffer subscribes to a signal which will deliver a CycleData with current_prog updated, and will update the internal corresponding CycleData when triggered.
New measured current (and field)
After a cycle has completed, new measured current, and field will be acquired, and the internal history CycleData is updated with the new measured current and field. This step is crucial if prediction is using measured current or field as input.