Movement speed behaves erratically and is incorrect #46
Description
Recently I noticed that there is something iffy with the movement speeds on our cutter. Initially I noticed that there was a huge speed difference between 1% and 0.99%. Further investigation using a laserscript test pattern with multiple speeds, as well as doing a simple square at different speeds manually, I noted that all speeds < 1% actually resulted in the same movement speed, whereas speeds >= 1% did actually influence the movement speed.
The above was observed using laoslaser-14-11-2014.bin from git. When I compiled my own version from git master (which should not have any relevant changes compared to that version) to enable more debugging, the behaviour changed. Now (even when doing a clean compile, without any extra debugging enabled), the speeds varied linearly, even below 1%. However, now 1% speed was somehow special - it was about 30% faster than expected (e.g. 4% takes 8 seconds, 2% takes 16 seconds, but 1% only takes 23 instead of 32 as you'd expect).
It does seem that the above speeds correspond to the configured value: We have a max speed of 800 mm/s. My square had a length of 240mm, so at 2% speed, this should take 240/(800*2%) = 15s, which seems close enough to 16s to be correct (@peteruithoven, it seems I wrongly calculated this before, so it is correct after all).
Now, things got more interesting when I did the laserscript test pattern again. With my self-compiled firmware (with debugging enabled), this showed the original behaviour again - all speeds below 1% result in the same actual movement speed.
I added some debugging output, which confirms that block->nominal_speed is correctly calculated (e.g. 1% results in 480.0mm/min, other values were also correct). I also checked that block->nominal_rate actually changes for different speeds, though I didn't check if the actual values are correct.
This suggests that the problem occurs later, somewhere in the grbl stepper driver?
Looking at the code did leave me quite confused. There's probably some complicated math required, but I couldn't escape the notion that things could be simplified. It seems there's a few layers - parsing simplecode, filling the planner buffer, actually executing the planner steps, and it seems that a lot of conversion back between units happens there. There is also a lot of floating point math going on, which could probably be done as integer / fixed point math as well? An initial thought I had was to convert everything to steps as soon as possible, but I just realized that the different axises might have different steps/mm, so that won't work. Still, sticking to a common, sufficiently precise, unit and converting everything to that unit early seems useful. Perhaps using um and um/s makes sense?
On a related note - it seems that the mark_speed variable, which is an int, currently limits granularity of speeds to 1mm/s. On our machine a speed of 1% corresponds to 8mm/s, so there's only 8 steps below 1% that are meaningful. Since that is the range where cutting of wood happens, it would be good to have extra granularity. Later, when passing the value on to grbl, the value is converted to mm/min, but that extra granularity is already lost then.