You shouldn't discount the idea that there's just some dumb rounding errors in the code, either in the controller or in the firmware - very possible, and it's only these kinds of larger-scale fields of regular marks that show it off.
There's definitely a mechanical "rounding error" to do with the slight mismatch between the pitch of the beaded cord and the circumference of the sprocket, you can see it in the dark hat brim on this norwegian pixel drawing:
Where there's a couple of thin gaps concentric with the left-hand-sprocket.
I don't know how to explain it properly, but I think the cord around the sprockets is slightly loose, so it's held in place by the beads in the teeth, but once it leaves the sprocket it gets stretched out a tiny bit more. Overall, one turn of the sprocket does give out the accurate length of cord, but it's distribution isn't completely even. It's extension per step isn't always equal, and it leads to the pattern of the teeth leaving an imprint in the marks on the paper.
That's one idea.
The other thing is that although the machine uses microsteps, if you're using stepMultiplier=8 (and stepsPerRev=200) then it only uses them internally, in order to make for smooth movement. The start and end points are still quantised to the coarser, non-microstepped grid. You could change to stepMultipler=1 and stepsPerRev=1600 to get the true addressable points available. But there will be artefacts that come from the imprecision of microstepping too 🙂
This is brilliant piece of diagnostic work DaniK, and I love the visualisations - a great way to see the quantisation effects.
sn
|
Author
some more polargraph-ARTefacts
