Try this loop:
<commands>
<loop>
<device>loc://x(0)</device>
<start>1.0</start>
<end>1.1</end>
<step>5.0</step>
<wait>false</wait>
<tolerance>0.5</tolerance>
<body>
<log><devices><device>loc://x(0)</device></devices></log>
</body>
</loop>
</commands>
Yes, the step size is too large.
One could argue if it should execute steps 1.0 and then 1.1, or just 1.0 and then no second step.
Instead, we get steps 1.0 and 6.0, which wasn't the case in the original implementation.
At first glance, the change could come from one of these commits
commit a9875c1
Date: Tue Mar 4 09:13:11 2025 +0100
don't use functions with side effects and update getWorkUnits
commit 0e2df3a
Date: Tue Mar 4 09:05:35 2025 +0100
add extra step for including bounds
commit 6f10297
Date: Mon Mar 3 16:38:29 2025 +0100
make sure alternating scans work with predictable steps
commit 30964db
Date: Mon Mar 3 15:48:11 2025 +0100
make number of steps in loop command predictable
Try this loop:
Yes, the step size is too large.
One could argue if it should execute steps 1.0 and then 1.1, or just 1.0 and then no second step.
Instead, we get steps 1.0 and 6.0, which wasn't the case in the original implementation.
At first glance, the change could come from one of these commits
commit a9875c1
Date: Tue Mar 4 09:13:11 2025 +0100
commit 0e2df3a
Date: Tue Mar 4 09:05:35 2025 +0100
commit 6f10297
Date: Mon Mar 3 16:38:29 2025 +0100
commit 30964db
Date: Mon Mar 3 15:48:11 2025 +0100