Does anyone know if it’s a bug or design, that if you do a rotary tool job, then stop it, then run the boundary for the next job, it will “unwind” the rotations of the previous job? ie. if the job did 100 turns clockwise, it will then do 100 turns anti-clockwise.
I understand adding the degrees of turn for a job, but surely when running a boundary it can/should do a modulo 360 on the degrees, and then just move the last proportion of a turn?
Anyone shed any light on this behaviour?
This is probably a bug. The gcode files are probably written in absolute coordinates (ie instead of saying turn 20 degrees then another 20 degrees it says go to position 20 then position 40). As such, the rotary axis may be at position 10000 by the time you end the job. When running the boundary it then tells the module to go to position 0 leading to the observed behavior.
They could reset the 0 on the rotary axis when a job is cancelled or something similar to resolve this.
Because it runs that many degrees out during a run, it’s very annoying. However, in my multi-pass rotary guide, I explain how to get around it instead of waiting.
Entire guide:
Snippet for resetting B:
3: Set the B origin back to 0.
3a: For this, take the number on the control screen for B (Mine was B70249.00)
3b: Divide it by 360 (Mine was 195.4138).
3c: Remove the decimals and multiply the whole number by 360. (195x360=70,200)
3d: Use the touchscreen controls to rotate to what you got in the equation (Mine: B70200.00) It should be back on the exact B origin you set (if you set a jaw clamp straight up, it should be straight up again, your model should also be pointing directly up)
3e: Tap the set origin tab, set B origin. Do not tap on any other axis.
Thanks Skreelink. I actually read that very article before seeing this reply. Now I just have to remember to do that before I run a boundary or similar. 
It’d be nice if they applied this logic when “rewinding” in code, so we didn’t’ have to. Shouldn’t be hard to implement, and would be more accurate, as they can use their x places of precision for sub-degree movement, which we can’t through the console.
I’ve also asked a question about multiple finishing passes, but best to answer on the guide, as it’s more relevant than here.
Thanks again. 
Annoyingly, after breaking a bit and letting it “unwind” (for accuracy - before I read your article), it appears that the repeat job is about 30 degrees out from the original (same g-code), so the unwind isn’t that accurate anyway! Anyone ever noticed any twist/spiral to their models?
@Skreelink - interesting thing I noticed. When running a “rotation” pass, it “unwinds” exactly 2 rotations on each pass (doing the 1.5mm remaining, 1.4mm remaining, etc as discussed on your thread), one while moving the X/Y for the next pass, then another, apparently just for fun. However, when doing a “Linkage” pass, it unwinds the number of turns for the pass. They obviously worked it out for Rotation, but forgot on Linkage. These rewind accurately (unlike my current experience with the “return to origin” rewind I’ve experienced. Not sure I’m thrilled about the 0.2* resolution by hand, either, but that’s another issue.