I have many equipments that update history variables periodically during a run. Previously the history DB would only get updated if the frontend was running and a run was in progress. However, it seems that the new
log_history_periodic() business with minimum and maximum logging periods does not account for either of these factors, and the history DB is being "updated" with stale values even if the frontend is stopped. This is significantly bloating the history DB with useless/misleading data.
For all of my frontends, the old logic of only using the hotlink made total sense - when the FE updates the variables, the new values get written to the DB. Even if the values haven’t really changed during the run, the FE still re-writes the values and the hotlink gets triggered. We never get any big gaps in the history during a run, as we’re always updating every 10s or so.
For this very common use case, the
log_history_periodic() is redundant during a run (as it’s already a periodic equipment) and broken the rest of the time.
I’m not sure what the best solution is. Perhaps
max_period could be set to a very large number (instead of
Common/Period) if the equipment is already periodic? If that doesn’t work, then I feel like the whole
log_history_periodic() concept may need to be revisited.