We had noticed the possibility that this kind of issue would occurred by the current implementation of LSC_LOCK guardian.
This issue occurs when the duration staying in the DOWN (1) state is short after requesting DOWN.
Because I could confirm that this issue was just a failure of loading observation.snap in the LOCK_PREP (5) state,
I asked Yuzurihara-kun to execute the script to load observation.snap.
-----
LSC_LOCK guardian requests all models to load down.snap only when the DOWN state is requested.
This means that loading down.snap is skipped in normal lockloss cases because the requested state
is kept as OBSERVATION in such cases.
Anyway, DOWN state was requested in this time as shown in Fig.1 (see crosshair at 14:56:56 JST) and down.snap was loaded.
Though changing the loaded table (e.g. observation.snap -> down.snap) takes ~25s, OBSERVATION was requested ~5s after the
DOWN request and the process that requests to load observation.snap was started ~6s after the DOWN request
(Duration staying DOWN is only ~5s as shown by the t-cursors in Fig.1.
As the results, requesting down.snap and requesting observation.snap run in parallel and loading observation.snap was requested
before loading down.snap was completed on some models.
Timeline:
14:56:56 requested DOWN state.
14:56:57 started loading down.snap
14:57:02 requested OBSERVATION state
14:57:04 started loading observation.snap
14:57:19 finished loading down.snap and loading observation.snap