It's a truncation issue, not a rounding issue, but that is semantics.
By truncating (rounding) elapsed time in ms toward its zero, i.e. toward the TimerPRE value, and truncating the remaining time in ms toward zero, the code is "throwing away" 1000 milliseconds between the two DIV instructions.
In the example shown, the top rung generates a remaining time of 5m41s = 581s = 581000ms, which is 961ms less than the 581961ms remaining, while the bottom rung generates an elapsed time of 18s = 18000ms, which is 39ms less than the actual elapsed time .ACC = 18-39. So the example leaves 961ms+39ms = 1000ms = one second on the table; Cinderella!
One possible fix, among many, with minimal change to existing AOI, would be to calculate the leftover milliseconds remaining, via a [MOD TotalTimeRemaining 1000 ModuloTransferMs] instruction on the first rung, and transfer (add) those to the second rung [ADD TimerACC ModulTransferMs TimerACClocal] before the first DIV and use TimerACClocal in place of TimerACC after that; as it stands now, that would make elapsed time start at 1 (after the first millisecond, anyway), and always be rounding up; reversing the rungs, but still transferring from first to second, would make the remaining time essentially start at 10m0s while elapsed time stayed at 0s through the first second.
Of course there are better approaches that would involve refactoring the entire AOI (but it's an AOI, so who cares?), and better handling of edge cases. E.g. one approach would involve rounding so the calculated whole-second transitions happen on the half-second (at 500ms remainder); one edge case is what to do if the .PRE value is not a multiple of 1000ms.
