Movement speed behaves erratically and is incorrect

[matthijskooijman]

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.

[peteruithoven]

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]

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 is what happens now - the simplecode interpreter calls grbl planner functions directly. The gcode parsing code from grbl isn' even present I think.

This would allow us to keep the grbl version up to date.

This is probably tricky - in addition to leaving out stuff from grbl, there's also additions for controlling the laser and probably other laos-specific changes. To really properly support this, some changes to upstream grbl would be needed - it should offer hooks in the right spots that laos can use to get stuff done at the right moments. This could be based on preprocessor macros, so it doesn't add any size to the normal grbl build, but I'm not sure if grbl's authors would be open for this...

[peteruithoven]

There seem to be discussing it already: grbl laser issues. laser and grbl experiments for example.

[pbrier]

On 1/14/2015 11:01, Peter Uithoven wrote:

There seem to be discussing it already: grbl laser issues
https://github.com/grbl/grbl/search?q=laser&type=Issues&utf8=%E2%9C%93.
laser and grbl experiments grbl/grbl#492
for example.

—
Reply to this email directly or view it on GitHub
#46 (comment).

I would vote +1 for a cleanup of the path generator code.
As we have ample resources available and "near infinite look ahead" I we
could simplify things
simplecode --> float calculated speed segments --> stepper interpolation
The 2D math is not too complicated.

Using smoothie codebase is also possible, but I would not include the
Gcode interpreter or configuration code.

[hpux735]

Though I have little to offer at the moment in terms of resources to help, I would love simplified vector cutting code. I've wanted to experiment with PPI (pulses per inch) settings with LaOS, but I can't figure heads versus tails of the grbl code. http://hackaday.com/2014/06/11/better-lasing-with-pulses/