I am hoping that someone can explain this to me. Here are the facts. 200 step 1.8* Stepper, 5mm Pitch. 1/8 microstepping. Based on the calculation this would result in 320 steps per mm. And from that a resolution per step of .003125mm. Now the question. If I want to do a move of say .01mm, that would equal 3.2 steps. .01/.003125 = 3.2 steps. So, I'm guessing the machine can only move the 3 steps as steps are the only possible increment. So....what happens to the .2 steps that are "lost"?
My understanding is that no steps are lost - it'll move 3 (micro)steps, not 3.2. The motor will do what it will do. Your resolution will be different than you expect.
My guess is that the 0.2 will be bookkept in the controller. So next time it will only need 0.8 steps to take one step (or .3 if you take rounding into account)
Wouldn't that be awesome? My impression, after spending a non-trivial amount of time investigating GRBL, is that this is not the case. Best advice I have (FWIW) is to pick a configuration resulting in integer steps.
If you google 'z banding' you'll see that the problem you've mentioned comes up as one of the reason for the banding. I had that problem when I used a 3/8" threaded rod. Since it's imperial it doesn't let you get 'integer stepps' as Techvette said. I changed my screws to 8mm with 2mm pitch and now the problem was solved since I used 0.2mm layer height.
I dont know the resolution of the floating point numbers inside GRBL but I do know how it all works, in theory. You store 2 numbers, one is the requested position and the other is the integer number of steps actually taken so far. when a new move is commanded the code has to convert the requested position into a number of steps, using the resolution as a divider and rounding off, hopefully in some clever ways. It is a kind of modified Bresenhams line algorithm (-: but of course there are limits and tradeoffs. the actual resolution of the floating point numbers is limited by the number of bits stored, and by the accuracy of the library used, the hardware, and speed constraints. I know from bitter experience that 4 byte 'single precision' floating point numbers are not in fact 'precise' at all and will cause trouble with calculations involving small or large numbers, and various combinations of log/exp and sqrt operations. I have implemented many workarounds in my day job to fix these things, most often just using 8 byte doubles for intermediate results. This is usually a quick fix. However, GRBL on an Arduino is in no way going to be using an 8 byte format.... (yp, some googling shows that the arduino compiler only allows 4 byte floats, with 5 to 9 digits of precision). so the end result is that there will be a lack of precision on a step to step basis but overall a machine should work fine within the limits of its design and construction. if you need 0.001mm accuracy then GRBL is probably not the controller you need. My Ox works just fine with 0.025mm per step on X and Y and 0.01 on Z. I never jog less then 0.1mm during setup to find the 0 positions. Just not worth it when I factor in belt stretch, microstepping fudge factors etc.
Wow - I haven't heard good 'ol Bresenham mentioned in a few years. Good point about FP precision. I'm a little surprised that GRBL doesn't just use fixed-point. Even with 16-bit fixed point you could easily, accurately and precisely drive a very large machine with 0.001mm precison.
