peteruithoven
commented
9 years ago Thanks for digging into this, I hope we can find the culprit. I have to admit that I can't think of a reason for this issue. One this I do wanted to note is that instead of fixing the current grbl implementation I think it would be better, in the long run, to update the grbl we use and add a simplecode parsing step in front of it if possible. Preferably, if possible, in such a way we don't have to convert our simplecode into regular gcode, but we skip grbl's gcode interpreter. This would allow us to keep the grbl version up to date. I say this because I have seen other speed related issues in the past and I can't imagine there not being useful updates to grbl. One other community we might be able to cooperate with is Smoothieware, another lasercutter controller that also uses MBed. Looking through their commits they seem very active, but I believe they lacked engraving support.
matthijskooijman
pbrier
hpux735
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_speedis correctly calculated (e.g. 1% results in 480.0mm/min, other values were also correct). I also checked thatblock->nominal_rateactually 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_speedvariable, 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.